Major Release
A Major Release is one of the three platform-wide upgrades Salesforce ships every year, named after the seasons: Spring, Summer, and Winter.
Definition
A Major Release is one of the three platform-wide upgrades Salesforce ships every year, named after the seasons: Spring, Summer, and Winter. Each one adds new features across every Salesforce product, changes or retires older behavior, and refreshes the platform that runs under your org. Every customer moves to the same version automatically on a published schedule, so a major release is the shared upgrade clock that the whole Salesforce ecosystem runs on.
A major release is not a download or an install. Salesforce upgrades your instance during a short maintenance window (often around five minutes), and your org wakes up on the new version. The work for admins and developers happens before that, during the sandbox preview period. That is when teams read the release notes, test against the new code, train users, and clear any changes that Salesforce will enforce automatically later.
How the Salesforce release machine works
Three seasons, one shared version
Salesforce delivers new features three times a year through its seasonal releases: Spring, Summer, and Winter. Production orgs are upgraded around February, June, and October. Each release is versioned by year, so you will see names like Spring 26, Summer 26, and Winter 26 in the release notes and in your org. The point of the seasonal model is that everyone runs the same version. There is no long-term version fragmentation the way there is with on-premise software, and there is no opt-out. A small clinic and a global bank on the same product get the same Spring 26 features. Salesforce calls this automatic, identical delivery one of the advantages of the multitenant cloud. The upgrade itself is brief, sometimes only a few minutes of maintenance, because the new code already lives on the instance and the upgrade flips your org onto it. The features land first in Lightning Experience, not Salesforce Classic, which is one more reason mature orgs keep moving toward Lightning. Knowing the three-times-a-year rhythm lets a team plan training, testing, and freezes around dates that are published as much as a year ahead.
Sandbox preview versus production
The most important date in any release is not the production upgrade. It is the sandbox preview. Salesforce upgrades preview sandbox instances roughly four to six weeks before production, in the months of January, May, and September. That gap is your window to test. You refresh or create a sandbox that sits on a preview instance, point your integrations and test scripts at it, and confirm that nothing breaks on the new version. Not every sandbox is a preview sandbox. Instances are split into preview and non-preview groups, and only the preview group gets the early upgrade. Non-preview sandboxes stay on the current version and move at the same time as production. Picking the wrong sandbox is a common mistake, because a team thinks it is testing the new release when it is still on the old one. Salesforce publishes which instances are preview ahead of every release, and you can confirm your sandbox instance in its details. If you miss the preview refresh deadline, the sandbox moves with production and you lose your early test runway for that cycle.
Release notes are the contract
For each major release, Salesforce publishes detailed release notes on Salesforce Help, usually several weeks before the preview sandboxes upgrade. The notes are the closest thing to a contract for what is changing. They list every new feature, every changed behavior, every deprecation, and which editions and clouds each item affects. The notes are large, so teams do not read them cover to cover. Instead they filter to the products they actually use, then scan for anything marked as enabled by default or as a change to existing behavior. Those are the items that can move your org without anyone clicking a button. A useful habit is to search the notes for the objects, features, and APIs your org depends on, and to flag anything that touches a customization you own. The release notes also call out items that are generally available versus beta, which matters because beta features can change or disappear before they are fully released. Reading the notes early is what turns a release from a surprise into a plan.
Release Updates and enforcement deadlines
Not every change in a release is optional. Salesforce uses Release Updates to manage behavior changes that will eventually apply to every org whether or not you act. You find them in Setup under Release Updates, where each one shows what is changing and an enforcement date. Salesforce usually introduces an update in one release and enforces it one or more releases later, which gives you time to test and adapt. A Spring 26 example was the move of Blob.toPdf to a new rendering engine, surfaced for testing with enforcement set for a later release. If you ignore a Release Update, it does not go away. On the enforcement date the new behavior turns on by itself, and any code or configuration that depended on the old behavior can break silently in production. The safe pattern is to treat each Release Update as a dated task. Review it in Setup, test the new behavior in a preview sandbox, and either adapt your customization or confirm you are unaffected before the deadline. This is where most release-related production incidents come from when teams skip the preview window.
Per-instance schedule and the Trust site
Two orgs do not always get the release on the same day. Salesforce rolls a major release out instance by instance over a set of weekends, so the exact production date depends on which instance your org lives on. The authoritative source for your date is the Salesforce Trust site, status.salesforce.com, which publishes the major release maintenance schedule and lets you look up your instance. Production windows are typically scheduled at off-peak hours for the instance, and the maintenance itself is short. Knowing your specific instance date matters for planning. It tells you when to finish preview testing, when to schedule a code freeze, and when to have support staff ready in case users notice changed behavior. Teams on different instances may sit a week or two apart within the same release wave, which is worth remembering when you coordinate with partners or with other business units that run separate orgs. The Trust site is also where you confirm that a release window has completed, rather than guessing from inside the org.
Major releases versus patches
Major releases are the big, scheduled, well-documented upgrades, but they are not the only changes Salesforce ships. Between the seasonal releases, Salesforce delivers patch releases, point releases, and security fixes on a per-instance basis. These smaller updates usually do not come with the full release-notes treatment or a preview window, because they are meant to fix and harden rather than introduce sweeping new functionality. The mental model is simple. A major release is the planned, feature-bearing event you prepare for over weeks. A patch is a maintenance update that keeps the platform stable and secure in between. Both are automatic and both are delivered through the instance, but only the major release changes your operational calendar. For developers, the API version also advances with major releases, so new Apex and metadata capabilities are tied to a version number such as v66.0. Pinning components to a specific API version is how you keep behavior stable even as the platform underneath continues to move forward release after release.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Major Release.
Hands-on resources to go deeper on Major Release.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. How many Major Releases does Salesforce ship to every customer org in a calendar year?
Q2. During a Major Release rollout, where do customers first get the new version so they can test before production?
Q3. What does Salesforce publish weeks ahead of each Major Release so admins can plan adoption?
Discussion
Loading discussion…