Testing NetSuite’s twice-yearly upgrades in the Release Preview window

NetSuite customers do not decide whether to upgrade. Oracle upgrades every account to each scheduled version, twice a year^[1]. What you do control is whether you have tested your own processes on the new version before it reaches production. The only place to do that is the Release Preview account, and it is open for a limited time. This guide covers how long the window lasts, what behaves differently inside it, and a plan that fits the small teams most NetSuite shops run.

The calendar, and why it is tighter than it looks

Versions are named by year and half: 2026.2 is rolling out now and 2027.1 is next. Oracle calls each one of two scheduled version upgrades a year. It also says further enhancements may now arrive in monthly minor releases between them, and SuiteApps follow their own schedules^[1]. One partner reports that 2026.2 production upgrades run on a rolling basis from August through October 2026^[13]. Your own date is in the New Release portlet. Regardless of service tier, you can move it through Customer-Scheduled Maintenance^[8].

The trap is the sandbox. Oracle upgrades it within seven days after production^[8], so the sandbox cannot preview the new version. Release Preview is the only way to see it before production does.

An Administrator requests the account from Setup > Company > Release Preview. The request can come from production or from a sandbox, and if you want a particular sandbox’s data and customizations, you request it from that sandbox^[2]. The data comes from a backup copy taken after the request^[2]. Oracle’s stated purpose is narrow and useful: test your existing business workflows. You are not expected to test the new features^[2].

What behaves differently in Release Preview

Release Preview is not a perfect copy of production. Oracle lists several differences, and each one becomes a test you skip by accident unless you plan for it:

Three of these deserve emphasis. First, Oracle says automated scheduled scripts can only be tested in sandbox accounts^[4]. So every scheduled and map/reduce script is two tests: run it by hand in Release Preview, then confirm it runs on schedule in the sandbox after the sandbox upgrade. Second, integrations do not work until someone re-creates their tokens or SAML setup^[5]. That is exactly why they get skipped, and why they then fail on upgrade day. Third, third-party SuiteApps need their vendor’s help. Oracle recommends telling each vendor your Release Preview dates, and managed bundle upgrades must be installed by hand^[7].

A plan a small team can run

Oracle’s suggested test plan covers business workflows, custom reports and forms, other customizations, SuiteScript deployments, SOAP integrations, installed SuiteApps, the web store and SuiteAnalytics Connect^[6]. For each business workflow it asks for a name, the role to test with, a test email address, the navigation steps and the expected results. Oracle also offers an Excel template to record them^[6]. For scripts, it suggests exporting Customization > Scripting > Script Deployments to a spreadsheet and using it as your checklist^[14]. That is a good skeleton. With a team of two or three, here is how I would fill it in:

1. Before the window opens: keep an inventory of what can break: scripts, SuiteFlow workflows, saved searches and datasets that integrations read, forms, SuiteApps and integrations. Rank them by business risk and change frequency.
2. Day one: set the Release Preview email preference to a test mailbox, which you do in production^[5]. Then grant testers access (at first only Administrators can log in^[3]), re-create integration tokens and SAML, and activate the saved searches you need.
3. First week: run your top 15 to 25 business workflows by risk. Order to cash, procure to pay, bank reconciliation and period close usually lead the list. Run them as the customized roles your users actually hold.
4. Second week: reconnect and run every integration, run each scheduled process by hand, and check the SuiteApps with their vendors.
5. Before the decision: compare roles with Show Role Differences and export the result. You need the Bulk Manage Roles permission, and Oracle advises comparing fewer than 100 roles at a time^[11]. Report defects to Support from the Release Preview account^[2].

Do not test as Administrator. NetSuite requires two-factor authentication for Administrator and other highly privileged roles in every account type, including Release Preview. Roles that require it cannot use user credentials for API access^[10]. Logins and integration authentication are therefore part of the regression scope every time.

Read the release notes for changes that break quietly

Most release-note items add things. A few change behavior you rely on. In 2026.2, SuiteQL queries and analytics datasets with no sort order now sort by transaction date instead of document name^[1]. Nothing fails, but an integration or report that assumed the old order produces different output. The same notes set dates for authentication. As of 2027.1, integrations that use NLAuth stop working, no new token-based authentication (TBA) integrations can be created, and new OAuth 2.0 authorization code integrations must use PKCE. Full TBA end of support is tentatively 2028.1^[1]. Separately, Oracle will remove SOAP web services in 2028.2, when existing SOAP integrations stop working^[12]. If any of your integrations use these methods, every upgrade between now and then needs an integration test plan with the migration in it.

The week after: sandbox refreshes and the rest of the year

Upgrade season is also when sandbox refreshes go wrong. Oracle says a refresh fails if it does not finish before your scheduled upgrade starts. If the upgrade is 72 hours away, wait until production and the sandbox have both been upgraded^[9]. If you upgrade a sandbox ahead of production and then refresh it, the sandbox goes back to the production version^[9]. My advice: freeze refreshes from the day Release Preview opens until the sandbox upgrade is done. Then refresh, if you need to, and use that week to confirm your automatic schedules.

After that, the work does not stop until the next Release Preview notice. Monthly minor releases and SuiteApp updates arrive in between^[1], and so do your own changes. A small regression suite that you run monthly costs less than a large one you rebuild twice a year: the top workflows by risk, every integration and a role comparison. The two scheduled upgrades then become a larger version of a routine you already have, not a project you restart each time.

Making the call

Oracle also asks you to note the scheduled events that run in production, turn them off before the upgrade and turn them back on afterwards^[6]. Put that list in your runbook next to the decision. Then decide on evidence: high-risk workflows passed with real roles, integrations reconnected and passed, scheduled processes run, and failures fixed, raised with Support or accepted in writing by the process owner. If a high-risk workflow fails and there is no fix, move the upgrade date. Oracle reserves four hours for the upgrade itself^[8]. Plan a production smoke test straight after it, and a role comparison once it is done.

The free NetSuite Release Preview Test Plan works out your test window and purge date and tracks workflows, setup and scheduled processes. The Customization Regression Inventory ranks what to test and flags integrations against the 2027 and 2028 deadlines. The Role & Permission Test Matrix covers the role tests.