Salesforce Winter ’27 sandbox preview: plan before 27 August

Salesforce has published the sandbox preview timetable for Winter ’27. The important operational date is 27 August 2026: to receive the early Winter ’27 upgrade, a sandbox must be active on a preview instance by the cutoff. Preview instances are then scheduled to upgrade on 28 or 29 August, while non-preview sandboxes remain on Summer ’26 until 9 or 10 October.

This is not a reason to refresh every sandbox. It is a reason for platform owners to decide which environments should move early, which should remain aligned with current production and what evidence the business needs before the production release. The dates and platform behaviour below are confirmed by Salesforce. The planning approach is Ostrelis guidance for operating the release safely.

What Salesforce has confirmed

Salesforce describes the sandbox preview as a roughly six-week period in which sandboxes on preview instances receive the next release before production and non-preview environments. For Winter ’27, the early upgrades take place on 28 and 29 August 2026. The later upgrade for non-preview sandboxes is scheduled for 9 and 10 October.

A sandbox’s Release Type shows whether it is currently preview or non-preview. Salesforce says that most existing preview sandboxes need no action. If a non-preview sandbox needs Winter ’27 early, it must be refreshed early enough for the request to complete before 6:00 PM Pacific Time on 27 August, which is 01:00 UTC on 28 August.

The completion time matters. Submitting a refresh just before the cutoff is not enough if the copy has not completed. Salesforce also warns that refreshing a preview sandbox after the cutoff routes it to a non-preview instance, taking it back to Summer ’26 for the remainder of the preview window.

Start with an environment decision, not a refresh request

For each sandbox, record its purpose, owner, current Release Type, significant work in progress and whether it should receive Winter ’27 early. A simple environment register is enough. The useful distinction is not “new release good, old release bad”; it is what each environment needs to prove.

At least one representative preview sandbox is normally valuable for testing the next release against your configuration. A non-preview sandbox can also be useful where a team needs an environment that matches production during the preview period—for example, to support a live incident, finish a release already in flight or compare behaviour between versions.

A mature estate may therefore need both. Smaller organisations may only have one suitable sandbox and will need to prioritise. Make that trade-off explicit with the platform owner and delivery teams rather than allowing refresh timing to decide it accidentally.

Treat a sandbox refresh as a destructive change

Salesforce’s guidance is clear that activating a replacement sandbox created through Refresh deletes the sandbox being replaced. Its current configuration and data are erased. Before refreshing, identify anything that exists only in the sandbox: uncommitted metadata, test records, integration endpoints, credentials or certificates, scheduled work, email settings, test users and evidence required by an active project.

Move source-controlled configuration into the agreed repository and branch. Export irreplaceable test data where that is appropriate and permitted. Record environment-specific settings that will need to be reapplied, and confirm who will complete post-refresh tasks. Do not copy secrets into tickets or general documentation; use the organisation’s approved secrets-management route.

Refreshing can also disrupt other teams. Check release calendars, user acceptance testing, training, integration testing and defect investigation before changing an environment. A short cross-team confirmation is less costly than discovering afterwards that the only reproducible test case has disappeared.

Build a risk-based Winter ’27 test plan

The preview window is most useful when the test scope exists before the upgrade. Avoid trying to test every page and field equally. Start with business-critical journeys and platform features where a release change would be costly or difficult to detect.

Core user journeys: test the actions that generate revenue, serve customers, create regulated records or support important reporting. Include realistic user profiles and permission sets rather than testing only as a system administrator.

Automation: run representative Flow, Apex, approval and scheduled-processing scenarios. Cover positive, negative and boundary cases, and review error-routing arrangements before starting.

Integrations: exercise inbound and outbound connections, authentication, API calls, middleware mappings and Microsoft dependencies. Confirm that monitoring distinguishes an application fault from a preview-environment issue.

Security and access: check login routes, single sign-on, MFA behaviour, connected applications, delegated administration and high-risk permissions. Include service accounts and integration users in the inventory even when they do not use the user interface.

Reporting and communications: verify important reports, dashboards, subscriptions, email templates and customer-facing messages. Visual differences matter when they change how users interpret or complete work, not merely because a screen looks different.

For every test, record an owner, expected result, evidence and defect route. Where practical, establish the Summer ’26 baseline before the preview upgrade. That makes it easier to tell a Winter ’27 regression from a pre-existing problem.

Use the six-week window as an operating cycle

Salesforce recommends finding release dates and planning backwards. In practice, the platform team should set a small number of checkpoints:

• Before 27 August: agree the environment map, protect work in progress, complete any necessary refresh early and prepare the test pack.
• After the preview upgrade: confirm the sandbox version and complete a short smoke test covering login, critical automation and integrations.
• During September: run risk-based regression tests, review relevant release notes and triage findings with clear owners.
• Before the October production upgrade: close or mitigate material defects, brief support teams and users, and confirm the production validation plan.

Keep release-note review connected to the org. A long list of new features is less useful than a short assessment of which changes apply, whether they are automatic, what must be enabled and who owns the decision. Record confirmed Salesforce behaviour separately from internal choices and assumptions.

Questions business stakeholders should ask

Business stakeholders do not need to manage instance placement, but they should be able to ask for a clear answer to five questions: Which sandbox will receive Winter ’27 early? What critical processes will be tested? Which teams could be affected by a refresh? How will significant findings be escalated? What must be complete before production upgrades?

If those answers do not exist, the issue is not simply release administration. It is unclear platform ownership. The sandbox preview provides a useful deadline for correcting that without turning the exercise into a large programme.

The Ostrelis view

The most valuable outcome is not a completed release checklist. It is evidence that the organisation understands its environments, critical dependencies and decision owners. A preview sandbox supports that work, but it cannot replace source control, representative testing, integration monitoring or accountable change management.

Ostrelis can help teams map the sandbox estate, prepare a proportionate test plan, review release impacts and provide ongoing operational support. See our Salesforce administration service, managed Salesforce support and approach and experience.