Lift-and-shift: when moving to the cloud does not deliver what you expected
Why mechanically moving infrastructure to the cloud without changing architecture preserves old problems and adds new costs.
Moving infrastructure to the cloud has become a standard agenda item in many companies' strategies. The arguments are clear: lower capital spending on hardware, flexible scaling, offloading some operational work.
But I keep seeing a consistent pattern in projects that started with those expectations. The company moves servers to the cloud - virtual machine by virtual machine, with almost no changes to the architecture. A few months later the cloud bill is significantly higher than expected, and there is no more flexibility than before. Analysts call this scenario "lift-and-shift" and are sceptical about it. I share that scepticism.
What lift-and-shift is and why it appeals
The idea is simple: take what is running on your own servers and move it to the cloud with minimal changes. As little code and architecture modification as possible, maximum migration speed.
This is attractive because it reduces risk. If you change nothing, nothing breaks. The team knows the system, no retraining required.
The problem is that this approach moves not just the applications but their inefficiencies. A system designed for permanently-running physical servers often runs in the cloud as permanently-running virtual machines - with the same overhead, but at cloud prices.
Where the disappointment comes from
A few typical situations:
Idle resources. A virtual machine rented in the cloud around the clock costs differently from an owned server amortised over several years. If the load is uneven - at night and on weekends the system is nearly idle - paying for constant availability means paying for emptiness.
Storage and traffic. In your own infrastructure, moving data between servers is free. In the cloud, outbound traffic costs money. An architecture that assumes active data exchange between components can generate a surprisingly large bill.
Licensing. Some enterprise software has licence terms that do not cover cloud use or require a different licence type. This is not always discovered in advance.
Where the real argument for cloud lies
Cloud services create value not when they replace a physical server with a virtual one. They create value when the architecture uses what you are paying for: elastic scaling, managed services you do not need to maintain yourself, global reach.
This requires rethinking how applications are structured. Not necessarily a full rewrite - but at least an analysis of where the current architecture conflicts with cloud principles.
Questions to assess before migration
Before starting a migration, it is worth asking a few questions:
- For which systems are we expecting savings, and what are those calculations based on?
- How does load on the systems vary across the day and week - does elasticity make sense?
- Which components can be replaced with managed services, so we stop maintaining them ourselves?
- Are there any licensing restrictions on the software we use?
- Who made the cloud cost estimate - and how does it compare to current spending?
Cloud is a good tool when used correctly. A mechanical migration without answers to these questions often leads to disappointment and unnecessary expense.