There is no single correct salesforce sandbox refresh cadence. Full copy sandboxes used for UAT typically need a refresh every 4 to 8 weeks tied to a release cycle, while partial and developer sandboxes can run for months without one. The mistake most teams make is picking one calendar date for every sandbox type instead of watching what the data and the config actually tell them.
A refresh isn't the same job as masking sensitive fields or seeding realistic test data, though the three tasks usually happen back to back. Cadence is about timing: when do you pull a new copy from production, and how do you decide that moment instead of guessing. Get the timing wrong and you either burn engineering hours on stale-data bugs or wipe out weeks of unmigrated config every time IT pulls the trigger.
What Refresh Cadence Actually Means for Salesforce Teams
Refresh cadence is the interval between pulling a new snapshot of production data and metadata into a sandbox. It sounds simple until you notice how many teams treat it as a fixed quarterly ritual rather than an engineering decision. Quarterly refresh schedules are usually inherited from a compliance checklist, not derived from how the org is actually used.
The real cost of picking the wrong cadence shows up in two directions. Refresh too rarely and your sandbox drifts so far from production that bugs found in UAT never reproduce for the customer, or worse, bugs in production never showed up in testing at all. Refresh too often and you delete unmerged branches of configuration work, forcing developers to redo hours of setup they thought was safe.
Storage plays a role too. Full copy sandboxes inherit the storage allocation of production, and letting one sit unrefreshed for a year means test records, attachments, and audit trails balloon well past anything a QA cycle needs. None of that is dramatic on its own. It just quietly slows every report, every SOQL query, and every data load your team runs against that org.
Match Cadence to Sandbox Type, Not a Universal Rule
Different sandbox types serve different jobs, and each one earns a different refresh window. A developer sandbox used for isolated feature work doesn't need production data volume at all, so refreshing it on the same schedule as your full copy UAT environment wastes a refresh slot and resets work nobody asked to lose.
| Sandbox Type | Typical Refresh Window | Why |
|---|---|---|
| Developer | Only when metadata drifts far from prod | Small storage, single-user scope, refresh wipes everything the developer built |
| Developer Pro | Every 2-3 months | Shared by a small team, config drift accumulates faster than in solo dev sandboxes |
| Partial Copy | Every 4-6 weeks | Used for QA and regression against a sample data set that needs to stay current |
| Full Copy | Every 6-12 weeks, aligned to major releases | UAT and performance testing need production-scale volume and recent records |
None of these windows are laws. An org with heavy quarterly integration changes might need Partial Copy refreshed every three weeks. A slow-moving back office org running Service Cloud with minimal customization can stretch Full Copy to 12 weeks without anyone noticing the difference. The table is a starting point, not a policy.
Warning Signs You're Refreshing on the Wrong Schedule
Cadence problems rarely announce themselves directly. They show up as symptoms that look unrelated until you trace them back to stale or over-fresh data.
- QA reports bugs that never reproduce in production, because the sandbox data is months out of sync with real customer records.
- Storage usage in a full copy sandbox creeps toward its cap faster than production itself grows.
- Integration tests fail on external ID mismatches because connected systems moved on while the sandbox stayed frozen.
- Developers file ad hoc refresh requests outside the schedule, a clear sign the standing cadence is too long for how the org is actually used.
- A scheduled refresh wipes out config work that was mid-flight, a sign the cadence is too tight relative to how sprints are actually paced.
The first three point to a cadence that's too slow. The last two point to one that's too fast, or at least badly timed against the team's own rhythm. Watching for these signals beats sticking to a fixed calendar entry that someone set up two years ago and nobody has revisited.
Building a Refresh Calendar Around Your Release Cycle
The cleanest anchor for a refresh calendar is your own release cycle, not Salesforce's seasonal release schedule. Line up the full copy refresh with the start of your UAT window for each major release, giving testers a snapshot close enough to production that findings actually matter.
Timing matters more than most teams expect. Salesforce doesn't guarantee a fixed completion window for a refresh, but full copy sandboxes above roughly 20GB routinely take 24 hours or longer to complete. Kick one off the same week UAT is supposed to start and you've already lost a day of testing time before anyone logs in.
Build in a freeze window and tell the team about it before it happens, not after. A refresh that lands mid-sprint without warning is how a QA engineer loses a day of test case setup and a developer loses a custom setting nobody backed up. This is the same discipline that keeps a rollback plan from turning into a scramble: communicate the change before it lands, not while people are already dealing with the fallout.
Automating Refresh Without Breaking Test Data or Config
A raw refresh from production overwrites custom settings, wipes seeded test data, and can silently disable outbound integrations that point to sandbox endpoints. Teams that treat refresh as a one-click event usually spend the next two or three days re-doing setup work that a script could have handled in minutes.
Post-refresh automation should reactivate the metadata a sandbox needs to actually function: flow triggers, email deliverability settings, integration user credentials, and any custom settings that reset to production defaults. Skipping this step is why so many teams dread refresh day more than they should.
Data is the other half of the problem. A freshly refreshed full copy sandbox drags production-scale volume with it, PII included, which is exactly the moment sensitive fields need masking before any tester or offshore QA contractor opens a record. Pairing a refresh with an automated masking pass closes that exposure window instead of leaving real customer data sitting in a lower environment for however long it takes someone to remember the compliance checklist. Once masking runs, seeding tools can layer in the specific edge-case records a QA cycle needs, since a straight production copy rarely has the exact combination of statuses and record types a test plan calls for. Automating both steps into the refresh pipeline turns a two-day recovery task into something that finishes overnight, and it means the sandbox is usable the moment the copy completes instead of a day later.
What Slows Teams Down When They Try to Change Cadence
Most of the friction in changing a refresh cadence has nothing to do with Salesforce itself. It comes from habits built around the old schedule.
Refreshing every sandbox on the same day is a common one. It overloads the refresh queue, and if two full copy sandboxes queue at once, both take longer than either would alone. Staggering refreshes across sandbox types avoids the pileup and keeps at least one environment available while another is mid-refresh.
Skipping a pre-refresh audit is another. Nobody enjoys checking what's about to get wiped, but a five-minute review of pending metadata changes and unmerged branches saves a rebuild later. And treating a full copy sandbox as a training environment without warning the business users who rely on it for that purpose is a fast way to generate complaints that have nothing to do with engineering at all. A cadence change is a process change, and process changes need the same communication a deployment freeze gets, not less.
Frequently Asked Questions
How often should a full copy Salesforce sandbox be refreshed?
Most orgs land between 6 and 12 weeks, timed to the start of each UAT cycle rather than a fixed calendar date. Orgs with heavy integration or compliance requirements sometimes need it closer to 4 weeks, while slower-moving orgs can stretch past 12 without issues. The right interval depends on how fast production data and metadata actually change, not on a generic industry average.
Does refreshing a sandbox delete existing test data and configuration?
Yes. A refresh overwrites the sandbox with a new copy of production, which wipes custom settings, seeded test records, and any unmigrated configuration changes made since the last refresh. This is why a pre-refresh audit and post-refresh automation matter, since without them teams lose days rebuilding what the refresh erased.
How long does a full copy sandbox refresh take?
Salesforce doesn't publish a guaranteed completion time, but full copy sandboxes over roughly 20GB commonly take 24 hours or longer. Smaller partial copy and developer sandboxes usually finish in a few hours. Scheduling the refresh with that buffer in mind prevents it from eating into a UAT window that was supposed to start the same day.
Should every sandbox type follow the same refresh cadence?
No. Developer sandboxes rarely need scheduled refreshes since they hold minimal data and are used by a single developer. Partial copy and full copy sandboxes, which support QA and UAT against production-like data, need a more disciplined and shorter cadence than developer or developer pro environments.
What happens if a sandbox refresh cadence is too infrequent?
Stale sandboxes drift far enough from production that QA teams stop trusting their own test results, since bugs found in the sandbox may not reproduce in the live org and vice versa. Storage also creeps upward as old test records and attachments pile up without ever getting refreshed away. Integration tests tend to fail on outdated external IDs once connected systems move on while the sandbox stays frozen.