15.3 Release Cycles and Release Preview

Two major releases, plus smaller updates

Help states that NetSuite has two major releases each year. Customers are upgraded in phases over a few months, so one production account can move before another. NetSuite Version 2026.2 is one of those two scheduled version upgrades. Between them, a minor release fixes customer-reported issues that should not wait for the next major release, and every customer receives that minor release at the same time. A hot push fixes a critical issue that cannot wait, usually for a specific customer or set of customers. SuiteApps can ship on their own schedule, separate from the core upgrade and from monthly minor releases.

Release Preparation tells administrators to get ready for those two major releases with a short list of jobs. Review the release notes and monitor the New Release portlet. Find the latest release news and training in SuiteAnswers. Build tests for the business processes the company cannot afford to break. Log in to Release Preview several weeks before the upgrade date. Notify users, using the administrative notification options Help describes for a service release. Report issues you find while testing, and report them from the Release Preview account.

Sneak Peeks, available from the What's new in the Suite portlet and from the Help home page, preview features planned for the upcoming release. Read them early so a changed screen is not a surprise on upgrade day. The practical habit is the same every cycle: read the release notes, test critical transactions in Release Preview, and do not assume every production feature exists in the preview account.

What Release Preview is, and how you hear it is ready

Release Preview is available twice a year, right before each release, for customers with a production account. Use it to verify that existing workflows still behave as expected on the new release, with your data and customizations. The Release Preview guide says you are not expected to test the new features for NetSuite. Test the processes you rely on, including where a new feature changes one of those processes, and find breaks before the phased upgrade reaches production.

An administrator opts in from production, or from a sandbox when that sandbox should be the source. Go to Setup > Company > Release Preview and click Request Release Preview. Then watch Account Status and Account Notifications. The preview is built from a backup copy. Help says creation takes about 5 to 7 calendar days, and the wait also depends on account size, integrations, and how many other customers request a refresh at the same time. The snapshot copies configurations, data, user passwords, and customizations, with the exceptions listed later in this section.

Help sends Release Preview availability details to administrators and posts them on the New Release portlet. The Administrator role receives an email when the account is ready, and in-account notices go out as well. Initially only that role can log in, at system.netsuite.com, by switching to the Release Preview Administrator role and then granting access to testers. Users with access can also open the account from the New Release portlet.

The account stays available until the source account is upgraded, or until 14 consecutive days pass with no login, in which case it is purged. The date access ends is listed in the New Release portlet. Saved work is deleted with the account and is not copied to production. The first run of a transaction can be slower than production, and later repetitions are usually faster. Keep daily business in production.

Prepare the test, then run the transactions that matter

Download the Release Preview Test Plan Template, ReleasePreviewTestPlan_Template.xls, and adapt the testing matrix to your workflows. Note the scheduled events that run in production. Help says those scheduled events should be disabled before the production account is upgraded and enabled again after the upgrade is complete. That note is about the production cutover, and it belongs on the same checklist as the preview tests.

When a test fails, report it from the Release Preview account, using the steps in How to Report Release Preview Issues. Do not close the gap by editing only production and assuming the preview was mistaken. After your production account is upgraded, run the same critical transactions again in production. The preview account is gone by then, and the phased upgrade is the moment the live data meets the new version.

Test the transactions the company cannot afford to break: an order through billing, a vendor bill through payment, and a custom record that a workflow or client script touches. Run scheduled scripts and scheduled workflows by hand. Help says they are copied into Release Preview but do not run automatically. Automated scheduled scripts, on their own schedule, are tested in a sandbox. Because 14 days without a login can purge the preview, put the test window on a calendar when the administrator email arrives.

Features you cannot assume are present

Only modules you have purchased and enabled in production are available in that Release Preview. Even among those modules, Help splits features into full testing, limited testing, and not available. The October 2024 sample asked which feature is unavailable in Release Preview and keyed Payroll. The other choices on that item were email campaigns, two-factor authentication, and memorized transactions. Current Help, on Features Available for Testing in Release Preview, still lists Payroll as not available for testing. The same not-available list also names:

• Fax
• Intelligent Recommendations
• NetSuite Analytics Warehouse (NSAW)
• Outlook Integration
• Payroll

While Payroll stays on that not-available list, a payroll batch is not a valid Release Preview test. Email campaigns can be tested when they have fewer than 25 recipients. Two-factor authentication settings are shared with the related production account, so users do not rebuild them. Memorized transactions can be fully tested, and they start running only after the first login to Release Preview. Those three are available, with those limits, which is why they were not the keyed answer.

Other limits explain a preview result that disagrees with production. Real credit card numbers are replaced with test numbers. Help's example is 1111111111111117, used with a valid expiration date. Real Social Security numbers and tax identification numbers are not copied. SAML configuration is not copied, and token-based authentication tokens are not copied, so you recreate those in the preview if you need them. Web store domains are not copied. Each account, including each Release Preview, needs its own domain. Saved searches that drive email are set inactive in Release Preview. Several payment and shipping integrations are present with a testing note of no actions taken. Read that note before you treat a missing email or payment as a defect.

Help also documents a development account. The comparison this objective tests is the three rows above: production for daily business, sandbox for a copy of the current version, and Release Preview for the next version.

When the portlet appears, read the notes in SuiteAnswers and the Help Center version topic, request Release Preview if it is not already requested, and test the transactions that post to the general ledger or fire the customizations you depend on. File preview issues before the phased upgrade reaches production, then confirm those transactions in production after the upgrade. The preview account ends when that upgrade happens.

Practice the release and support items in the Oracle NetSuite Foundation practice questions.