SuiteScript 1.0 and 2.0 End-of-Life: Mandatory Migration to 2.1 by 2028.2

Starting in 2026.2, SuiteScript 2.1 is the standard scripting model. Oracle has published a phased deprecation timeline that ends with the complete removal of SuiteScript 1.0, SuiteScript 2.0, and the @NApiVersion 2.0 / @NApiVersion 2.x annotation values in 2028.2.

Deprecation Timeline

What Is Actually Changing at the Runtime Level

SuiteScript 2.1 runs on a newer JavaScript engine that supports ES2019+ syntax: let/const, arrow functions, spread operators, destructuring, template literals, async/await, and Promise. SuiteScript 2.0 scripts already use the same module loader (define()/require()) and N/* module APIs, but they execute in an older Nashorn-era runtime that lacks these language features.

The practical difference between SS 2.0 and SS 2.1 is the @NApiVersion annotation value in the JSDoc block at the top of your script file. Changing @NApiVersion 2.0 or @NApiVersion 2.x to @NApiVersion 2.1 switches the runtime. The module API surface (N/record, N/search, N/query, N/https, etc.) is the same.

SuiteScript 1.0 is a fundamentally different API — global functions like nlapiLoadRecord(), nlapiSearchRecord(), nlapiSubmitField() — and requires a full rewrite to the N/* module pattern.

Key Risk: 2028.1 Forced Runtime Upgrade

In 2028.1, any script still annotated @NApiVersion 2.0 or @NApiVersion 2.x will silently execute under the 2.1 runtime. This is the highest-risk milestone for shops that have not tested. Code that relies on Nashorn-specific quirks — Java interop via Java.type(), implicit type coercion differences, or undocumented global objects — may break without warning once the runtime swaps underneath it.

What to Do

1. Inventory your scripts. Go to Customization > Scripting > Scripts, filter by API Version. Any script not showing 2.1 needs attention. You can also use N/search on the script record type, filtering on apiversion, to generate a programmatic inventory.
2. Triage into three buckets:
   • SS 2.0 → 2.1 (low effort): Change the annotation from @NApiVersion 2.0 or @NApiVersion 2.x to @NApiVersion 2.1. Test for any Nashorn-specific behavior. Most scripts will work without code changes.
   • SS 1.0 → 2.1 (full rewrite): Replace global API calls with their N/* module equivalents. This is not a find-and-replace; the control flow, error handling, and context object patterns are different.
   • Retire: Deactivate scripts that are inactive, obsolete, or duplicated. Remove their script deployments.
3. Prioritize by risk. Start with scripts attached to critical business processes — approval workflows, integration endpoints (RESTlets, Suitelets serving external systems), scheduled scripts that run financial processes. High-governance or high-frequency scripts should be tested first.
4. Test in Sandbox. Deploy the updated script in a Sandbox or Release Preview account. Compare behavior against the original by running the same transactions. Pay special attention to:
   • Scripts using eval() or dynamic code generation
   • Scripts relying on arguments object behavior in arrow functions (arrow functions do not bind arguments)
   • Scripts using var hoisting patterns that behave differently with let/const block scoping if you refactor
5. Roll out in phases. Migrate in batches — do not flip all annotations at once. Monitor the Script Execution Log and script governance usage after each batch before proceeding.

Common SS 1.0 → 2.1 Equivalents

• nlapiLoadRecord(type, id) → record.load({ type: type, id: id })
• nlapiSearchRecord(type, id, filters, columns) → search.create({ type: type, filters: filters, columns: columns }).run()
• nlapiSubmitField(type, id, fields, values) → record.submitFields({ type: type, id: id, values: obj })
• nlapiRequestURL(url) → https.get({ url: url })
• nlapiGetContext() → runtime.getCurrentScript() / runtime.getCurrentUser()

Bottom Line

The 2027.1 critical-only support gate for SS 1.0 is the real forcing function — after that release, Oracle will not fix non-critical bugs in 1.0 scripts, and the only remediation path is migration. If you have a significant SS 1.0 codebase, start rewriting now. For SS 2.0 scripts, the migration is mostly a one-line annotation change, but you must validate in a test environment before 2028.1 forces the runtime swap on you.