Stop 13 · Cloud Migration & Multi-CloudTopics · 3/8

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.

The blob character pushes a chai cart past a half-built wooden cafe frame.

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. 1

    Rehost

    Copy the VM to the cloud. Same OS, same app, new data centre.

  2. 2

    Right-size

    Watch real CPU and memory for a few weeks, then pick smaller instances.

  3. 3

    Replatform

    Swap the self-run database for a managed one. Backups and patches become the provider's job.

  4. 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

~25 min

Quick check

A team rehosted a server that was sized for festival-season peaks. What usually happens to the cloud bill?

Go deeper

  1. 1List a scenario where lift-and-shift is clearly the right first step, and one where it isn't.
  2. 2Learn why many organizations lift-and-shift first, then re-architect incrementally afterward.
  3. 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.

Download
InsideEdge