SuiteScript 1.0 Deprecation Date Confirmed: Oracle Sets a 2028.2 Deadline

I've spent the past few weeks telling people that SuiteScript 1.0 had no deadline — that it was frozen, not deprecated, and that anyone selling you a countdown was getting ahead of what Oracle had actually said. I wrote a whole page about it.

That page needed an update this week.

What changed

Oracle's SuiteAnswers article 1047412, SuiteScript 2.1 Required for All Custom Scripts in NetSuite 2028.2, was last updated September 16. I haven't read it myself — SuiteAnswers sits behind a NetSuite login — but two independent sources describe the same article, the same mechanism, and the same dates. That's enough corroboration for me to change what I've been telling people, with one caveat attached: I'm reporting this secondhand until I can verify it against Oracle's own account.

The account-level warning banner some of you have been seeing since the 2026.2 upgrade — "Update Needed: Update Scripts to SuiteScript 2.1" — is also now corroborated. I'd previously left it off my site because I couldn't confirm it against Oracle's release notes. It’s now confirmed!

The dates

Four releases, each doing something different:

• 2026.2 — SuiteScript 2.1 becomes the standard scripting model. The warning banner starts appearing for accounts still running 1.0, 2.0, or 2.x.
• 2027.1 — SuiteScript 1.0 enters end-of-life support: critical issues only. A non-critical bug now requires converting the script to 2.1 first.
• 2028.1 — scripts annotated 2.0 or 2.x start executing as SuiteScript 2.1 by default. No redeploy, no approval step, nothing on your change calendar.
• 2028.2 — the exit closes. Every script must be on 2.1 or it stops working.

Why 2028.1 is the one to actually watch

Everyone is going to fixate on 2028.2, because it's the date with teeth — the one where things stop working outright. That's a mistake.

2028.1 is quieter and more dangerous, because nothing visible happens. A script annotated @NApiVersion 2.0 doesn't get flagged, doesn't get redeployed, doesn't show up on anyone's sprint board. It just starts running on a different engine — ECMAScript 2023 instead of 5.1 — the next time it executes. Oracle gives you a preference to switch it back to the old runtime while you fix what broke, but that only helps if you notice something broke, and notice which script did it.

The behaviors that change under 2.1 aren't uniform, either. Some fail loudly — reserved words, for each...in, reassigning a const — and you'll find those in testing. Others change quietly: a decimal like 616.00 stores as an integer instead of a double, parseInt('08') starts returning a value where it used to return none, a RESTlet's JSON response stops getting double-stringified. Those are the ones that pass a smoke test and surface a month later in someone's reconciliation.

If you've never separated "scripts annotated 2.x" from "scripts actually running as 2.0" in your own account, that's the same trap in miniature: 2.x isn't a moving target that tracks the current version. It resolves to 2.0 today, and it's fully in scope for both deadlines above.

What I'd do with this if it were my account

Not panic before 2027 — there's still runway. But this year, not next: find out what you're actually carrying. Which scripts are 1.0, which are 2.0/2.x, which are yours versus a vendor's, and which ones would actually behave differently if the runtime under them changed tonight. That's a very different list from "everything annotated below 2.1," and it's the list that decides whether 2028.1 is a non-event or a fire drill.

Two other deadlines are running through the same window and often touch the same scripts — Token-Based Authentication and SOAP web services both retire on schedules that land at 2028.1 and 2028.2 respectively.

The full timeline, the sourcing, and the caveats I'm still sitting with are on the updated SuiteScript 1.0 deadline page.