Lift-and-Shift vs Re-Architecting
Part of the Cloud Computing Roadmap
In short
Your boss wants out of the data centre in six months. Your architect wants to rebuild everything as microservices. Both are right about something, and this choice decides your next two years.
Lift-and-shift moves an application to the cloud with minimal changes for speed; re-architecting redesigns it to be cloud-native for better long-term efficiency — a real trade-off between migration speed and eventual cloud ROI.

Think of it like this
Move the cart or build the cafe
A chai wala's lane is being dug up. He can wheel his cart to the next street by evening and keep selling. Or he can spend months building a proper cafe with seating and a fridge. The cart move is fast. The cafe earns more later.
Watch it happen
Same app, two ways to move it
Lift-and-shift
- Copy VMs as they are
- Weeks, not months
- Old design and its costs come along
Re-architect
- Redesign with managed cloud services
- Months of work and testing
- Autoscaling, lower running costs later
Lift-and-shift to meet a deadline, then re-architect the few apps where the gains justify the work.
The big ideas
What you need to know
Lift-and-shift is fast
Tools copy whole servers into cloud VMs. Code barely changes, so testing is lighter and risk is lower.
But the bill can grow
Servers sized for peak on-premises run 24x7 in the cloud too. Rehosted apps often cost more until right-sized.
Re-architecting pays later
Breaking an app into managed services lets parts scale on their own and drops patching work.
Move first, improve next
Many teams rehost, stabilise, then modernise one piece at a time. It's not a one-time choice.
How it works
A common two-step path
- 1
Rehost
Copy the VM to the cloud. Same OS, same app, new data centre.
- 2
Right-size
Watch real CPU and memory for a few weeks, then pick smaller instances.
- 3
Replatform
Swap the self-run database for a managed one. Backups and patches become the provider's job.
- 4
Refactor a hot spot
Pull the busiest feature, like image uploads, into its own service or function.
Save yourself the pain
Common mistakes
Oops
Expecting a lift-and-shift to cut costs on day one.
Do this instead
Rehosting mainly buys speed. Savings come after right-sizing, scheduling and managed services.
Oops
Re-architecting an app that's being replaced next year anyway.
Do this instead
Match the effort to the app's future. Short-lived apps deserve the cheapest move.
Your mission
Plan both routes for one app
Quick check
A team rehosted a server that was sized for festival-season peaks. What usually happens to the cloud bill?
Go deeper
- 1List a scenario where lift-and-shift is clearly the right first step, and one where it isn't.
- 2Learn why many organizations lift-and-shift first, then re-architect incrementally afterward.
- 3Understand lift-and-shift often doesn't capture the cost savings cloud can offer, at least initially.
More topics at this stop
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.