The date you cannot move is October 12
Salesforce puts the next major release in front of every customer on the same day. The newsroom post published on August 31, 2026 states that "The Winter '27 Release is generally available October 12, 2026." Nothing an admin does in Setup changes that date. Summer '26, release 262, is what your users see today. Winter '27 is release 264, and it arrives whether or not your regression pack has been run.
The planning problem sits earlier in the calendar. Salesforce Help documents the sandbox preview cutoff as "6:00 PM PT on August 27, 2026", with preview instances upgraded on "August 28 and August 29, 2026" and non-preview instances upgraded on "October 9 and October 10, 2026". A team on a non-preview instance receives the new release two or three days before general availability, which leaves no useful room to test anything.
If you are reading this in late September with an untested org, your options narrowed weeks ago. Knowing which ones remain is worth the ten minutes it takes to check where each sandbox actually lives. We covered what Salesforce said when it set the Winter '27 date at the end of August, and it has not moved since.
Three seasons, and one of them lands in October
The cadence is stable enough to plan a year around. Salesforce puts it plainly: "You'll typically see Spring in February, Summer in June, and Winter in October." A Salesforce Help article gives the same three seasons and the same three months. The scheduling documentation says "Major release maintenance occurs three times per year", with dates communicated "approximately one year in advance on status.salesforce.com".
The number that decides your quarter is the gap between sandbox preview and general availability. Preview instances were upgraded at the end of August and the release lands on October 12, so a preview sandbox gave a team roughly six weeks with the new code in an environment it controls. That gap is the regression budget, and it is the same six weeks for the org with four admins as for the org with forty.
Salesforce documents a North America production window of Friday 8:00 pm to Saturday 2:00 am Pacific time. Instance-level dates live on Salesforce Trust Status under the Maintenances tab, which is where Salesforce directs customers to find the next release's milestones, meaning sandbox preview, release weekends and upgrade windows. Read those off the Trust site for your own instance rather than from any article, this one included.
There is a good reason to prefer the Trust site over the general documentation. A Salesforce Help article describes sandbox preview instances upgrading in January, May and September, while the Winter '27 preview ran on August 28 and August 29, 2026. The general rule and the published dates for this release do not line up, and the published dates are the ones your sandbox followed.
The sandbox rule that catches teams out
Salesforce Help states the governing rule in one sentence: "The only way to change the upgrade status of a sandbox is to move it to another instance by refreshing it." A sandbox sits on a preview instance or it sits on a non-preview one, and no setting, support case or admin permission changes which. The status came with the instance and stays until the sandbox is replaced.
Refreshing is the part that hurts. A refresh drops the current contents and copies production again, so anything living only in that sandbox goes with it. Half-finished flows, test data built up over months, a permission set tuned since spring, the integration user credentials your middleware points at. Plenty of teams meet the rule and the cost of the remedy in the same afternoon.
Refresh intervals differ by sandbox type, so confirm from the sandbox list in your own org what you can refresh and when. A refreshed sandbox also needs its users, permissions and connected apps put back before anyone can run a test, which makes it a sensible moment to work through a proper permission audit rather than recreating whatever was there before out of habit.
What a September discovery actually looks like
The common version runs roughly as follows. A release manager asks the admin team to load the regression pack into the main test sandbox in the third week of September and learns that the sandbox is still running Summer '26. The sandbox was never on a preview instance. Nobody chose that, and nobody has looked since the day it was created, possibly three years ago.
From there every choice is imperfect. Refresh onto a preview instance and lose whatever the sandbox held, which means rebuilding test data before a single script runs. Test in a second sandbox that sits on a preview instance, accepting a thinner copy of production that will miss anything depending on volume or real integration wiring. Or let the release reach production untested and plan a verification pass for the first working morning after.
Most teams take the third option and call it monitoring. That can be defensible for a lightly customised org whose owners have read the notes and found nothing touching their configuration. It is a poor call for an org with heavy Apex, managed packages pinned to particular versions, or integrations depending on specific API behaviour. Either way the decision belongs to whoever signs off change, not to the admin who found the problem on a Tuesday.
The fix for next season is dull and it works. Decide which sandbox is the release-testing sandbox, confirm which instance it sits on, and record that beside the rest of your release checklist for shared solutions. Checking takes a minute in June and removes the entire argument in September.
Mandatory upgrades are the deal you signed
Salesforce answers the deferral question directly. Asked whether a customer can choose the timing, the Help documentation says "No, upgrades are scheduled according to the Salesforce release calendar". Asked whether the upgrade can be avoided, it says "No, automatic upgrades are mandatory as outlined in your Salesforce contract". There is no polite escalation path behind those answers and no account executive who can grant an exception.
Reading that answer as a grievance misses what it buys. One codebase for every customer is why a support engineer can reproduce your problem, why a consultant who has never seen your org can still guess what is wrong, and why the documentation matches what you see on screen. Orgs sitting three versions apart would each need their own answers, and everyone would pay for that in support time.
The cost lands on the calendar rather than on the invoice. Your regression window is set by a schedule someone else publishes, and the work is fitting testing into it rather than arguing with it. When the notes arrive faster than anyone can read them, our piece on a better way to read change notes covers how to cut them down to what your own org can be affected by.
The checks worth doing before October 12
Start with the instance. Open the sandbox list for every org you own, confirm against Salesforce Trust Status which instance each one runs on and whether it was in the preview group, and record the answer where the team can see it. If your main test sandbox is not on a preview instance, make the refresh decision this week rather than in October, because a refresh plus a test data rebuild is not a two-day job.
Then read the notes inside your own org rather than in the abstract. Salesforce ships Release Updates, and the list that matters is the one your org shows you. We could not load the release notes pages while writing this, so nothing here describes how those updates behave, and the list in your own Setup is the only place to work from.
Last, put a name against the weekend. Someone on your side should be awake for the first business morning after the upgrade, holding a short list of what the business would notice first if it broke. The integration jobs, the nightly data load, the login path for partner users, the two reports leadership opens before the Monday meeting. Write that list while it is still a planning exercise, and keep our Salesforce Platform coverage open for the rest of the release.
