NetSuite Release Testing: Who Actually Tests Your Scripts Twice a Year

Last updated: November 1, 2026

By Colin Boothe, CIO at Foretopia

NetSuite upgrades every account twice a year, and the Release Preview is your only rehearsal, so run a short contract test sprint that retests your scripts, integrations, and saved searches before the upgrade lands. My group at Foretopia budgets about 120 hours a year to keep one validated NetSuite integration in its validated state across both releases. KORE1-placed ERP and NetSuite consultants bill $73 to $123 an hour, median $91 (KORE1 Contract Rate Index 2026-Q4, n=15, multi-state).

Video chapters

• 0:00 — Intro
• 0:26 — What usually breaks in a NetSuite release?
• 0:38 — How the Release Preview window works
• 1:17 — Release testing under change control
• 1:45 — Who should test, and what each seat bills
• 2:32 — What breaks if testing is skipped, and quick questions

Oracle’s help page on this has a line I love. “You are not expected to test the new features for NetSuite.”

Read it twice. Oracle isn’t asking you to check Oracle’s work. It’s asking you to check yours. Every script, every integration, every saved search somebody built in 2021 before they left for a better job. You get a copy of your account on the new version, and you get a deadline. That’s the offer.

So who does it?

It’s on almost no job description. Ask around and you get a shrug, then the admin’s name, then the admin’s face when they hear about it.

Bias first. My group offers release maintenance to regulated clients. KORE1, whose site you’re reading, places contract testers through QA staff augmentation and the rest of its IT staffing services. We would both like you to pay somebody. If you have twelve scripts, one integration, and an admin with free hours, keep your money and steal the checklist below. Everyone else should keep reading, and should know the ongoing version of this lives under NetSuite support services while the seats themselves come through contract staffing.

What Changes in a NetSuite Release, and What Usually Breaks?

NetSuite release testing is a regression pass you run against your own customizations before each scheduled version upgrade reaches production. It retests scripts, workflows, integrations, saved searches, and formulas against the new version in a Release Preview account, then records what passed, what failed, and who fixes it.

Oracle’s 2026.2 notes call that version “one of two scheduled version upgrades delivered each year,” with monthly releases between them and SuiteApps on a schedule of their own. Twice a year. Forever. You can move the date. You can’t skip the upgrade.

Oracle tested Oracle’s stuff. Fine. Nobody tested yours.

• Some SuiteScript calling an API the release notes just changed. Oracle literally points you at the SuiteScript section of those notes for this. Who reads them? Nobody, until something’s on fire.
• Integrations. 3PL, storefront, EDI broker, bank. Pick one. Now you’ve got two vendors on a call, each positive it’s the other guy.
• Saved searches with formula columns are sneakier, since they don’t throw errors. You just get a different number, politely, and nobody looks until close.
• Scheduled workflows.
• That SuiteApp your vendor manages for you? Oracle says managed bundle upgrades can’t be pushed to a Release Preview account. So unless somebody installs the upgrade by hand you’re rehearsing with last season’s copy, and you won’t know it.

And an iPaaS doesn’t get you out of this, before you ask. It came up on a proposal of mine this summer, a mid-market pharma manufacturer. Answer was no. Custom records, saved searches, permissions, RESTlet endpoints, all of it stays on the NetSuite side no matter what carries the data, so your regression scope follows what the release touches and the tool doesn’t get a vote.

How Does the NetSuite Release Preview Window Actually Work?

An administrator has to ask. Nobody hands it to you. Setup > Company > Release Preview, click Request Release Preview, from production or a sandbox account. Then wait. Oracle’s Release Preview overview says about 5 to 7 calendar days to build it, and a later refresh moves with your account size, how many integrations you’ve got, and how many other customers picked the same week.

How long does it stay open? Oracle doesn’t publish a day count that I can find. Access ends the date your production account upgrades, and that date sits in the What’s new in the Suite portlet. Oracle will also purge the account after 14 consecutive days with no login, so your rehearsal space can get deleted because everybody was busy at month-end.

Nice.

Your sandbox won’t save you. Oracle’s upgrade maintenance notes say the sandbox gets upgraded within 7 days after production, which is the wrong direction for a rehearsal. Same page: four hours reserved for the production upgrade, many finished within 60 minutes, and a Customer-Scheduled Maintenance tool for moving the date. Moving it is not a test plan.

