Estates carried 2 to 3 times the Full sandboxes their release cadence justified, because a 29 day refresh limit is cheaper to buy around than to wait out
Nobody buys a surplus sandbox on purpose. They buy a way around a 29 day wait, and the workaround renews every year afterward as if it were capacity.
Prepared by Redress Compliance · August 17, 2026 · Salesforce advisory. 30 to 40 Salesforce estates benchmarked, 2024 to 2025.
Executive summary
Estates carried 2 to 3 times the Full sandboxes their release cadence justified. The driver is the refresh interval rather than a capacity need, because a Full sandbox refreshes every 29 days and teams buy extra orgs to work around the wait.
Roughly one in three paid sandboxes showed no login activity in the prior 90 days. Dormant Partial Copy orgs sit inside the platform agreement where no one reviews them between renewals.
Faster refresh add ons sat idle on 20 to 30 percent of the orgs carrying them. Bought to solve the same wait, then left in place once the release that needed them shipped.
The sandbox line rarely appears as a single number. It hides inside the platform agreement and rises with the annual uplift, which is why it is the most overlooked line in the contract.
What are the four sandbox types actually for?
They differ on storage, refresh interval, and whether they copy production data. The type sets both the cost and how often the org can be reset.
| Type | Data copied | What it is for | Where the cost creeps in |
|---|---|---|---|
| Developer | Metadata only | Individual development work | Rarely, it is the cheap tier |
| Developer Pro | Metadata, larger storage | Development needing more room | Provisioned then forgotten |
| Partial Copy | A sample of production data | Testing against representative data | Dormant orgs nobody logs into |
| Full | A complete production copy | Full regression and staging | Surplus orgs bought to beat the refresh wait |
Allocation runs by edition. Enterprise, Unlimited, and Performance bundle different counts, and everything beyond the bundled allocation is a paid add on.
A Full sandbox refreshes every 29 days, so a team that needs two clean environments in a month buys a second Full org rather than waiting. That is a rational decision at the time and an invisible one afterward. The workaround then renews annually as though it were capacity.
Which is how estates end up carrying two to three times what their release cadence justifies.
Why does the sandbox line grow without anyone deciding to grow it?
Because it is never presented as a decision. Salesforce sells sandboxes as included allocations plus paid add ons tied to your edition, so the cost rarely appears as a single line.
It sits inside the platform agreement and rises with the annual uplift. Most buyers never reconcile the sandboxes they pay for against the sandboxes they actually use.
- Pull login activity per sandbox for the last 90 days, since roughly one in three paid orgs showed none at all.
- Map Full orgs to the actual release cadence, because the justified number is usually a fraction of the provisioned one.
- List every faster refresh add on and check it is still used, as 20 to 30 percent sat idle on the orgs carrying them.
- Co terminate the sandbox spend with the master agreement, so the whole line comes up for review at a moment when you hold leverage.
The Salesforce licence optimisation guide
Editions and allocations, the four sandbox types with their refresh limits, and the moves that cut surplus orgs before the renewal locks them in.
Get the brief →What 30 to 40 Salesforce estates showed
Across roughly 30 to 40 Salesforce estates benchmarked between 2024 and 2025, sandbox spend was the single most overlooked line in the platform agreement.
Surplus Full sandboxes led. Most estates carried 2 to 3 times the Full orgs their release cadence justified, and the reason was consistent enough to be structural rather than accidental.
A Full sandbox refreshes every 29 days. A team that needs a clean environment twice in a month cannot wait, so it buys a second org. The purchase solves a scheduling constraint, and then it renews every year as though it were capacity.
Dormant Partial Copy orgs came second, with roughly one in three paid sandboxes showing no login activity in the prior 90 days. Faster refresh add ons were the third pattern, idle on 20 to 30 percent of the orgs that carried them, bought for a release that has since shipped.
All three share a cause. The count and the type are the levers, and neither is visible as a line anyone reviews between renewals. Rightsizing before the quote is worth more than the headline discount, and the wider estate position sits at the Salesforce hub.
- Your quote benchmarked against 500,000+ real closed deals, adjusted for size, region, and industry
- Sandbox count and type modeled against release cadence rather than provisioned allocation
- Uplift and co termination language flagged with the exact quote, the page, and the replacement text
What does a rightsizing pass actually change?
Three things, in order, and the order matters because each one shrinks the base the next applies to.
The count
Retire dormant orgs first. An org with no logins in 90 days is not a capacity decision waiting to be defended, it is a line waiting to be cut.
The type
Downgrade where the workload allows. A Partial Copy used for a test that never touches production data belongs on Developer Pro, and the storage difference is the whole price difference.
The timing
Co terminate the sandbox spend with the master agreement. Aligning the renewal dates compounds leverage, because a line reviewed in isolation mid term has nothing behind the ask.
What the pass produces
- A retire list, every paid org with no logins in 90 days, which is roughly a third of them.
- A downgrade list, Partial Copy orgs whose testing never touches production data.
- An add on list, the faster refresh options idle on 20 to 30 percent of the orgs carrying them.
- A cadence map, Full orgs set against the releases that actually justify them.
What the estates measured, 2024 to 2025
Across roughly 30 to 40 Salesforce estates benchmarked:
Carried against what the release cadence justified, driven by the 29 day refresh interval rather than by capacity.
Paid sandboxes showing no login activity at all in the prior 90 days.
Faster refresh add ons sat idle on 20 to 30 percent of the orgs that carried them, bought to solve the same wait and left in place after the release shipped.
A typical rightsizing pass took 15 to 30 percent off the sandbox line, using count and type rather than any change to the headline rate.
Watch the briefing · 5:50Every Salesforce Product Is a Different NegotiationWhy the platform line and the add on lines need separate arguments at the same renewal.
Your first five moves
- List every sandbox with its type, its edition allocation, and whether it is paid or included in the bundle.
- Pull 90 day login activity per org and mark every one showing none, since roughly a third will.
- Map Full orgs against the real release cadence, which is where the 2 to 3 times surplus becomes visible.
- Check every faster refresh add on is still needed, as 20 to 30 percent were idle once the release that justified them shipped.
- Co terminate sandbox spend with the master agreement. The negotiation practice runs the reconciliation before the quote.
Frequently asked questions
How many surplus sandboxes does a typical estate carry?
Most estates carried 2 to 3 times the Full sandboxes their release cadence justified, across the 30 to 40 estates benchmarked in 2024 and 2025.
Why do teams buy extra Full sandboxes?
Because a Full sandbox refreshes only every 29 days. A team needing two clean environments inside a month buys a second org rather than waiting, and the workaround then renews as though it were capacity.
What are the four sandbox types?
Developer and Developer Pro are metadata orgs, Partial Copy carries a sample of production data, and Full is a complete production copy. The type sets both the cost and the refresh limit.
How are sandboxes allocated?
By edition. Enterprise, Unlimited, and Performance bundle different counts, and everything beyond the bundled allocation is a paid add on that sits inside the platform agreement.
How many paid sandboxes are dormant?
Roughly one in three showed no login activity in the prior 90 days. They are Partial Copy orgs in most cases, provisioned for a project and never retired afterward.
Are refresh add ons worth keeping?
Often not. Faster refresh add ons sat idle on 20 to 30 percent of the orgs carrying them, bought to solve a specific release constraint and left in place long after that release shipped.
Why is the sandbox line so easy to miss?
Because it rarely appears as a single number. It hides inside the platform agreement and rises with the annual uplift, so nothing prompts a reconciliation between renewals.
What saving is available?
Typically 15 to 30 percent of the sandbox line, achieved through count and type rather than through any change to the headline rate.
Should sandbox spend be co terminated?
Yes. Aligning sandbox renewal with the master agreement compounds leverage, because a line reviewed alone mid term has nothing behind the ask.
What should be done before the renewal quote?
A full reconciliation of paid sandboxes against 90 day login activity and the real release cadence. The count and the type are the levers, and both have to be settled before a rate is discussed.
