Case Study: 95% Saving Through Azure Backup Retention Redesign

Problem

A large council organisation had a valid requirement to retain some data for up to seven years.

The issue was not the retention requirement itself. The issue was that decommissioned virtual machines were still being retained in Azure Backup and Recovery Services vaults, even when they no longer needed fast operational restore.

That made the environment look safe on paper, but it was costing more than it needed to.

Context

Azure Backup is the right tool for active workloads that need managed backup, policy control, and reliable restore options.

It is not always the right place to keep historical data from retired workloads for years.

• Production and non-production workloads were not always clearly separated.
• Active and decommissioned workloads were often treated the same way.
• Historical VM data stayed in expensive backup storage.
• Some retained data had not been reassessed for archive suitability.
• Some production backup coverage gaps also needed attention.

The practical goal was simple: keep the data that had to be retained, but move it to the right storage tier with the right recovery expectation.

What was accomplished

Our team reviewed the Azure Backup estate to find where the storage growth and cost were coming from.

The work covered VMs still connected to Recovery Services vaults, decommissioned VMs with retained recovery points, backup policies, retention settings, and historical VM backup data suitable for archive storage.

From there, we redesigned the retention approach and created a controlled process to move eligible historical VM data into secure Azure archive storage.

The work also tightened governance. Backup coverage gaps were identified, production protection was brought back into focus, and operations teams were given a clearer process for handling decommissioned workloads in future.

Key decisions and trade-offs

The main trade-off was recovery speed versus storage cost.

Some workloads still needed normal backup protection and faster restore options. Those stayed aligned to backup policy.

Other data only needed to be retained for compliance or historical reasons. For that data, archive storage was a better fit, provided the slower restore timing was understood and accepted.

Archive rehydration was tested, and up to 24-hour restore timing was accepted for the long-term retention use case.

Result

The remediation delivered a six-figure annual saving while preserving required retention.

Conclusion

The better model is to keep active recovery data in backup storage, move retained historical data into the right archive tier, and make decommissioning part of the normal workload lifecycle.

For organisations with growing Azure Backup spend, an Azure cost optimisation audit can quickly show where retention design, archive storage, and backup governance need attention.