Built in is not the same as cheapest
Microsoft 365 Backup protects platform data on a pay as you go per gigabyte meter charged to Azure rather than to the suite, which means the bill is a function of data volume and retention rather than of how many people you employ. Both of those grow quietly, and the meter grows with them, which is why the service is usually bought on convenience and rarely modelled against the tool it is meant to replace.
Prepared by Redress Compliance · August 10, 2026 · Microsoft advisory. Based on 20 to 30 Microsoft 365 data protection reviews, 2024 to 2025.
Executive summary
The per gigabyte meter scaled faster than buyers expected in 40 to 60 percent of the estates we modelled.
Native backup is billed pay as you go per gigabyte of protected data per month and charged to an Azure subscription rather than to the suite, so it sits outside the seat line entirely and needs its own budget owner and its own alert.
There is no seat licence involved, which also means none of the usual seat governance applies to it.
Retention is the lever, because it multiplies stored volume and the meter charges for all of it.
A long default retention applied to every workload stores far more than the recovery requirement needs, and since the bill is a function of volume and retention rather than user count, the policy decision is the pricing decision.
Data volume, retention period, workload scope, and growth rate are the four drivers, and three of the four are governance choices rather than technical constraints.
Native backup overlapped an existing third party contract at 10 to 20 percent of the data protection budget.
Buyers ran both for months without cancelling either, which is the specific failure mode: the native service is easy to enable and the incumbent contract has a term, so the overlap is created by a decision that felt free at the time.
Model the volume and retention against the incumbent before switching anything on, not after.
Native wins on restore speed and simplicity; third party often wins on retention economics. Native integration speeds recovery inside the platform and removes separate infrastructure, which makes it economical where retention is genuinely short.
Third party tools tend to win on long retention through flat or tiered storage, on coverage beyond the platform, and on portability, because the data is held independently of the vendor. Modelling both first avoided 8 to 15 percent of avoidable spend.
What actually moves the bill
| Driver | Effect on cost | Often overlooked | Buyer side move |
|---|---|---|---|
| Data volume | Directly scales the meter | Old collaboration sites | Archive before backup |
| Retention period | Longer means more stored | Default long retention | Match policy to requirement |
| Workload scope | More workloads, more data | Backing up everything | Scope to critical data |
| Growth rate | Compounds month on month | Unmanaged sprawl | Govern data growth |
Because the charge lands on Azure consumption rather than on the suite, it escapes the governance that covers every other line in the estate. Seat based services get reviewed at renewal, reconciled against headcount, and owned by whoever runs the suite.
A per gigabyte meter charged to a cloud subscription has none of that: no seat count to reconcile, no renewal date to force a review, and frequently no named owner at all, which is exactly why it scaled faster than buyers expected in 40 to 60 percent of the estates we modelled.
Give it a budget owner and an alert on day one, because nothing else in the operating model will surface it. The wider suite mechanics sit in the Microsoft 365 licensing pillar.
Where each option genuinely wins
- Native wins on restore speed, because integration inside the platform shortens recovery in a way an external tool structurally cannot.
- Native wins on simplicity, with no separate infrastructure to run, which is a real operating saving rather than only a licensing one.
- Native wins on short retention, where the per gigabyte meter is economical precisely because there is little stored volume to charge against.
- Third party often wins on long retention, where flat or tiered storage pricing beats a per gigabyte meter that charges for every month of every copy.
- Third party wins on coverage and portability, protecting platforms beyond the suite and holding the data independently of the vendor whose platform it came from.
The Microsoft EA renewal playbook
The buyer side framework for the current EA cycle, including where consumption metered services sit against the seat based estate.
Get the white paper →The overlap that creates itself
The standard line is that native backup is obviously right because it is built in, so you should switch off the third party tool and move everything across. We disagree, and the failure mode we saw is more specific than a pricing disagreement.
In the estates we modelled, the per gigabyte meter on long retention scaled past the flat cost of the incumbent tool, and buyers ran both services for months without cancelling either, which produced an overlap worth 10 to 20 percent of the data protection budget for exactly nothing.
That overlap is not a decision anybody made. It is what happens when one service is trivially easy to enable and the other has a contract term: the native service starts billing immediately while the incumbent runs to its renewal, and in between nobody owns the question of which one is the plan.
The correction is sequencing rather than analysis. Model data volume and retention against the third party contract before enabling anything, because after enablement you are comparing a live meter against a live contract and the comparison has already cost you a quarter.
Then scope native to the workloads where its restore speed and short retention genuinely win, rather than treating it as an all or nothing replacement.
And set the retention policy per workload rather than accepting a long default, since retention multiplies stored volume and the meter charges for every gigabyte of it.
Archive before backup where old collaboration sites are carrying data nobody has opened in years, because backing up an archive candidate is paying twice for a decision nobody took. The optimizer sits at M365 license optimizer.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across data protection reviews, 2024 to 2025
Across roughly 20 to 30 Microsoft 365 data protection reviews we ran between 2024 and 2025, the native service was bought on convenience and rarely modelled against the third party incumbent:
Estates where the per gigabyte charge scaled faster than the buyer had expected, driven by retention defaults rather than by user growth.
Share of the data protection budget spent running native and third party protection in parallel over the same data.
Three patterns recurred: the pay as you go per gigabyte meter scaling faster than buyers expected in 40 to 60 percent of estates, native backup overlapping an existing third party contract at 10 to 20 percent of the data protection budget.
And modelling retention and data volume before committing avoiding 8 to 15 percent of avoidable spend.
The buyer side move is to model volume and retention against the incumbent first, scope native to the workloads where restore speed and short retention win, set retention per workload rather than accepting a long default, and give the Azure charged meter a named budget owner and an alert.
Built in is not the same as cheapest.
Your first five moves
- Model data volume and retention against the incumbent contract before enabling anything, because after enablement you are comparing a live meter against a live contract and the overlap has already started.
- Set retention per workload rather than accepting a long default, since retention multiplies stored volume and the meter charges for every gigabyte of every month.
- Scope native backup to the workloads where restore speed and short retention win, rather than treating it as an all or nothing replacement for the existing tool.
- Archive before backup where old collaboration sites carry data nobody has opened in years, because protecting an archive candidate pays twice for a decision nobody took.
- Give the Azure charged meter a named budget owner and an alert, because it sits outside the seat line and no renewal date will force a review of it. The Microsoft practice runs the model with you.
Frequently asked questions
How is Microsoft 365 Backup priced?
On a pay as you go meter per gigabyte of protected data per month, charged to an Azure subscription rather than to the suite.
There is no seat licence involved, which means the bill is a function of data volume and retention rather than of user count, and it sits outside the seat line in both budgeting and governance terms.
What drives the cost?
Four things: data volume, which scales the meter directly; retention period, since longer retention means more stored data; workload scope, because protecting everything protects a lot of data nobody needs recovered; and growth rate, which compounds month on month.
Three of the four are governance choices rather than technical constraints.
Why is retention the main lever?
Because it multiplies stored volume and the meter charges for all of it.
A long default retention applied uniformly across every workload stores far more than the actual recovery requirement, and since the bill tracks volume rather than headcount, the retention policy is effectively the pricing decision. Match the policy to the requirement per workload.
Does native backup replace a third party tool?
Sometimes, and the overlap is the risk. In our reviews native protection overlapped an existing third party contract at 10 to 20 percent of the data protection budget, because the native service is trivially easy to enable while the incumbent runs to its contract term.
Model both before enabling anything rather than after.
When does native win?
On restore speed, because platform integration shortens recovery in a way an external tool structurally cannot; on simplicity, since there is no separate infrastructure to run.
And on short retention, where the per gigabyte meter is economical precisely because there is little stored volume to charge for.
When does a third party tool win?
On long retention, where flat or tiered storage pricing beats a meter charging for every gigabyte of every month. On coverage, where protection extends beyond the platform to systems the native service does not touch.
And on portability, since the data is held independently of the vendor whose platform produced it.
Why does the Azure billing matter?
Because it escapes the governance that covers seat based services. There is no seat count to reconcile, no renewal date to force a review, and frequently no named owner, which is why the meter scaled faster than buyers expected in 40 to 60 percent of the estates we modelled.
Assign a budget owner and an alert on day one.
Negotiating Microsoft E5, E7, and Copilot Cowork: The Two-Layer Bill
E7 at $99 vs $117 in components, and the truth proposals omit: $99 is the governance floor. Agent execution bills separately through Copilot Credits with no rollover, Security Copilot overages at $6 per unit, and Cowork priced as license plus meter.
