SuiteScript 1.0 Is Still Running Your Business. What a 2.1 Migration Takes, in Contract Developer Hours

Last updated: November 10, 2026

By Colin Boothe, CIO at Foretopia

A SuiteScript 1.0 to 2.1 migration starts with an inventory. List every script, sort each into retire, rewrite or leave for now, and estimate only the rewrites as contract developer hours on time and materials. KORE1-placed ERP and NetSuite consultants bill $73 to $123 an hour, median $91 (KORE1 Contract Rate Index 2026-Q4, n=15).

Open the Scripts list in your NetSuite account and sort it by API version. Go ahead. I’ll wait.

Somewhere in there is a 1.0 script that fires every time someone saves a sales order. A developer wrote it before half your current staff was hired, and that developer is long gone. Nobody can tell you exactly what it does, and nobody wants to be the person who finds out by turning it off. It works. That’s the whole problem, because working is the only reason it’s still there.

Now it has a date on it. Oracle put the schedule in writing, and the first deadline lands in 2027. This post covers what Oracle actually says, how to sort the pile without a six-month discovery project, and how to turn the rewrites into contract hours without making up a number.

Disclosure first. KORE1, whose site you’re on, places the contract SuiteScript developers I’m about to price, on contract staffing terms, and my own consulting group does this kind of migration for clients. So both of us have a stake if you hire help. If you’ve got a dozen scripts and a developer on staff with a free month, keep the money and do it yourself. Good for you.

Why Is SuiteScript 1.0 Still Running Your Business?

Because nobody budgets for code that works. A script that does its job produces no tickets, no complaints, and no line item. It sits there for years. Credit holds. Commission math. The file that goes to your warehouse every night at 2 a.m. Pricing rules a sales VP asked for once and forgot about. Nobody notices any of it.

Ten-year-old accounts collect scripts the way garages collect boxes. Different people wrote them for different reasons, a partner here, a contractor there, one very brave controller with a JavaScript book. Nobody ever went back through to decide which ones still earn their space. Classic garage.

Oracle’s own documentation is polite about it. It calls 1.0 “a previous version of SuiteScript” and says that although Oracle’s support and service teams can still troubleshoot solutions written in it, “this version is no longer updated” (Oracle NetSuite Help, SuiteScript 1.0 Documentation). The advice for new work is to pick 2.1. Fine for new work. It says nothing about the pile of 1.0 you already own and depend on.

One more thing before the dates. Some of those scripts shouldn’t be rewritten as scripts at all. A script that only sets a field when a status changes is a workflow wearing a trench coat. If you can’t tell which is which, SuiteScript vs SuiteFlow covers where the line sits. Then come back.

What Is Oracle’s Current Support Stance on SuiteScript 1.0?

Oracle says SuiteScript 1.0 is no longer updated, and its help center now sets a schedule that ends with every script on 2.1. Support can still troubleshoot 1.0 code today. From release 2027.1 that shrinks to critical issues only, and by 2028.2 all new and existing scripts must use SuiteScript 2.1.

Here is Oracle’s own wording.

Source: Oracle NetSuite Help, Transitioning To SuiteScript 2.1, read November 10, 2026. The page shows no revision date, and Oracle edits it, so check it again before you lock a schedule.

Read the 2027.1 row twice. “Other problems will require you to convert scripts to SuiteScript 2.1 first.” Translate that out of Oracle-speak and a 1.0 script that misbehaves in a non-critical way gets you a conversion project, on the script’s schedule and not yours. I’d bet it picks the busiest week of your quarter. Not great.

The 2028.1 row is the one I’d watch. Existing accounts can keep deploying 1.0 scripts, so it feels like a reprieve. It’s a countdown with a nicer font. Then 2028.2 says all of them, new and existing. Oracle’s help center also says that when a feature still requires an older version, you follow that feature’s documented requirements “until related help content is updated,” so a few oddballs may get exceptions. Don’t be an oddball.

My read, and this part is mine, not Oracle’s. Waiting for 2028 means competing with every other NetSuite account for the same few developers who still read 1.0 fluently, in the same few quarters. That sucks as a plan. Starting before the 2027.1 line means you pick the order of operations, instead of Oracle’s support queue picking it for you.

A side note on 2.0. If you also have scripts tagged 2.0 or 2.x, Oracle has an account-level setting that runs them on the 2.1 runtime before you touch any code, which makes them a smaller and separate project. This post is about the 1.0 pile.

How Do You Inventory and Triage Legacy Scripts?

Oracle’s first recommended step is plain. “Create an inventory of scripts that are not already using SuiteScript 2.1.” Pull the list from Customization, then Scripting, then Scripts. For each one, write down the type (user event, client, scheduled, Suitelet, RESTlet, workflow action), the API version on the script record, whether any deployment is active, the records it touches, and the name of a human who can answer questions about it. If the owner column says “unknown,” that’s data. Write it down.

