What to check before your account upgrades
NetSuite updates twice a year and you can’t opt out. The .1 release lands in the first half of the year, the .2 release in the second, and your account gets upgraded on a date Oracle picks.
The short version: request a Release Preview account as soon as you can, set the email preference before you touch anything else, spend most of your testing time on the workflows you already have rather than on the new features, and write down what you find, because you cannot move fixes out of a Release Preview account.
Most of what goes wrong in a release is not a new feature behaving badly. It’s an existing script, search, or integration that quietly stops meaning what it used to.
When your turn comes
Releases roll out in phases rather than all at once. Roughly 20 percent of accounts go in the first phase, then 40 percent, then the last 40 percent. For a .1 release those phases typically land in February, March and April. For a .2 release, August, September and October.
Which means the quiet month is the one before the first phase, January or July. That’s when the release notes and the Sneak Peek show up and when requesting a Release Preview account is least likely to collide with anything else you’re doing.
Your actual date is in the New Release portlet on your dashboard. Add that portlet if it isn’t there.
And that date is a default, not a decree. There’s a reschedule link in the portlet itself, or you can go straight to Setup > Company > Customer-Scheduled Maintenance. Find NetSuite Version Upgrade Maintenance, click Reschedule, pick a new date and start time, give a reason, done. No approvals, no support case, and it works for sandbox as well as production.
Four details that decide whether this is actually useful to you.
It’s available to every customer. Oracle says so plainly: customer-scheduled maintenance is available regardless of service tier.
You can do it more than once, as many times as you like, until the schedule locks somewhere between 72 and 24 hours before the maintenance. The page itself tells you when rescheduling closes.
Some dates will be greyed out. Oracle dims the ones that collide with maintenance it can’t move. So you’re choosing from an offered set rather than naming any date you want. If nothing in that set works, you can contact Support before the maintenance window with a justification, which is a different and slower path.
Nobody is checking your choice. Oracle’s own wording: “Oracle NetSuite doesn’t check the suitability of the new date and time and isn’t responsible for any impact to your business.” Which is fair, and it means the responsibility for not scheduling your upgrade on top of month-end close, or the day your biggest customer’s PO drops, sits entirely with you. Look at your close calendar before you pick.
Most teams treat the upgrade date as weather. It’s a setting.
There’s a notification as well, and it’s worth ten minutes because most teams have it pointed at the wrong people without knowing. Setup > Company > Company Management > Administrative Notifications, then the Options subtab. Five notification types live there, each with its own recipient list. The one you want is Service Release Notifications, which Oracle describes as announcing the new version, your Release Preview access, and the date your account gets upgraded. One setting, both halves of the timeline.
Two defaults to look at while you’re in there.
Include Admins defaults to yes, which means the notification goes to whoever currently holds the Administrator role rather than to whoever owns release testing. Those are often not the same person, and on a long-lived account they’re often not even the same department.
⚠ Send Email appears to be off by default. If it is, then out of the box there is no email at all. The notification is delivered in-account, to the admins, where it sits next to everything else nobody reads. Which is a better explanation for why so many teams don’t know their upgrade date than a stale distribution list.
Add the people who actually need the date to Recipients, turn on Send Email, and that’s the last time an upgrade surprises you. Note that Recipients only accepts employee users and groups made up of employee users, so you can’t put a Customer Center or Vendor Center user on the list.
Two things people get wrong about the calendar.
Your sandbox is not a preview. Sandbox and production are upgraded on different dates, and you shouldn’t assume which comes first. Most practitioner accounts report sandbox landing a few days to a week after production, and at least one write-up of a recent cycle says the opposite. Either way, testing in sandbox before your upgrade tells you how the current release behaves, not the next one.
There’s a second reason that catches more experienced teams. Sandbox and Release Preview don’t lose the same things when they’re created. The sandbox list of what isn’t copied includes 2FA settings, integration records and inbound single sign-on mappings, none of which appear on the Release Preview list. So if you already have a tidy sandbox-refresh runbook, it won’t cover Release Preview, and the gaps it doesn’t cover are different ones.
Release Preview takes 5 to 7 calendar days to build after you request it. Deciding to test the week before your upgrade means you don’t get to test.
Getting a Release Preview account
Setup > Company > Release Preview, then Request Release Preview. You need the Administrator role, and you can request from production or from sandbox.
What you get is a copy of your production data, configurations and customizations, running the new version, at https://system.netsuite.com with your usual login. Switch to the Release Preview Administrator role, marked “RP” in the Change Roles list.
Two limits worth knowing now rather than later.
It gets purged after 14 consecutive days without a login. Request it, get busy, come back three weeks later, and it’s gone. Administrators do get notified by email of the pending purge about 24 hours in advance so they have a chance to log in to prevent the purge.
You cannot bundle changes out of a Release Preview account. Anything you fix in there, you fix again in production. This is by design. Which means the output of your testing is a written list of what to do on upgrade day, not a repaired account.
Getting everybody else in
This one eats the first morning of a lot of testing weeks, and nothing warns you about it. Your users don’t automatically have access to the Release Preview account even though they have access to production. You have to re-provision each one, and the procedure is stranger than you’d guess.
For one user, in the Release Preview account:
- Lists > Employees > Employees, click Edit next to the person.
- On the Access subtab, clear the Give Access box. Write down the roles they have first, because you’re about to need them.
- Save.
- Edit the same employee record again.
- On the Access subtab, check Give Access again and fill in what it asks for.
- Reassign their roles.
- Save, then tell them to log out and back in.
Off and on again, in two separate saves. That’s Oracle’s documented procedure, not a workaround.
For a group of people there’s a bulk route. Build an Employee search returning Internal ID and Give Access, export it to CSV, then Setup > Import/Export > Import CSV Records, with Employees as both Import Type and Record Type and Update in the Data Handling field.
Do this on day one, not on the morning you’ve booked your power users. Six people who can’t log in is how a testing week turns into a testing afternoon.
The first thing to do in a new Release Preview account
Before you run a single test, set the email preference.
Setup > Company > Email > Email Preferences, then the Sandbox and Release Preview Email Preferences subtab. Three options:
- Send Email To, which routes everything to addresses you name. This is the one Oracle tells you to pick, in an Important callout, for both sandbox and Release Preview.
- Send Email to Logged In User, which sounds safer than it is. Oracle warns that email generated from a web store isn’t sent to the logged-in user, so this option has a hole in it exactly where web store testing happens.
- Do Not Send Emails, which blocks everything.
Once you look for it, you can see Oracle worrying about the same thing everywhere else in the account. Every saved search arrives inactive, and Oracle’s stated reason is to cut down automatic email notifications. Email campaigns are capped at fewer than 25 recipients. Direct deposit, PayPal, and the UPS and FedEx integrations are all present but take no action. Credit card processing swaps your real card numbers for test ones. Oracle has fenced off the money and the bulk mail on your behalf, and left your transactional email to you.
What to test, and what not to
You are not expected to test the new features. You’re there to confirm your existing business workflows still work.
That’s the opposite of how most testing weeks actually get spent, and it’s the single biggest improvement available to most teams.
A reasonable split is most of your time on what you already run, and the remainder on anything new you actually plan to use.
The workflows that earn the time
Run them end to end, with real scenarios, not hypothetical ones:
- Quote to sales order to fulfillment to invoice to payment
- Purchase order to receipt to bill to payment
- Your month-end close sequence, including the reports the close depends on
- Anything with an approval routing on it
- Whatever your busiest team does forty times a day
The customizations that break quietly
- Scripts. User event, scheduled, client, Suitelets, map/reduce. Execution order changes, governance limits change, APIs get deprecated. A script that still runs is not the same as a script that still does the right thing.
- Workflows. Conditional logic can evaluate differently when a field it depends on changes.
- Saved searches and reports. Field references and joins shift, and a search that returns rows but the wrong rows is worse than one that errors.
- Integrations. Field IDs, authentication, timing. Tell your integration vendors the date, and ask them what they’re testing. While you’re at it, ask which ones authenticate with TBA, for the reason below.
- Anything reading a query that doesn’t specify a sort order. A release can change a default sort, and nothing errors when it does. 2026.2 changed the default for SuiteQL queries and Analytics datasets built on generic transactions, from transaction display name to transaction date. If a script or an integration takes the first row of an unsorted query, it is now taking a different first row. We’ve written that one up with the fix: SuiteQL gotchas.
- Bundles and SuiteApps. Third-party code on someone else’s release schedule.
Who should be in the room
Power users from each function, not just the administrator. The person who does accounts payable every day will spot a changed field on a bill in ten seconds. Somebody testing it from a script will not.
What you can’t test, and what won’t behave normally
Plan around this before you build the test plan, because a few of these will take a chunk out of your coverage and one of them changes how you test the thing most likely to break.
Not available at all
Five things simply don’t work in a Release Preview account:
- Payroll
- Outlook Integration
- Fax
- Intelligent Recommendations
- NetSuite Analytics Warehouse
Payroll is the one that hurts. If your close depends on it, that part of your close cannot be regression tested before the upgrade.
Available, but not the way you expect
| What | What actually happens |
|---|---|
| Scheduled SuiteScripts | Copied, but they don’t run on their own. Manual testing only |
| Direct Deposit, PayPal, UPS and FedEx, Alternative Payment Methods, Perquest | Present, but no action is taken. Nothing sends, nothing ships |
| Credit Card Processing | Your real card numbers are replaced with test numbers, and you must use test cards |
| SSN and TIN fields | Test numbers only |
| Email Campaigns | Fewer than 25 recipients |
| Token-based Authentication | New tokens must be created in Release Preview |
| SAML Single Sign-on | Must be configured manually |
| Website and Web Store | Domains must be set up manually, and must be unique across accounts |
| SuiteAnalytics Connect | Needs configuration changes for Release Preview |
| NetSuite Connector | Can’t connect multiple NetSuite accounts at once |
The scheduled scripts row deserves a second read, because it quietly rewrites the most common piece of release advice.
Everyone tells you to test your scheduled scripts. You can’t, not in the sense of watching them run. They come across and they sit there. Nothing fires on schedule, so you have to trigger each one by hand and reason about whether the timing would have worked.
Which means a scheduled script that breaks because of when it runs, rather than what it does, is invisible in Release Preview. It’ll surface on the first real execution after the upgrade. That’s an argument for the last row of the calendar below, and for treating the first scheduled run after go-live as a test rather than as business as usual.
What usually goes wrong
Release Preview looks broken, and isn’t
Several things are deliberately not copied from production, and the effect is an account that appears to have been wrecked by the upgrade. It hasn’t.
| What’s missing | What you’ll conclude |
|---|---|
| All saved searches are set to inactive by default | “The release broke every search we have” |
| Token-based authentication tokens aren’t copied | “The release broke all our integrations” |
| Workflow instances aren’t copied, and neither are SuiteFlow history logs | “The release killed every approval in flight” |
| SAML configuration isn’t copied | “We can’t even log in properly” |
| Customer Center roles aren’t copied | “Customer login is dead” |
| Websites and web store domains aren’t copied | “The web store is down” |
| Credit card processing profiles need their credentials re-entered | “Payments are broken” |
None of those are release problems. They’re Release Preview being a test account.
Three of them are real tasks rather than checkboxes, and they’re the three that decide whether your testing week covers anything that matters.
Tokens. This is why plenty of teams never test integrations at all. You have to create fresh tokens in Release Preview for every integration you intend to exercise, and integrations are where the expensive failures live.
Customer Center. Customer login doesn’t work in Release Preview even though it works in production, and standing it up takes a CSV import of customer records. If any part of your business depends on customers logging in, budget for that specifically, because it isn’t a setting.
Web store. You need to set up a domain in Release Preview yourself if you want to test a store, and it has to be unique across accounts, so you can’t reuse the production one. Combine that with the email preference warning above: a web store is the one place where Send Email to Logged In User won’t protect you.
Also not copied: system notes on records, and campaign response history. Fine for most testing, awkward if your test depends on the history of a record.
Scheduled scripts running twice, or at the wrong moment
Oracle’s own instruction: note the scheduled events running in production, disable them before the production account is upgraded, and re-enable them after.
That list is easy to write while you’re calm and miserable to reconstruct on upgrade morning. Write it during testing.
And write it knowing you couldn’t watch any of them run. Per the section above, scheduled scripts are copied to Release Preview but never execute on their own. So the list you’re building is the only artifact you get out of the exercise, which makes it worth more, not less.
The deadline that isn’t about this release
One item that belongs in your notes this cycle even though it doesn’t bite this cycle.
From the 2026.2 release notes: as of NetSuite 2027.1 you will not be able to create new integrations that use token-based authentication. That covers both the IssueToken endpoint and the three-step TBA authorization flow. Existing TBA integrations keep working past 2027.1, with final end of support tentatively 2028.1.
So nothing breaks now. What changes now is the cost of adding one. Any integration you were planning to build on TBA has a window, and any vendor who tells you their connector uses TBA has a roadmap question to answer.
The reason it belongs on a release readiness page rather than a roadmap page: you are already going to be in front of your integration list this cycle, creating fresh tokens in Release Preview for everything you want to test. That’s the cheapest moment you will ever get to write down which integrations use TBA and who owns each one. Do it while the list is open in front of you.
The upgrade window itself
Performance in Release Preview is often slow at first and improves as you use it. Oracle says so directly, so don’t file that as a defect on your first click.
And the things you’re most likely to discover late are the ones that only run at a period boundary. A release in September can look completely clean and still break something that only executes at quarter end.
A calendar that works
| When | What |
|---|---|
| As soon as the portlet shows your date | Check it against your close calendar. Reschedule now if it lands badly, while the good slots are still open |
| Same day | Request Release Preview. It takes 5 to 7 days to build |
| Day one in the new account | Set the Sandbox and Release Preview email preference. Before anything else. Then get your testers provisioned, because that takes longer than you think |
| 4 to 6 weeks out | Read the release notes and the Sneak Peek. Book time with your power users now, not later |
| 3 to 4 weeks out | Regression testing, mostly on existing workflows. Log in at least once every two weeks or the account is purged |
| 2 weeks out | Tell the users what’s changing. Confirm your integration vendors have tested |
| 72 hours out | Last chance to reschedule. After this the date locks |
| Before upgrade day | Disable scheduled events. Have the re-enable list written down |
| Upgrade day, plus 72 hours | Re-enable scheduled events. Smoke test the core workflows. Watch the first scheduled runs actually run, because this is the first time anybody has |
⚠ The 2026 exception: NetSuite Next
2026 is not a normal year for this. Alongside the usual .1 and .2 releases, Oracle is rolling out NetSuite Next, which includes a redesigned interface built on Oracle’s Redwood design system and an AI assistant called Ask Oracle.
Oracle’s own release page describes starting with a preview account to explore Ask Oracle and the redesigned experience, or going live right away, and notes that some of it is available to US and Canada customers first.
Two things follow, and they change what release readiness means this cycle.
A UI change is a training project, not a testing project. Your regression tests can pass completely and your accounts payable clerk can still be unable to find anything. Budget for that separately from the testing above.
An AI assistant answering questions about your data is only as good as the data. If your chart of accounts has duplicates, your item names are inconsistent, or your subledgers don’t tie to the general ledger, natural-language answers will be confidently wrong in ways a saved search never was. Cleaning that up is worth doing on its own merits and now has a second reason.
We’ve put what we found testing that in one place, including the report that returned three different answers to the same question, what a question actually costs in AI Units, and the three-setting control that decides who gets NetSuite Next and who doesn’t: what we learned before turning on Ask Oracle.
And on what these assistants do and don’t answer reliably: getting reliable answers out of the NetSuite MCP.
When to get help
Two honest signals that this is worth outsourcing.
Nobody owns it. Release testing fails most often because it’s nobody’s job, not because it’s hard. If you can’t name the person accountable for it, the testing isn’t going to happen, and that’s a scheduling problem rather than a NetSuite problem.
Your customizations outnumber the people who understand them. If the scripts were written by a consultant who has moved on, testing them means reading them first.
If neither applies, you can do all of this yourself, and this page is the whole method.
Coming up on a release date and not sure where to start? The first hour is free. Bring us your account and your date and we’ll tell you what we’d test first.