When organisations start planning a cloud migration, "lift and shift" often comes up early. The appeal is obvious: take what you have, move it to AWS without changing it, and declare the migration complete. It's the path of least resistance and, on the surface, it looks like the safest option.
It's also one of the most common reasons cloud migrations fail to deliver value.
This post is about why lift and shift as an end state, rather than an interim tactic, creates problems, and what a more considered approach looks like.
What Lift and Shift Actually Means
Lift and shift (also called rehosting) means taking your existing on-premises servers, applications, or virtual machines and moving them to AWS with minimal or no change. You're not refactoring code, redesigning databases, or rethinking how the application works. You're just changing where it runs.
As a temporary measure during a migration programme, this is sometimes sensible. Getting critical systems off ageing hardware quickly, for instance, can be a legitimate reason to rehost first and optimise later.
The problem is when "later" never comes. The application lands in AWS, it works, and the migration is declared done. What you have at that point is not a cloud environment. You have a virtual data centre that happens to be hosted by Amazon.
Why It Doesn't Deliver Cloud Value
The commercial case for cloud migration is usually built on a combination of cost reduction, scalability, and operational efficiency. Lift and shift, on its own, typically delivers none of these reliably.
Cost. On-premises infrastructure is purchased in chunks: you buy a server, it runs for five years, you buy another one. The cost model is relatively predictable. AWS bills by the hour. If you take a server that was running at 15% utilisation on-premises and move it to an equivalently sized EC2 instance, you're now paying for that overcapacity by the hour, indefinitely. Without rightsizing or architectural adjustment, AWS can be more expensive than what you had before.
Scalability. Cloud scalability, the ability to scale up during peak demand and scale down when load drops, requires your application to be designed or adapted for it. Applications that weren't built with horizontal scaling in mind don't automatically become scalable because they're now running in AWS. You get the infrastructure capability without the ability to use it.
Operational efficiency. Managed services are one of the primary ways organisations reduce operational overhead on AWS. But managed services typically require architectural change. A self-managed database on an EC2 instance doesn't become a managed RDS instance by virtue of being moved. You still own the patching, the backups, the failover, and the operational overhead; you've just moved where that work happens.
The Migration Strategies Worth Considering
AWS typically describes six migration strategies (the "6 Rs"): Rehost, Replatform, Repurchase, Refactor, Retire, and Retain. Lift and shift is Rehosting, the most conservative option.
For most applications, Replatforming is the appropriate starting point. This means making targeted changes to take advantage of cloud capabilities without a full rewrite. Moving from a self-managed database on EC2 to RDS is a common example. You're not redesigning the application; you're swapping out a component for a managed equivalent. The lift is moderate; the operational benefit is significant.
For applications with genuine business importance and a long expected lifespan, Refactoring, which means redesigning parts of the application to be cloud-native, is often the right long-term answer. This is the highest-effort migration strategy, but it's also the one that delivers the scalability, resilience, and cost efficiency that the original business case was built on.
And sometimes the right answer is to Retire or Replace entirely. A significant portion of most application portfolios consists of tools that have been superseded, underused, or that have commercially available cloud-native alternatives. These don't need to be migrated. They need to be cut.
The Discovery Phase Nobody Wants to Skip
The decision about which strategy applies to which application cannot be made without understanding what you actually have. This is where migration programmes most commonly go wrong.
Application discovery, inventorying what exists, what it does, what it depends on, and who relies on it, is unglamorous work. It requires time and organisational involvement. People are often reluctant to assign resource to it. And there's always pressure to start migrating things because migrating things looks like progress.
But the cost of skipping it is a migration built on wrong assumptions: applications moved with the wrong strategy, dependencies that break in the new environment, and surprises that surface in production.
A thorough discovery phase doesn't slow a migration down. It stops you having to redo work.
What We Actually Recommend
The right migration approach is application-specific. Some things genuinely should be lifted and shifted first, particularly if there's a hard deadline like hardware end-of-life. Others should go straight to replatforming. Some should be retired without migrating at all.
What matters is making those decisions deliberately, based on analysis, not defaulting to the easiest option for everything and assuming the rest will sort itself out.
Cloud migration, done properly, is a programme of work with a clear business outcome at the end. That requires planning, prioritisation, and honest assessment of what you have. It's more involved than lift and shift. But it's also the version that delivers what the business was expecting when it decided to move to the cloud.