Then three verdicts. Oracle hands you the first two. Start with “scripts that support critical business processes,” it says, and “inactive or obsolete scripts should be evaluated for retirement instead of migration.” Retire is the cheapest hour you’ll ever spend. Rewrite is where the money goes. Leave for now is the one people abuse, so it gets a rule. A script only gets left alone if it carries a written conversion date before 2028.2. No date means forgotten, not left alone.

Want a number against your own list? Send the bill rate quote page your script count, how many you expect to rewrite, your start date, and the weekly hours you want, and we’ll price it against these cells. The 2026 contract rate card has every cell if you’d rather read first.

Expect fights. Somebody will swear a script is critical because it once saved their quarter. Don’t argue. Switch it off in a sandbox, run the process it supposedly protects, and see what happens. Evidence ends more arguments than meetings do. Try it.

Group the keepers by business process, not by script type. Order-to-cash scripts move together, the warehouse integration moves together, and each group gets tested together. Oracle says to move scripts “in manageable groups rather than changing everything at once.” Our own change control at Foretopia adds a corollary. Changes that ship together still get assessed one at a time, because bundling is a classic way to dodge the assessment, and the assessment is where you find the surprise. Boring. It works anyway.

How Do You Estimate the Rewrite in Contract Hours?

I’m not printing hours per script, and you should be suspicious of anyone who does. I haven’t seen your code. A 1.0 script that formats an email and a 1.0 script that reconciles inventory across three locations can both be called a user event, and they don’t live in the same galaxy. Anyone quoting hours per script without opening the file is guessing with confidence. Hard pass.

What I can give you is the method. It’s short.

Sort the rewrites by what they touch, not by how many there are. One record’s fields makes a small script. Searches, sublists and several record types make a medium one. Anything that calls out to another system, runs on a schedule against thousands of records, or moves money is large. Ten small scripts and three large ones is a very different project from thirteen scripts.

Then run a pilot. Have the contractor convert one script from each size class in a sandbox, and keep the clock split four ways, between reading the old code, writing the 2.1 version, review, and testing. Those logged hours are your hours per class, measured on your code, in your account. Nothing I print beats them.

Add the lines nobody adds. Inventory and triage. Sandbox refresh. A regression pass after each group, where Oracle says to test all entry points and to verify “sublist behavior, searches, record operations, data handling, and error handling.” Handover notes, so the next person doesn’t open the file and say “who wrote this?” On a regulated NetSuite integration we scoped for a mid-market pharma manufacturer, validation alone came to roughly 30% of the hours. You won’t need that for a commission script. It does show where estimates go to die, and it’s never the typing.

Watch the conversion tool, too. Oracle lists automated options, including an agent skill that upgrades 1.0 scripts and an AI-assisted developer assistant. Then it adds, “Automated tools and agent skills can accelerate migration, but you must review all generated code, object updates, and deployment changes before using them in production.” It also warns that “some SuiteScript 1.0 functions do not have a direct SuiteScript 2.1 equivalent and might require a different implementation.” Those are your hour blowups. The tool shrinks the typing. It doesn’t shrink the review, and it can’t invent an equivalent that doesn’t exist.

Our written process for AI-assisted code says the same thing in plainer words. A named person is the author of record. Generation runs against an approved specification instead of a loose prompt. A second person reviews before anything merges. And the tests are written by a human, because a test generated by the same tool that wrote the code proves nothing.

Then multiply. Hours per class, times the scripts in that class, plus the extra lines, times the bill rate for the seat. Devin Hornick, a partner at KORE1, describes how a manager with a project thinks about this. “In the SOW world, this is just a hiring manager with a budget… a certain amount of hours based on that budget.” Same arithmetic here, with one correction from our side of the table. KORE1 bills the hours worked, so your estimate is a plan you check against actual hours every week, and the weekly burn report from scoping a contract NetSuite developer on time and materials works here too.

Source: KORE1 Contract Rate Index 2026-Q4, effective October 16, 2026. “Every 100 hours” is the median bill rate times 100, which is arithmetic and not an estimate of your project. The 13-week column is 40 hours a week for 13 weeks. A bill rate covers wages, payroll taxes, insurance, and KORE1’s recruiting and account management. The methodology page explains observed versus modeled cells, and the modeled cells start from the BLS Occupational Employment and Wages release for May 2025, published May 15, 2026.

Fine print, because I’d rather tell you than have you find it. The index has no SuiteScript-only cell, so I used the three nearest. The software engineer cells are general developers, not NetSuite specialists, and the senior cell rests on 7 placements, so read it as “experienced developers in Southern California bill about this” and not as a floor. A seat that needs deep 1.0 reading skills plus 2.1 writing can price toward the senior row from day one.

