SuiteScript 1.0 Is on the Clock. There's Just No Number on It Yet.

For years, moving off SuiteScript 1.0 was the thing everyone agreed they should do eventually. Eventually had no shape. That is starting to change.

Starting with the 2026.2 release, NetSuite accounts will show notifications warning that older script versions will eventually stop working in a future release. Oracle's own documentation already describes 1.0 as supported but frozen: no new features, no enhancements. This is the clearest signal the platform has given that the runway is finite.

There is still no published end date, though. No cutoff. No countdown. That combination is the actual news, and it is easy to read the wrong way.

Why no date is harder than a date

A deadline is something you can plan around. You put it on a roadmap, scope the work, hit it. Silence gives you none of that structure, and it invites the worst response available: waiting.

Here is the problem with waiting. 1.0 does not fail on a date. It erodes. NetSuite ships twice a year, and each release can shift the ground under legacy code without a single announcement. A client script that reliably returned a record starts returning null because the page renders differently now. A function call that ran untouched for a decade throws an error that was technically deprecated years ago. Nothing lands on a calendar. The behavior just drifts.

And there is usually more of it than anyone remembers. A heavily customized account can carry dozens or even hundreds of custom scripts, which is what makes "we will get to it" quietly expensive.

The part that has nothing to do with code

The scripts most exposed to this are the ones that have quietly worked the longest. That is exactly what makes them dangerous to touch. Code that has run untouched for eight years was almost always written by someone who has since moved on, and the reasoning behind it moved on with them.

So the job is rarely a clean translation from one syntax to another. It is closer to archaeology. Before you can safely rewrite what a script does, you have to reconstruct why it does it. That recovery of intent is the real work, and it gets harder every year the original author is gone.

Where AI helps, and where it doesn't

This is the part I get asked about constantly, so let me be straight. AI genuinely accelerates the mechanical side of a port. Translating a 1.0 function into 2.1, restructuring a script into the module system, drafting the first pass: that work is faster than it used to be, and we use these tools every day.

But it makes the human part more important, not less. A model can rewrite syntax. It cannot know that a particular field was populated by a workaround finance relies on at close, or confirm that the rewritten version still behaves under real data. Someone who understands the business process still has to validate it before it ships. AI shortens the easy part, which just throws more weight onto the judgment part.

How to find out what you are carrying

You do not need anyone else to take the first inventory. Two reliable tells.

The fast one is a search. Anywhere a script uses the "nlapi" prefix, you are looking at 1.0. That signature is your first candidate list.

The systematic one lives in the UI. Go to Customization > Scripting > Scripts and set the API Version filter to 1.0 for the official count. Then check the thing most people forget: custom plug-in implementations. Several of those did not get 2.x support until relatively late, so they can sit outside the obvious list and quietly stay on 1.0. Look at them separately.

Once you have the list, the next move is triage, not a mass rewrite. Start with the scripts that touch money and month-end, test every change in a sandbox against real transactions before it goes near production, and phase the rest. That is what keeps a migration from becoming its own outage.

What this actually is

We only do SuiteScript, so some version of this runs through most of our weeks. The honest version: the new syntax is the easy part. 2.1 is a better language, and rewriting a function to use it is not where the difficulty lives.

The difficulty is doing it without breaking a process the business has depended on for years, using logic no one documented, in a system where a small regression can hide until month-end. That is a judgment problem before it is a coding problem. It is also why "we will get to it" tends to be the expensive plan. Not because a deadline is bearing down, but because the knowledge required to do it cleanly keeps walking out the door.

So no, you do not need to panic. You do need to stop treating the missing deadline as permission to wait. Find out what you are carrying. Then move on a calendar you control, instead of one a broken close picks for you.

If you want a second read on your 1.0 inventory before anyone touches it, my inbox is open.