SuiteScript 2.1 before the deadline: sixty-plus scripts in under a day

NetSuite is moving every account to SuiteScript 2.1 and retiring the older versions. Most companies will scope this as a long project, one script at a time. We inventoried more than 1,600 scripts, converted and deployed more than sixty, and did it in under a day.

What’s changing

NetSuite has been moving the platform to SuiteScript 2.1 for some time. Accounts on recent releases now see notices that older script versions — 1.0 and 2.0 — will stop being supported, and customers have started receiving dates. Whatever the final cut-off turns out to be, the direction is settled: every custom script in the account needs to run on 2.1.

For a company that has been customizing NetSuite for years, that sounds alarming. Scripts written by three different consultants, some by an employee who has since left, a few nobody is sure are still running, and all of them touching orders, fulfillments, billing and payments. Nobody wants to be the person who broke shipping for the sake of a version number.

How this usually gets scoped

The default approach treats each script as its own small project: open it, read it, change it, test it, deploy it, next. Multiply by however many scripts the account has and you get a quote measured in weeks, a project plan measured in quarters, and an invoice to match. Some of that caution is warranted. Most of it is the cost of not knowing what you have.

Most of the risk in a platform migration is the inventory you never took.

What we did instead

Inventory everything first

The account had more than 1,600 scripts. That number is what scares people, and it is mostly not the client’s problem. We pulled the full inventory with version, type, owner, file and deployment status, and sorted it before anyone opened a file.

Separate whose problem each script is

Vendor and bundle scripts. The large majority belonged to installed SuiteApps and third-party bundles. Those are the publisher’s to convert. The right action is a list of vendors and a polite email asking for their timeline — not touching their code.
Dead scripts. Several custom scripts were inactive, undeployed or superseded by newer ones. Those don’t get converted; they get retired. Every script deleted is one less thing to test.
Blocked by the platform. One script type the client used is still limited to the old version by NetSuite itself. That one is marked as waiting on Oracle, with nothing to do yet.
Actually the client’s. What remained was a bounded list: a little over sixty active custom scripts.

Convert, deploy and verify in one pass

The remaining scripts were converted, checked and deployed the same day, then watched in production. A handful needed more than a version change, because 2.1 is stricter about a few things older versions let slide. Those surfaced quickly, were fixed the same day, and each fix became a rule applied to every new script written since.

The result

1,600+ scripts inventoried and sorted into theirs, ours, dead and blocked.
60+ custom scripts converted and deployed to production in under a day.
The legacy version backlog cleared except for the one script NetSuite itself has not yet opened up.
A workbook the client keeps: every script, its owner, its status and what happened to it, ready for the next vendor follow-up or audit.

For a fraction of what a script-by-script engagement would have cost, the client went from “we have a deadline and don’t know what we have” to “done, with a list proving it.”

Why it can be done this fast

Not through recklessness. Speed came from three things a long engagement tends to skip: an inventory before any work, a clear rule for what is and isn’t the client’s responsibility, and someone who has written enough SuiteScript to know which changes are routine and which deserve a careful look. We have a repeatable method for the conversion and verification itself, and we keep that part to ourselves.

What to ask before you sign a migration quote

How many scripts in the account are actually ours, and how many belong to vendors?
Which of ours are inactive or superseded and can simply be retired?
Which are blocked by NetSuite itself, and what’s the plan for them?
How will each converted script be verified in production, and how will we know if something regressed?
What do we get at the end besides converted code — is there an inventory we keep?

If a proposal can’t answer the first question, it’s priced on guesswork. If you’d like the inventory done before you decide anything, that’s where we start.