Lift-and-shift produces a datacentre on rented hardware at higher cost. The overrun is predictable from the migration strategy chosen at the start.
A cloud migration business case usually promises three things: lower infrastructure cost, greater elasticity and faster delivery. A meaningful proportion of migrations deliver none of them, and finish with a monthly bill exceeding what the datacentre cost.
This outcome is not random. It follows predictably from decisions made at the start of the programme.
Lift-and-shift preserves every inefficiency
The fastest migration path is to replicate existing servers as cloud instances. It is low-risk, requires little application change, and it is why so many organisations choose it.
It also guarantees the business case fails. An application architected for fixed on-premise hardware does not scale elastically simply because it is now running on someone else's hardware. It runs at its provisioned size continuously, which is precisely the cost model cloud is supposed to improve on — except now you are paying a margin on it.
Worse, on-premise capacity was sized for peak and treated as sunk. In cloud, that same over-provisioning bills monthly, forever. The waste that was invisible in a depreciated asset becomes a line item.
Nobody owns the bill
In a datacentre, capacity is constrained by procurement. Adding servers requires a purchase order, which requires justification. That friction is an accidental cost control.
Cloud removes the friction entirely, which is the point — and also the problem. Any engineer can provision anything instantly. Without tagging discipline and cost attribution, spend is a single aggregate number that no individual team feels responsible for, and it grows.
The fix is unglamorous: mandatory tagging enforced by policy, cost attributed to the teams that generate it, and visibility in the tools engineers already use. Cost becomes an engineering concern when engineers can see the cost of their own decisions.
Managed services were avoided
Much of cloud's economic advantage comes from managed services — databases, queues, storage tiers that eliminate operational overhead. Teams frequently avoid them, citing lock-in, and run self-managed equivalents on raw compute.
Lock-in is a genuine consideration, but it is often invoked reflexively. The relevant question is what portability is actually worth against the operational cost of maintaining the alternative — patching, backups, failover, scaling — all of which consumes engineering time that would otherwise go to product work.
What a migration that holds its case looks like
Assessment first, application by application. Some workloads should be rehosted, some replatformed onto managed services, some genuinely refactored, and some retired entirely — the last category is usually larger than expected and is the cheapest win available.
Governance before workloads. Account structure, tagging standards and cost policy established before anything migrates, because retrofitting governance across a populated estate costs multiples of doing it first.
Right-sizing as a continuous practice rather than a one-off exercise, with commitment purchasing planned against actual observed usage.
And a business case stated in terms the organisation can actually verify after the fact — not just cost, but provisioning lead time, deployment frequency and incident recovery time. If the only promised benefit is cost reduction, the programme will be judged solely on a bill that takes eighteen months to optimise.
