For NetSuite administrators and release managers
Retire the Release Preview
test plan spreadsheet.
Oracle gives you an .xls and a preview account that can't be refreshed and disappears after 14 idle days. Lastest records your saved searches, custom forms and SuiteFlow processes once, then diffs every screen between Release Preview and production.
The 2026.2 preview period is already running
Two releases a year. And you find out your date about three weeks ahead.
2026.2 production upgrades begin 7 August 2026 and run through 18 September 2026. Your exact upgrade date and time show up in the New Release portlet roughly three weeks before it happens, and account assignment is sticky, so your slot tends to repeat about every six months. Oracle is explicit that you are not expected to test the new features. Your job is narrower and harder: prove nothing you already rely on broke.
Work the Suggested Test Plan by hand.
Someone requests the RP account, waits 5–7 days for it to build, then opens ReleasePreviewTestPlan_Template.xls and starts clicking. Order entry, the invoice print, three saved searches, a custom form, the approval SuiteFlow. Rows get ticked. Half the plan gets shortcut because there are only so many hours before the upgrade lands.
- The RP account can't be refreshed during the preview period, and changes there never come back to production
- Purged after 14 consecutive days with no login — a quiet fortnight and the account is gone
- Scheduled SuiteScript can't be tested there at all — automated scheduled scripts only run in sandbox accounts
- Next release, the same person clicks the same 200 rows again, from memory
Record the process once. Replay it every release.
Walk each business process through your live account once while Lastest records it. That becomes a Playwright test in your repo and a set of screen baselines. When the RP account is ready, replay the pack against it and read the diffs: what moved, what renamed, what stopped rendering. Do it again the day after your production upgrade, and again for 2027.1.
- Runs inside your network — production and RP screens never leave your perimeter
- Visual, structural and perceptual diffs of the actual screen, not just an assertion that passed
- AI records the test once. Replay is deterministic — no model in the execution path
- Timestamped before/after evidence per screen, exportable for sign-off
- The same pack covers the sandbox pass, which is upgraded within 7 days after production
“Your team should have tested printing orders in the release preview before our production got upgraded.”
— a NetSuite practitioner to a peer, r/Netsuite
What gets baselined
Saved searchesCustom formsSuiteFlow screensSuiteScript-driven UISuiteApps / bundlesDashboard portletsTransaction print outputApproval routingBuilt for the Release Preview account
Oracle picks the date. You still own the proof.
Two things the Release Preview account makes hard, and how a recorded regression pack handles both.
01 · Record
Your business processes, captured before the Snapshot Date.
Record order-to-cash, the month-end saved searches, the custom forms your controllers live in, and the SuiteFlow approvals — against your live account, while it is still on 2026.1. Lastest emits plain Playwright tests into your git repo and a screen baseline for each step. Nothing about the recording is locked in our format, and nothing about replay depends on a model.
- Works against production, a sandbox after its refresh, or the RP account
- Tests you can read, edit and keep — no proprietary object repository
- The same pack replays for 2026.2, 2027.1 and every release after
02 · Diff
Release Preview against production, screen by screen.
Replay the pack against the RP account and compare each screen with its production baseline. A field that moved, a tab that got renamed, a saved search that lost a column, an invoice form that now prints one line lower — none of it throws an error, and all of it shows up as a diff. Each comparison is captured with a timestamp, so the record of what you tested exists without anyone maintaining a spreadsheet.
- Visual, structural and perceptual comparison of the rendered screen
- Approve expected changes; the rest stays flagged until someone looks
- Run it again the day after your production upgrade to confirm the live account matches
Release Preview questions, answered
- How long does it take to get a Release Preview account?
- You request it under Setup > Company > Release Preview, and Oracle builds it in roughly 5 to 7 days. That lead time is why teams that request the RP account in the same week the 2026.2 upgrades start often lose half their testing time waiting. Request early, then run a recorded regression pack against the account the day it lands.
- Why did our Release Preview account disappear?
- A Release Preview account is purged after 14 consecutive days with no login. It also cannot be refreshed with data from your production account during the preview period, and changes you make in it cannot be transferred back to production. Practically, that means the RP account is a read-and-verify environment on a clock, not a place to build anything you intend to keep.
- Can we test scheduled SuiteScript in Release Preview?
- No. Automated scheduled scripts can only be tested in sandbox accounts, not in the Release Preview account. So a complete regression plan spans both: user-facing screens, saved searches, custom forms and SuiteFlow steps in RP, and scheduled SuiteScript in sandbox. Sandbox accounts are upgraded within 7 days after production, so the sandbox pass happens after your production upgrade, not before it.
- Is Release Preview the same as a sandbox?
- No, and conflating them is the most common planning mistake. A sandbox refresh copies production data into a sandbox account; a Release Preview account is a separate, non-refreshable copy of your account running the next release. Different purposes, different upgrade timing, different limits on what you can test.
- When exactly does our account get 2026.2?
- Your exact upgrade date and time appear in the New Release portlet roughly three weeks ahead of the upgrade, and you can request a Customer-Scheduled Maintenance window for supported maintenance activity. Account assignment is sticky, so accounts tend to land in the same slot release after release, roughly six months apart. Practitioners talk about this as Phase 1, 2 and 3; the only date that binds you is the one in the portlet.
- What does Lastest actually diff?
- Screen-level visual, structural and perceptual diffs. Saved search results, custom form layouts, dashboard portlets, SuiteFlow-driven screens and printed or previewed transaction output. It compares what a user sees in the Release Preview account against the same screen in your live account, so a moved field, a renamed tab or a form that lost a column shows up as a diff rather than as a support case after the upgrade.
- Does anything leave our network?
- No. Lastest is self-hosted, so it runs inside your own network against your Release Preview account, and your NetSuite screens and record data stay on your infrastructure. The tests themselves are plain Playwright in your own git repo, which means you can read them, edit them and keep them.
- How does this compare to running the same regression on SAP or Salesforce?
- The mechanics are identical, because the underlying problem is identical: the vendor picks the date and you still have to prove nothing broke. Our pillar page on regression testing for vendor-set release dates covers the shared approach across SAP, Salesforce, Dynamics 365, NetSuite and Veeva.
2026.2 upgrades run
7 August to 18 September.
What's your scope?
Thirty minutes. We map your upgrade date from the New Release portlet to a concrete regression scope: which saved searches, custom forms, SuiteFlow processes and installed SuiteApps actually need a screen-level diff, what belongs in the RP account, and what has to wait for the sandbox pass. You leave with the scope whether or not you buy anything. Working across more than one vendor? The same approach for SAP, Salesforce, Dynamics 365 and Veeva is on our release testing pillar page.
Book a release-readiness review →# replay the recorded pack against the RP account
$ lastest run --suite netsuite-o2c --target release-preview
✓ sales order entry — 14 screens, no diff
✓ approval SuiteFlow — 9 screens, no diff
! invoice print preview — 1 screen, layout diff
! saved search: open AR — column order changed
evidence written to ./artifacts/2026.2/ · 24 screens · timestamped