Every cloud-modernization conversation eventually arrives at this fork: do we lift-and-shift the legacy app, or refactor it? Both options are valid; both are wrong as defaults. The right answer depends on what you’re actually trying to optimize — cost, velocity, or risk — and an honest read on how much capacity your team has for either path.
Lift-and-shift: speed at the cost of native benefits
Lift-and-shift means moving the application to cloud infrastructure with minimal code changes — usually containerizing and deploying to a managed service. Behavior stays identical; the deployment target changes.
- Pros: fast (weeks), low risk (behavior unchanged), predictable cost.
- Cons: cloud bill rarely improves much, old pain travels with you, you don’t get cloud-native benefits (autoscaling, managed services, serverless).
Refactor: capacity-intensive, but the upside is real
Refactor means rebuilding key parts of the application to be cloud-native — decomposing into smaller services, moving state to managed databases, using platform primitives (queues, secrets, identity).
- Pros: meaningful cost savings, tech debt paid down along the way, stack modernized.
- Cons: months of work, behavior risk (you need strong tests), team capacity required throughout.
The honest decision matrix
- Lift-and-shift if: the app is on its way to retirement in 12-24 months; you have a hard deadline to leave the data center; your team has no capacity for a major rebuild; the legacy code is still serving the business well.
- Refactor if: the app is core and will be around for 5+ years; you have a team that can dedicate 30-50% capacity to the rebuild; cloud costs (with lift-and-shift) will be unsustainable at expected scale; modernizing is part of a larger product strategy.
- Hybrid (most common): lift-and-shift everything to buy time, then refactor the 1-2 components that are pain points within the next 12 months. This is what most teams actually do.
The trap of partial refactor
The classic failure mode: a team starts a refactor with great intentions, runs out of budget at 60% complete, and ends up running BOTH the legacy app and the half-refactored version in parallel. Worse than either pure path.
If you can’t commit to finishing a refactor, lift-and-shift cleanly. Half-done refactors are a worse state than the starting point.
The 6R framework, simplified
AWS’s “6 Rs of migration” framework has more nuance, but in practice most decisions land in one of four buckets:
- Retire— the app isn’t worth migrating. Sunset it.
- Retain— keep it where it is. Some workloads belong on-prem or in a colo for compliance, latency, or hardware reasons.
- Lift-and-shift (Rehost)— fast move, no improvements.
- Refactor (Replatform / Rearchitect)— the real modernization path.
How we approach this
Our typical Cloud & DevOps engagement starts with an audit that bucket-sorts every application into one of these four categories. Most enterprises find 60-80% of their apps are lift-and-shift candidates, 10-20% are retire candidates, and 10-20% deserve real refactor effort. Getting the bucketing right is most of the value.
Takeaways
- Lift-and-shift = fast, cheap to do, expensive to keep.
- Refactor = months of work, but the upside is structural.
- Hybrid (lift everything, refactor the 1-2 pain points) is what most teams pick.
- Half-finished refactor is worse than either path. Commit or don’t start.
