What needs testing when NetSuite releases an upgrade?

If you're a retailer running NetSuite, test five things before each upgrade: a baseline of your current test results, the areas the release notes say are changing, your most customised workflows and scripts, every integration between NetSuite and your storefront, warehouse and order management systems, and your critical end-to-end retail flows, such as online orders, fulfilment, refunds and purchasing.

NetSuite releases two major upgrades a year, each in a fixed window, so plan your testing early. Here's what that looks like in practice.

NetSuite upgrades have a reputation for being low-drama. Oracle runs them, the platform is mature, and most releases land without anyone noticing.

And that's the point. You want nobody to notice.

For more than two and a half years, we've run end-to-end regression testing for every NetSuite upgrade at Lovehoney, a retailer that brought multiple global entities onto a single NetSuite instance. In that time, no NetSuite upgrade has caused a live incident. The risk is still there every release but thorough testing is what keeps it from reaching shoppers.

How NetSuite upgrades work

NetSuite ships two major releases a year. Before each one, customers can request a Release Preview account to test the new version against their own processes. Your scheduled upgrade dates appear in the New Release portlet in your account.

In practice, you get a window of around six weeks. Within it, you agree a plan with NetSuite: which environment gets the upgrade, and when. Staging first, then the other sandboxes, then production.

There's some flexibility but there's also a cut-off. Leave it too late and NetSuite upgrades every environment anyway, whether you've tested or not.

Get the upgrade onto your staging environment as early as you can and give yourself at least a week there. If problems show up, you can push the later dates back.

Check where the window falls against your trading calendar too. An upgrade landing in the run-up to Black Friday or a major sale leaves very little room to fix anything. Our Peak Survival Guide covers how to prepare for peak trading.

So the first rule of NetSuite upgrade testing is simple: it's time-boxed. Treat the window as a fixed deadline and plan backwards from it.

What needs testing when NetSuite upgrades

1. Your baseline, before anything changes

Run your test pack before the upgrade lands.

If something is already failing, you need to know about it now. Otherwise you'll find it afterwards and assume the new release caused it. A clean baseline separates existing issues from new ones, and saves days of chasing the wrong problem.

2. What's actually in the release

Read the release notes and map them against how your retail business uses NetSuite. The aim is to build a picture of where change could touch you, so testing effort goes there first.

3. Your most customised areas

You'll know where your NetSuite instance has the most tailoring: custom scripts, workflows, records and configuration. Those are the higher-risk areas in any upgrade. The more an area departs from standard NetSuite, the more attention it deserves.

4. Integrations, upstream and downstream

This is the big one. Anything NetSuite feeds, and anything that feeds NetSuite.

At Lovehoney, NetSuite connects to Salesforce Commerce Cloud and multiple warehouse and order management systems through Celigo integrations. They also have several trading entities, each with its own processes, plus different tax rules across US states, Canada and Europe. There are a lot of connections to check.

Every one of those connections is a place where an upgrade could quietly change behaviour. We see the same pattern on Shopify projects, where most of the risk sits in the integration layer.

5. Your critical end-to-end flows

We run what we call a golden thread: a set of end-to-end tests that pass through every critical process and every integration. It proves that each flow still works from start to finish once the upgrade is in, without needing to test every variation.

Run these for each entity or subsidiary that has its own workflow. For retailers with several brands or regions, that's where the variations hide.

6. Your tests themselves

One thing that does change with upgrades: page layouts, how pages are built, and how element IDs work. Changes like these can break automated tests.

Build in a little time after each release to repair your automation. In our experience, the fixes are usually small, and one change often fixes a whole group of tests at once.

How much testing does your upgrade need?

It depends on how far your NetSuite instance has moved from standard.

If your retail business runs a setup with limited tailoring and few connected systems, your upgrade risk is towards the low end.

If you have multiple entities, lots of integration points and heavy configuration, it's at the high end and your testing should reflect that.

This is the same thinking behind our Graded Test Approach: test in proportion to what happens if it goes wrong.

Manual, automated, or both?

Both, but weighted heavily towards automation.

For Lovehoney's 2026.2 NetSuite upgrade, the automated regression pack ran 1,645 tests in 5 hours 40 minutes. By hand, the same tests would take an estimated 37 tester-days, every release.

When the upgrade window is six weeks and you want a week in staging, that difference matters.

Some checks stay manual, and should. Areas without a proper sandbox setup may need test data loaded by hand. And finance should always review the outcomes themselves. Automation's job is to clear the road before they get there.

Watch out for environment refreshes

Sandbox refreshes can cause as much disruption as the upgrades themselves.

A refresh pulls data down from production or another sandbox, and that can knock out integration connections. Treat a refresh like any other change, and re-check your integrations afterwards. NetSuite also advises against refreshing a sandbox close to your upgrade date: a refresh that hasn't finished when the upgrade starts will fail.

If nothing has failed before, why test?

A smooth last upgrade tells you very little about the next one. Assuming it does is confirmation bias.

Upgrade testing also gives you a dry run. Your ecommerce, warehouse and finance teams get to rehearse the steps, everyone refreshes their memory, and you go into the deployment with a clear, current baseline.

Most of all, it gives you confidence. An automated regression pack needs a little maintenance after each release, and in return you go live knowing what to expect.

Where Spike fits in

We help retailers test NetSuite with confidence, through upgrades, refreshes and everything in between.

For Lovehoney, that means an automated regression pack that runs from storefront order through to the general ledger. We run it before every NetSuite upgrade and maintain it as the retail business changes, so it keeps working release after release.

We also ran independent end-to-end testing for Ooni's move to NetSuite, covering orders from Shopify through to their 3PL partners.

If your next NetSuite upgrade window is coming up and you're not sure what you'd test first, now is the time to work it out, while there's still room in the window.

Read the Lovehoney case study

Frequently asked questions