Lift-and-shift is a checkpoint, not a finish line

Most cloud migrations start the same way: move the workload as-is, get it running on managed infrastructure, declare victory. It’s the fastest path to “we’re in the cloud now,” and for a hard deadline — a data-center contract ending, hardware past end-of-life — it’s often the right first move. The mistake is treating it as the whole project.

What lift-and-shift actually buys you

Moving a VM-based application onto equivalent cloud infrastructure gets you out of the business of owning hardware. That’s real value: no more capacity planning years in advance, no more waiting on a procurement cycle to add resources, a much shorter path to disaster recovery. It does not, by itself, get you elastic scaling, a lower run-rate cost, or the reliability guarantees people associate with “being in the cloud.” Those come from re-architecting, not relocating.

The gap people don’t expect

An application built for a fixed data center — with a monolithic deployment, a database sized for the biggest instance you could buy, and no concept of horizontal scaling — behaves the same way on cloud VMs as it did on physical servers. It just costs differently, and not always less. We’ve seen lift-and-shift migrations land with a higher monthly bill than the on-prem setup they replaced, because nothing about the workload changed to take advantage of what the cloud is actually good at: paying for capacity as you use it, not as you provisioned it.

What the second phase looks like

Once the workload is safely off legacy infrastructure, the re-architecture work usually falls into a few buckets:

1. Decompose what benefits from it. Not everything needs to become microservices — that’s its own trap. But the parts of the system with genuinely different scaling or deployment needs (a reporting job, a public API, a background worker) usually benefit from being separated from the core application.
2. Move state to managed services. A self-managed database on a VM is one of the highest-maintenance, highest-risk components in most stacks. Migrating it to a managed offering removes an entire category of operational burden — patching, backups, failover — that was never core to the business anyway.
3. Make scaling automatic, not manual. If someone still has to notice load and resize an instance by hand, the migration bought infrastructure flexibility that nothing in the application is using yet.
4. Revisit cost as an architecture input, not an afterthought. Cloud billing exposes cost per resource in a way on-prem accounting rarely did. That visibility is only useful if someone acts on it — right-sizing instances, moving cold data to cheaper storage tiers, shutting down non-production environments outside business hours.

The honest timeline

Lift-and-shift can happen in weeks. The re-architecture work is measured in months, and it’s tempting to skip once the migration deadline has passed and the pressure is off. That’s usually the point where the cost and reliability benefits people expected from “moving to the cloud” quietly fail to show up — not because the cloud didn’t deliver, but because the workload was never changed to ask for them.

Plan the second phase before the first one starts. It’s much easier to get budget and attention for re-architecture as a continuation of a migration everyone already agreed to, than as a separate project competing for priority six months later.