Why Is the Cleanup a Project, Not a Hire?

Because it ends. The skill is odd. Somebody who can read a decade-old 1.0 script, work out what the business was trying to do, and write the 2.1 version that does it properly. You need that person for a few months. After the last group ships the job is gone, and so is your reason to carry a salary for it.

KORE1’s median contract assignment runs 116 days across 1,887 placements (all roles, not only ERP), a bit under four months. Call it a sanity check. A plan that needs one contractor for two years isn’t a cleanup. It’s a hiring decision you haven’t admitted to yet.

There are exceptions. If your backlog is a conveyor belt of new SuiteScript requests and not a pile of old ones, hire. That’s a different post, how to hire a NetSuite developer, and the number to compare against is NetSuite developer cost. And if your contractor turns out to be someone you’d keep, KORE1 contractors can convert to your payroll at no fee after 1,040 hours. If you want the staffing side of a cleanup laid out, NetSuite customization cleanup staffing covers how we put the team together.

What Breaks If the Old Scripts Are Left Alone?

Devin Hornick puts one question to any project that might not get funded, which is what actually breaks if it doesn’t happen. Fair question. So here’s the list.

The first break is the quiet one. After 2027.1, a non-critical problem in a 1.0 script means converting first and fixing second. You’ll do that conversion on whichever script broke, under deadline, with no pilot and no sandbox time. You were always going to do the conversion. You’ll just do it badly.

Second, every NetSuite release is a free regression test you didn’t ask for. Twice a year your scripts run against new code, and the 1.0 scripts have no tests, no documentation, and sometimes no owner. Who tests all of that is a problem of its own, and I wrote it up separately in NetSuite release testing.

Third, the people. The one person who understands your 1.0 code retires, or quits, or takes a better offer from a company that’s busy with its own migration. My read again, but when every account is scrambling in the same few quarters, nobody’s hiring manager is going to be calm.

Fourth, and this is the one I’d frame and hang on a wall. On a regulated NetSuite engagement we scoped for a mid-market pharma manufacturer, there was an older SuiteScript integration that pushed files to the company’s third-party logistics provider. Nobody had put it under change control, and the customer’s instruction was to keep it as it was for now. We recommended the opposite. Document the interface, bring it under change control, and understand what it contributes to a data flow an auditor cares about. Doing that up front costs far less than answering an audit finding on it later, and a script nobody owns inside a process somebody audits is exactly how you collect one.

You’re probably not regulated. The lesson travels anyway. Unowned code on a path that matters is a liability whether or not an auditor ever shows up.

Questions Owners Ask Before Anyone Touches a Script

Can we just leave the 1.0 scripts running until Oracle makes us move?

Until 2027.1, support works the way it does today. After that Oracle covers critical issues only, and anything else starts with converting the script. 2028.2 is the date all new and existing scripts must use SuiteScript 2.1, so leaving them running is a plan with a deadline on it.

Does an AI conversion tool mean we need fewer developer hours?

Fewer typing hours, the same review hours. Oracle says automated tools and agent skills can accelerate migration, but you must review all generated code, object updates, and deployment changes before production. Some 1.0 functions also have no direct 2.1 equivalent, and those need a person to design a replacement.

Realistically, how long does a SuiteScript 2.1 migration take?

Nobody honest can tell you before the inventory exists. KORE1’s median contract assignment is 116 days across 1,887 placements, all roles, and a short pilot of one script per size class gives you hours measured on your own code instead of a guess.

What does a contract SuiteScript developer cost per hour?

$73 to $123 an hour for ERP and NetSuite consultants at a $91 median, with software engineers at $105 and senior engineers at $120 (KORE1 Contract Rate Index 2026-Q4). The software engineer cells are primarily Southern California, and contractors bill hourly, so a short pilot costs a fraction of the 13-week seat figures.

Wouldn’t a workflow be cheaper than rewriting every script?

For some of them, yes, and it’s worth asking script by script before you pay for a rewrite. A script that only sets a field when a status changes may be a workflow. Loops, sublists, real math and outbound calls are where code earns its keep.

Start With the Inventory

Homework. Before your next planning meeting, export the script list and add four columns. The API version, whether it’s active, the last time it ran, and the name of a person. Sort by API version. The 1.0 rows are your project, and the ones with no active deployment and no name are your first retirements. That’s a free afternoon that shrinks the estimate before anyone writes a line of 2.1. Nice.

Then hit me up on LinkedIn if the sorting is the part that stalls. If you already know your script count, get a SuiteScript developer quote and we’ll price it against these cells. Prefer to talk first? The contact page reaches a recruiter.

Data as of November 2026. Oracle’s SuiteScript timeline was read on November 10, 2026. The KORE1 Contract Rate Index refreshes quarterly, and this page is refreshed with it.