Then the part that catches people. A Release Preview account is a copy of production as of a certain date, and it’s a copy with pieces missing. From Oracle’s list of what’s testable:

The token row eats day one. A NetSuite RESTlet won’t take a plain API key in the first place, since external callers need OAuth 1.0 token-based authentication or OAuth 2.0, so a vendor that can only POST with an API key is already talking through a relay you put in front of it. Test the relay too. It’s the piece everyone forgets exists, right up until it’s the piece that’s down.

Oracle’s suggested test plan comes with an Excel template, and you should use it, but it doesn’t name who does the work. Neither does anything else Oracle publishes on this. The right-hand column below is my answer. Start with inventory: Script Deployments gives you the list of scripts, while saved reports and saved searches can’t be exported, so somebody builds those lists by hand.

Sucks. Do it anyway.

Want a tester booked for the next release? Send the release date, your script and integration count, whether you’re regulated, and how many weeks you need through the contract test sprint quote request.

How Does a Regulated Shop Handle a Release Under Change Control?

Same test. A paper trail with teeth.

Our written change control process at Foretopia treats a NetSuite release as a change to the operating environment, then runs it through the same machinery as any other change. It gets assessed against the release preview before it reaches production. The record says which functions in scope are affected, what regression testing is required, and what remediation is needed. A release that needs a fix? That fix is its own change with its own record. Sounds like bureaucracy. Then an auditor asks you to prove it.

Two rules carry it. Whoever assesses the change doesn’t get to implement it. And you can’t bundle your way out, so a release fix shipping alongside three other tickets means each one gets assessed alone and then the pile gets assessed together. Ever seen a change log with “release updates” as one line covering a month of unrelated work? That’s what the rule is there to kill.

Nobody’s asking for full requalification every six months. That’d be absurd. You size it with a risk-based impact assessment of what the release touched, write down why, and move on, which is how the GAMP 5 Second Edition crowd already thinks. And the regression set comes out of your original operational qualification protocols. You paid for that proof once. Rerun it.

Now the number. In that pharma proposal, holding one validated integration in its validated state came to 120 hours a year. It isn’t all testing, though. Impact assessment and regression across both releases, the documentation, change control support, incident response up to an allowance, a yearly review with quality, that’s the whole 120. Walk away and the integration keeps running fine. The validated state is what lapses, quietly, and you’ll pay more to buy it back than you would have to keep it.

Why Not Ask the Controller to Click Around?

Because you’ll get clicks.

A good controller knows when a number is wrong, and that’s worth a lot, so keep them in the loop as the approver. Asking them to design the test is different, because they’ll run the invoice they ran this morning, it’ll work, and they’ll go back to the close they were already late on. Accountants should approve tests. They should not write them.

Developers shouldn’t grade their own work either. I said this to a regulated client in writing: the failure mode of self-testing isn’t fabricated results, it’s unconsciously gentle test design that exercises the paths the builder had in mind. Nobody’s lying. They just never think to send an order with a blank lot number, because their own code would never produce one, so the idea of testing for it doesn’t occur to anybody in the room until a real one shows up. Good regression work is mostly negative tests like that. Expired token. Partial shipment. A record with the field everyone assumes is filled in.

Same logic applies if AI wrote part of your SuiteScript, which it probably did. Our policy says test scripts and acceptance criteria don’t get generated by the same means as the code they exercise, because independence of the test from the implementation is the whole control. Ask one tool to write the code and the test, and you’ve got a kid grading their own homework with a very confident smile.

Which gets you to a small crew. Here’s who sits in the sprint, priced from the KORE1 Contract Rate Index 2026-Q4 (effective October 16, 2026).

How to read that. KORE1 observed cells come from KORE1 W2 contract placements started 2023 to 2026, with five or more behind each cell and the count shown. Modeled cells use wages from the BLS May 2025 Occupational Employment and Wages release plus a 24% burden, times the bill-to-cost range KORE1 observes. Both QA rows are modeled, not placements. The analyst cell rests on six deals, so call it a ballpark. The index methodology shows how each one is built, and metro cells are on the 2026 Contract Rate Card.

Lazy math for an account with a few dozen scripts and a handful of integrations. A mid-level tester for two weeks, 80 hours at $83, is $6,640. An ERP consultant half time on the fixes, 40 hours at $91, is $3,640. An analyst for 20 hours at $99 is $1,980. That’s 140 hours and $12,260 for one release, or $24,520 a year. Swap in the senior tester for the first pass while the regression set gets built and one release runs $14,100.

