Cloud Migration Strategies: Lift-and-Shift vs Replatform vs Rebuild

Most cloud migrations are sold on a promise that quietly does not hold: move to the cloud and your costs go down.

They usually go up. Sometimes a lot.

That is not an argument against migrating. It is an argument against migrating for the wrong reason, which is how a surprising number of these projects get approved. The cloud buys you elasticity, speed, and managed services. It does not buy you cheapness, and the teams that expected cheapness are the ones who end up defending a bill nobody predicted.

So: the three real strategies, what each actually costs, how to choose, and the mistakes that recur.

Fair warning on one point up front. Almost everything below is less about technology than it looks. The migrations that go badly rarely fail on the infrastructure. They fail on scope, on undiscovered dependencies, and on people being handed a system they have never run.

The three strategies

Everything gets marketed as a distinct methodology. There are really three, and they differ in one dimension: how much you change on the way.

The instinct is to treat the third as the "real" one and the first as cheating. That instinct is wrong, and it is expensive.

Lift-and-shift (rehost)

You take what runs in your data center and run the same thing on cloud servers. Same application, same architecture, different address.

It is fast, it is low risk, and the criticism is accurate: you get almost none of the cloud's actual advantages. You have moved your servers, not modernized anything. Your costs often rise, because a cloud VM running 24/7 is more expensive than the hardware you already owned.

And yet it is frequently the right first move.

If your data center lease expires in four months, this is your only option, and that is fine. If you need to get out of a facility before you can think properly about architecture, lift-and-shift buys you the time to think. Getting there badly and improving afterward beats missing the deadline.

The failure is not doing it. The failure is doing it and then stopping, which is how you end up paying cloud prices for data-center architecture, forever.

Replatform

You keep the application mostly intact but swap infrastructure components for managed equivalents. Your self-managed database becomes a managed one. Your load balancer becomes the cloud's. Your servers become containers.

The application code barely changes. What changes is how much you have to operate.

This is the sweet spot for most companies, and it is under-chosen because it lacks a good story. Nobody presents "we replaced our database with a managed database" at a conference.

But the return is real: you stop doing backups, patching, and failover yourself, which is work that produced no customer value and consumed your best engineers. You get genuine cloud benefits for a fraction of the re-architecture cost.

If you are unsure which strategy to pick, this is usually the answer.

Re-architect

You rebuild the application to be cloud-native: managed services, auto-scaling, event-driven where it helps, decomposed where it helps.

This unlocks everything the cloud can do. It also takes a year or more, carries the highest risk of any option, and competes directly with shipping product.

It is worth doing when the current architecture is genuinely the constraint on the business, not when it is merely old. Those are different conditions, and teams conflate them constantly.

One caution: re-architecting is where "while we are in here" kills projects. The scope expands because everything looks improvable once you are already rebuilding, and a nine-month project becomes a two-year one nobody wants to fund anymore.

How to actually choose

Skip the frameworks. Three questions settle it.

1. What is forcing this? A lease expiry or a hardware end-of-life means the clock is the constraint. Lift-and-shift, then improve. A capability you genuinely cannot deliver on current infrastructure means the architecture is the constraint, and re-architecture is on the table.
2. Is this system your differentiator? Re-architect the thing customers pay you for. Replatform or rehost everything else. Spending a year rebuilding your internal admin tool as a cloud-native masterpiece is a real thing teams do.
3. Can you afford to be slow for a year? Not financially, competitively. If a rival is shipping while you rebuild, the technically correct choice may still be the wrong one.

Notice that none of these are about technology. They are about time, focus, and what the business actually needs.

The playbook

Whatever strategy you pick, the sequence that works is the same.

• Inventory honestly. Almost every organization discovers systems nobody remembered, owned by nobody, that something critical depends on. Find these before they find you.
• Start with something that does not matter. Migrate a low-stakes system first. You are not testing the system; you are testing your process, your tooling, and your assumptions.
• Move data last, and rehearse it. Data migration is where projects die. Practice the cutover on real volumes, and time it, because "it worked in staging" means nothing when the dataset is a hundred times larger.
• Run both, briefly. Keep the old system live until the new one has proven itself under real load. Yes, it costs double for a few weeks. That is insurance, not waste.
• Decommission ruthlessly. The old system must actually be turned off. This is the most-skipped step, and skipping it means you now pay for two environments and maintain both.

