Short answer: three things decide whether a release costs you an afternoon or a week. Getting a sandbox onto the preview track before the refresh deadline, reading your own org’s Release Updates page instead of a summary, and testing integrations rather than screens. Everything else in release preparation is optional, and most teams do the optional parts instead.
The shape of the cycle, which does not change
Three releases a year, each following the same sequence. The dates move. The order never does.
- Pre-release org available. A throwaway org on the new release, weeks ahead. Useful for looking at a specific new feature, useless for testing your own configuration, because your configuration is not in it.
- Release notes published, roughly five to six weeks before the first production weekend.
- Sandbox preview window opens, with a hard refresh cutoff a day or two before. This is the date that matters most, and it is the one that gets missed.
- Production release weekends — three of them, spread over about five weeks. Your instance is in one of them, and you do not choose which.
Get your own dates from Salesforce Trust, Maintenances tab, filtered to your instance. Not from a blog, including this one: instances differ, and the only date that matters is yours.
For Winter ’27, the preview window opened on preview-track sandboxes in late August 2026 and production upgrades run across September and October. Check Trust for your instance rather than working from that sentence.
The preview sandbox decision, made once
A sandbox is on the preview track or it is not, and the difference is decided by when it was created or last refreshed relative to the cutoff. Miss the cutoff and your sandbox stays on the current release, which means you cannot test the next one at all. There is no way to fix that after the fact.
So the standing arrangement worth setting up: one sandbox that exists to be on the preview track, refreshed before every cutoff, and not used for anything that a refresh would destroy. Put the cutoff dates in a shared calendar for the whole year, from Trust, in one sitting.
The trap is using your main development sandbox for this. Refreshing it wipes work in progress, so somebody always argues for delaying the refresh, and that argument is how a team ends up with no preview environment in the one release that breaks something.
Read your own org’s list first
Every release summary you can read, including ours, is generic. Your org’s Release Updates page in Setup is specific: what is being enforced, when, and what it changes for you.
Start there, sort by enforcement release, and triage. We wrote up the triage in the Release Updates that actually break things — the short version is that authentication, access, timing and validation changes need testing, and everything else needs a read.
Then, and only then, read the release notes for the features you care about. Doing it in that order means the mandatory work gets the attention while you still have a testing window.
Test integrations, not screens
Most release-preparation plans test the user interface, because that is what is easy to look at. Most release incidents happen to integrations, because nothing is watching them.
A test plan that catches real problems, in priority order:
- Every integration authenticates. From where it normally runs, as the user it normally uses. This one check catches the entire authentication-retirement category.
- Every integration completes a real transaction. Inbound and outbound, with a payload from production, not a clean sample.
- Your automation’s timing assumptions. Anywhere code writes something and immediately reads it back.
- Access, for two or three real profiles. Log in as those users, count what they can see, compare to before.
- Your test classes. They will find compile-level breakage from platform changes, which is a small category but a cheap one to check.
- The screens people use most. Last, and briefly.
Reverse that order and you get the plan most teams run, which is why the surprises are always integrations.
A four-week rhythm that fits around real work
When the notes publish: read your Release Updates page, triage it, and book the testing time. An hour.
Preview week: refresh or confirm the preview sandbox. Run the integration checks. Activate the updates that pass. Half a day, and it is the half day that earns everything.
The week before your production date: fix what the preview found, and tell the business what is changing in words they use. Nothing technical.
The Monday after: re-run the integration checks in production, and read the error emails from the weekend before someone else reports them. An hour.
That is about a day per release, three times a year. Teams that skip it do not save the day — they spend it in an incident, at a worse time, with an audience.
What I have stopped doing
Reading the release notes end to end. They are enormous, most of it does not apply, and the important mandatory changes are on a different page anyway. Read your Release Updates list in full, then read only the note sections for products you actually use.
Writing a long internal summary for the business. Nobody read it. Three bullets in a message on the day, plus a heads-up about anything that changes a screen people use hourly, lands better and costs twenty minutes.
Frequently asked
Can we skip a release? No. Major releases apply to every org on the schedule Salesforce publishes.
Do we need a full sandbox for preview testing? No, and a full sandbox has other trade-offs. What you need is a sandbox on the preview track containing enough configuration and integration wiring to be a fair test.
What if we find a genuine regression in preview? Raise a case during the preview window, with reproduction steps from the preview sandbox. That timing is the strongest position you will ever have — the same case after production upgrade is a support queue rather than a pre-release fix.
Is the pre-release org worth signing up for? For looking at one specific new feature, yes. For testing your org, no. It contains none of your work.