The hours are my sizing, not a study. Argue with them using your own script count. It’s arithmetic on index cells, billed hourly with your people directing the work, and it isn’t a quote.

And if the sprint keeps finding the same gap, it isn’t a sprint problem. No admin at all points you to NetSuite administrator staffing, or to the first-30-days plan I wrote for when your NetSuite admin quits. A pile of broken scripts points to NetSuite developer staffing, and I’d scope that developer on time and materials. Too many scripts is its own conversation, and it starts with SuiteScript versus SuiteFlow, because every script you don’t write is one less thing to retest twice a year until you die.

Booking takes less time than the preview does. Median offer-to-start across 1,997 KORE1 contract placements is 3 days, though sourcing and vetting come first, so start the search before Oracle’s notice lands rather than after it, when every other NetSuite shop is asking for the same people. The service version of all this is ERP testing and UAT staffing. Still ahead of go-live? Start with how many contractors a NetSuite go-live needs.

What Breaks If Release Testing Is Skipped?

Often nothing you can see on upgrade day. Four hours are reserved, it finishes early, and everyone goes home pleased.

Monday is where it starts. The scheduled script nobody ran by hand in preview has its first automated run in production, against live orders, and if it fails, your first test result is a pile of orders that didn’t move. An integration starts rejecting records, and because no one tested the failure path, the error lands in a log nobody reads while your 3PL waits on a file that isn’t coming. You’ll hear about it from the warehouse. Maybe a customer.

Formula columns are slower. A saved search that feeds a reconciliation returns something a little different, and it sits there until close, when the controller is out by an amount nobody can explain and three people spend two days hunting a bug in the wrong place. In a regulated shop it’s quieter still. Everything runs. The validated state lapsed anyway. You find out when an inspector asks for the release assessment and you’re holding a blank page.

KORE1 partner Devin Hornick has a filter for where money still moves: “where companies are still investing and where they simply can’t afford to have projects fail or go unfinished.” Your ERP passes it by default. It closes the books, ships the orders, and sends the invoices. Plenty of hiring budgets are tight right now, but nobody’s freezing whether the warehouse gets its pick list.

You’re going to pay for release testing no matter what. Once on a schedule, in a copy of your account, for a known number of hours. Or once in production, with your customers helping.

Things People Ask the Week the Upgrade Notice Shows Up

Realistically, how long does the NetSuite release preview stay open?

Until your production account upgrades, which is the only end date Oracle gives, and I can’t find a published day count. Creating the account takes about 5 to 7 calendar days, so request early. Log in at least every two weeks too, since 14 consecutive days without a login purges it.

Does the preview run our scheduled scripts on its own?

No. Scheduled and map/reduce scripts get copied, but they don’t run unless someone runs them by hand. Oracle says automated scheduled runs can only be tested in sandbox accounts, and its upgrade notes put the sandbox upgrade within 7 days after production. Read those two together. You run them manually in preview, then watch the first automated run in production like a hawk.

What would one test sprint actually run us?

$12,260 on my example: 140 hours across a mid-level tester, an ERP consultant, and a business systems analyst at KORE1 Contract Rate Index 2026-Q4 medians. That’s a sizing, not a quote. A bigger script count moves the hours, and the first release costs more because somebody has to build the regression set, which is the part people forget to budget when they copy last release’s number.

We aren’t regulated. Can we skip the paperwork?

Skip the binder, keep the testing. A distributor doesn’t need a validation summary report, but it still needs a list of what was tested, who passed it, and what’s still open. One spreadsheet does that. Regulation changes how much you document. It doesn’t change what breaks.

Can our implementation partner just cover this?

Sometimes, so read the contract before you assume. Plenty of retainers exclude regression work on your customizations, or bill it as extra, and the post on what a NetSuite retainer buys you lists the exclusions to ask about. A partner also knows the build far better than your business, which is why someone on your payroll still approves the results.

Start With One Number

Open Script Deployments and count. Then count your integrations. That’s your scope, and it takes ten minutes, and I’d bet you a donut nobody at your company has done it since go-live.

If the number scares you, hit me up on LinkedIn. If you already know you need hands, talk to a KORE1 recruiter before the notice shows up, not after.

Data as of November 2026. The KORE1 Contract Rate Index refreshes quarterly, and I’d recheck this page against Oracle’s docs before each NetSuite release.