That last one deserves emphasis, because it is where the promised savings evaporate. A migration that ends with the old environment still running has not reduced anything. It has added.

Why the bill goes up

The cost surprise is so consistent that it is worth naming the mechanics.

In a data center, you bought capacity once and it sat there. The cost was fixed, visible, and painful in a single annual conversation. In the cloud, cost is variable, invisible, and generated continuously by every engineer with deploy access.

Nobody notices that the test environment has been running all weekend. Or that a service was over-provisioned during a launch and never scaled back. Or that data egress charges exist at all until the first bill lands.

The savings the cloud genuinely offers, elasticity, are only real if you actually scale down. Most teams scale up and never scale back, which means they bought the expensive version of a fixed-capacity data center.

So build cost visibility from day one. Tag everything by team. Put the bill somewhere engineers see it. Make someone responsible for it who also has the authority to fix it.

This is not a finance concern you can defer. It is an engineering constraint, and if you introduce it in month eighteen you will spend a quarter unwinding decisions that should never have been made.

The timeline nobody believes until it happens

Ask any team how long their migration will take, then double it. This is not cynicism; it is a pattern with a specific cause.

The estimate covers the systems you know about. The overrun comes from the ones you do not.

Every organization has undocumented dependencies. A cron job on a forgotten server that populates a report someone senior reads every Monday. A hardcoded IP address in a config file nobody has opened in four years. An integration with a partner that only fires at quarter end.

None of these appear in your inventory. All of them appear during cutover, usually at the worst moment.

This is why the discovery phase deserves more time than feels reasonable, and why migrating a low-stakes system first is so valuable. That first migration is not really about the system. It is about finding out what you did not know.

Budget for discovery to change the plan. If it does not, you did not look hard enough.

What to do about the team

Here is the part that gets left out of migration plans entirely.

Your team knows how to operate your data center. After the migration, they need to operate something they have never operated, with different failure modes, different tooling, and a different mental model.

Nobody budgets for this. The plan covers the systems and assumes the people transfer for free.

They do not. An operations engineer who was excellent with physical infrastructure is a beginner with cloud networking, and being a beginner in production is how outages happen.

So build the learning in deliberately. Train before you migrate, not after. Let people run the new stack in low-stakes environments where mistakes are cheap. Expect a period of reduced velocity and plan for it rather than being surprised by it.

And be honest with the team about what is changing in their role. People can handle a hard transition. What they cannot handle is discovering, after the fact, that their expertise was quietly made irrelevant and nobody mentioned it.

The mistakes that recur

These show up over and over, and every one is avoidable.

1. Migrating for cost savings. The wrong reason, and it sets an expectation you will fail. Migrate for elasticity, speed, or managed services. If the bill drops, treat it as a bonus.
2. Big bang cutover. Moving everything at once means every problem arrives simultaneously, with no way to isolate what broke. Migrate in slices.
3. No rollback plan. If you cannot go back, you are not migrating, you are gambling. Test the rollback before you need it.
4. Lift-and-shift as the destination. It is a valid first step and a terrible final state. Have a written plan for what comes after, with a date on it.
5. Ignoring the humans. Your team now operates infrastructure they have never operated. If you have not invested in that, you have handed production to people you set up to fail, and that is a change management problem, not a technical one.

Frequently asked questions

The bottom line

Pick your strategy based on what is forcing the move, not on what sounds most modern.

Lift-and-shift when the clock is the constraint, and commit to a next step with a date on it. Replatform when you want real benefit without betting a year, which is most of the time. Re-architect only when the architecture is genuinely what is holding the business back.

Then migrate in slices, rehearse the data cutover, keep a tested rollback, and actually turn the old thing off.

And go in expecting the bill to rise. If you migrate for elasticity and speed rather than savings, the cloud delivers. If you migrate for savings, you will spend two years explaining an invoice.

One last thing worth saying plainly: the technical migration is the easy half. Whether it succeeds depends on your team operating something new and your organization working differently, which is where these projects actually fail. Start with an honest modernization audit, and let your architecture decisions follow the constraint rather than the fashion.