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.
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.
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.
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.
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.
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.
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.
| Golden thread flow | Why it matters |
| Refunds | Touches almost every part of a sales order: fulfilment, billing and returning the money |
| Purchase orders | Proves the procurement side end to end |
| Transfer orders | Checks stock moving between locations and warehouse systems |
| Gift vouchers | A distinct payment and liability flow that's easy to overlook |
| Each storefront | Every storefront has its own integration, so each one gets a run |
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.
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.
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.
| Your NetSuite setup | Upgrade risk | Testing focus |
| Mostly standard, few integrations, one entity | Lower | Baseline, release-note areas, core order and finance flows |
| Some customisation, a handful of integrations | Medium | Add custom scripts and workflows, plus each integration end to end |
| Multiple entities, many integrations, heavy configuration | Higher | Full golden thread for every entity and storefront, run early in the window |
This is the same thinking behind our Graded Test Approach: test in proportion to what happens if it goes wrong.
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.
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.
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.
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.