Why your cloud migration savings haven't appeared

The workloads moved. The applications run. Eighteen months in, the cloud bill is well above the business case, the data center cost has barely fallen, and nobody can explain either number.

Cloud migration failures are almost never technical. Migration tooling is mature and the engineering is largely solved. The failures are financial, and they trace back to decisions made in the first eight weeks.

1. Nobody ranked the drivers

Cost, agility, and resilience produce different migrations, and they conflict.

A cost-driven migration requires optimization work — right-sizing, replatforming to managed services, commitment purchasing — and that work takes time. A deadline-driven migration is a rehost. Both are legitimate; they are not the same program.

The fix: force a ranked driver hierarchy at the outset, and where a deadline makes the cost case unachievable, rephase the business case honestly and fund optimization as a distinct subsequent phase.

2. The source estate was never decommissioned

Migration completes, the team moves on, and the data center contract, the licences, and the support agreements all run to their own term. The organization is now paying for the workload twice.

The fix: make source decommissioning an exit criterion for each migration wave — not a follow-on project. Terminate the licences, terminate the support contracts, release the hosting, and confirm with finance that the cost has left.

3. Resources were never tagged at provisioning

Cost allocation depends on tags. Tags applied by guidance decay within weeks. Tags enforced by policy at provisioning — where a resource cannot be created without them — hold indefinitely.

Without enforced tagging nobody can attribute spend, nobody owns a budget, and the aggregate number grows without any individual being accountable for it. The savings case becomes unevidenced.

The fix: a five-day decision in month one. Enforce tagging through policy, in the landing zone, before the first wave.

4. Migration started before the landing zone was finished

Account structure, network topology, identity integration, security guardrails, logging, and tagging standards are all far cheaper to build before workloads arrive. Retrofitting them around live production costs several times as much and sometimes requires a second migration.

The fix: make landing zone completion a gate on wave one, not a milestone alongside it.

5. Nothing was retired at assessment

Estates routinely contain ten to twenty percent of workloads with no identifiable business owner and no authentication activity. Every one of those retired during assessment is a workload never migrated, never tested, never validated, and never run.

The fix: run a genuine retirement pass during discovery, using authentication logs and spend data rather than the configuration database alone. It is the cheapest saving available in the entire program.

6. Only one cost line was reported

A cloud program looks like a cost increase for its first twelve to eighteen months. That is not a symptom of failure — it is dual-running, and it is expected. But a report showing only cloud spend, rising month over month against a business case that promised savings, invites exactly the wrong conversation.

The fix: report both lines together from wave one — cloud spend and source estate cost — against a modeled trajectory that shows the increase before the decrease. A sponsor who was shown the shape in advance asks a ten-minute question. One who was not commissions a program review.

The pattern

Every one of these is a decision, not an accident, and every one is made early. By the time the savings shortfall appears in a finance reconciliation, the trajectory has been set for a year.

The programs that deliver their case set a spend guardrail in month one, enforce tagging at provisioning, gate wave one on the landing zone, and treat decommissioning as part of the migration rather than as cleanup afterward.