Since 2026.2, NetSuite administrators have been seeing a notice: scripts written against SuiteScript 1.0, 2.0 and older 2.x will stop working in a future release.
No date. Oracle hasn’t given one.
So everybody is watching the deadline that doesn’t exist, and almost nobody is looking at the three sitting next to it that do.
The dates that are already published
Pull the platform roadmap together and SuiteScript stops looking like an isolated event.
Token-based authentication. From 2027.1 you cannot create new integrations using TBA for SOAP, REST or RESTlets. OAuth 2.0 becomes the only option for new work, and new authorization-code integrations require PKCE for every client type. Support for existing TBA integrations is expected to end around 2028.1, with SuiteAnalytics Connect the exception.
SOAP web services. The 2025.2 endpoint was the last one planned. From 2026.1 new endpoints stopped being included by default. In 2027.1 no new SOAP integrations are permitted. By 2027.2 only that 2025.2 endpoint is still supported. In 2028.2 SOAP is gone from NetSuite entirely.
The analytics data source. Already done. 2026.1 removed the legacy NetSuite.com source, and workbooks had to move to NetSuite2.com.
SuiteScript. 2026.1 gave you a preference to run 2.0 server scripts on the 2.1 runtime. 2026.2 started the warnings. Enforcement: unannounced.
Three of those four have dates. The one everybody is talking about is the one that doesn’t.
Why that matters more than it sounds
These aren’t four separate projects that happen to share a calendar. They land on the same code.
Picture an integration a partner built for you in 2019. It talks to NetSuite over SOAP. It authenticates with TBA. It’s triggered by a SuiteScript 1.0 RESTlet, and something downstream reads a saved search into a workbook.
That single integration appears on all four lists.
If you treat them as four initiatives you will scope it four times, regression-test it four times, and go through change control four times. If you treat the integration as the unit of work, you touch it once.
Almost nobody is planning it that way, because the deprecations were announced separately and land in different parts of the release notes.
The one thing to check today
Go to Customization → Scripting → Scripts and filter on API Version. That gives you the count of 1.0 and 2.0 scripts in the account.
Then look for anything declaring @NApiVersion 2.x. That is not a pinned version. It means whatever NetSuite currently considers latest, so those scripts already shift underneath you on releases you didn’t approve. Most people are surprised by that number.
While you’re there, grep your source for nlapi. Every 1.0 API carries the prefix, and it catches what the script list doesn’t show cleanly: workflow action scripts, client scripts hanging off custom forms, code pasted somewhere it shouldn’t have been.
SuiteScript 1.0 doesn’t fail loudly
This is the part that changes how urgent it feels.
nlapiSearchRecord() on a compound AND/OR filter doesn’t throw. It returns an empty result set. If a report has been quietly giving zero rows and somebody rebuilt it in a spreadsheet rather than raising a ticket, that’s usually why.
Scheduled script chains stop mid-run if a deployment’s status flag isn’t cleared or governance runs out. No error. You find out because something downstream didn’t happen.
pageInit fires before the Responsive UI has populated fields, so a user sees a blank field on a record that visibly contains data, and nothing appears in the execution log at all.
None of this shows up on a dashboard. It shows up as “the system is a bit unreliable”, which is how it survives for years.
Oracle’s own position on 1.0 is worth reading plainly: it is still supported, but “no new feature development or enhancement work is being done”. Frozen, not maintained.
What actually changes in 2.1
Not the syntax. The engine.
2.0 runs on Rhino, an ES5.1 engine. 2.1 runs on GraalJS, roughly ES2023. Different engine, different semantics, and the one that catches people is that 2.1 executes in strict mode.
Assign to a variable you never declared and 2.0 handed you a global. 2.1 throws. eval() stops working. So does with(), which appears constantly in older NetSuite code because it saved retyping a record variable.
Then the quieter category. var hoists and let doesn’t, so converting them breaks anything using a variable above its declaration. Arrow functions change what this means and drop the arguments object. Template literals stop silently swallowing undefined values and start printing the word undefined into your output, which is a decade of latent bugs becoming visible at once.
Measure it instead of estimating it
2026.1 added a global preference that runs your existing 2.0 server scripts on the 2.1 runtime without rewriting them.
This gets read as a stay of execution. Use it as a measuring instrument instead.
Turn it on in a sandbox refreshed with real data and watch. Most 2.0 scripts run unchanged. The ones that don’t are relying on 2.0-specific behaviour, and that list is your actual scope. You’ve swapped a guess based on script count for a number based on what genuinely breaks, and it cost you a sandbox refresh.
It covers server scripts only, so client scripts still need their own pass.
Half of it shouldn’t be converted at all
Before converting anything, work out which of four things is true.
Nobody uses it, so delete it. In most accounts this is the biggest category by a distance, and doing this pass first shrinks everything downstream.
The platform does it natively now. SuiteFlow, native approvals and saved search capability have all moved a long way since 2015, and plenty of old custom script is solving a problem NetSuite has since solved for you.
It’s real custom logic with no native equivalent. That’s the work.
Or the process it encodes has changed, and converting it faithfully just preserves a bug in a newer runtime.
Oracle’s AI-assisted upgrade skill handles the mechanical majority well, with 125+ API mappings and 34 object conversions. It also documents 13 APIs with no 2.1 equivalent at all, and there are cases where a single 1.0 call becomes several 2.x calls depending on what the code was for. Those need somebody who understands the process, not just the syntax.
The bundles you’re not allowed to touch
Some of the legacy script in your account isn’t yours. It arrived in a managed bundle from an ISV or a former partner, and you cannot edit it. Your plan does nothing for it.
Vendors still trading need one email: what’s your SuiteScript 2.1 timeline? Keep the reply. A vendor who can’t answer that in September 2026 is a risk you’re carrying for them.
The harder case is a bundle from a partner who’s gone, or a product that’s been end-of-lifed. Replacing a bundle, rebuilding natively or negotiating an unmanaged copy all take months and all involve procurement. Send those emails this quarter, because the answers set your critical path and nothing about them compresses.
On waiting
The argument for waiting is that there’s no date, so there’s no urgency.
The argument against is that 2027.1 and 2028.2 are real, they’re published, and they hit the same integrations. When SuiteScript enforcement is finally announced it will land on accounts already mid-way through an OAuth migration and a REST migration, staffed by the same small pool of people who know this platform.
Everyone will reach that conclusion at the same time. That’s the actual risk, and it isn’t technical.
Suiteley’s consultants and certified SuiteScript developers work as one team, which is why we can tell you which scripts to delete rather than quoting you to convert all of them. If you want a script inventory and risk assessment on your account, get in touch.