Lift-and-shift has an honest use: getting out of a data centre before a lease ends. As a strategy for value, it disappoints reliably, because a virtual machine that was hard to operate in a rack is still hard to operate in a region — now with a metered bill.
The return on a migration comes from the things you change while you are moving.
Pick the outcomes first
Before any workload moves, write down what should be measurably different afterwards. Useful candidates:
- Recovery time. Restoring a critical system takes a day today. What should it take, and can we demonstrate it?
- Release frequency. Deploying needs a weekend and three people. What would it take to make it a Tuesday afternoon?
- Capacity. We size for a peak we guessed a year ago. What would it look like for capacity to follow actual demand?
- Environment parity. Staging differs from production in ways nobody has fully documented. What would it take for them to be built from the same definition?
If a migration plan cannot name at least two of these, it is a relocation rather than an improvement.
Infrastructure as code, from the start
The single change that produces most of the operational benefit is defining infrastructure in version control rather than in a console.
It means an environment can be rebuilt instead of repaired, which is what turns disaster recovery from a document into a test you can actually run. It means staging and production genuinely match, because they come from one definition. And it means a change to infrastructure goes through review like any other change.
Retrofitting this after a migration is possible but considerably less pleasant than doing it as part of one.
Migrate in slices, with a way back
Move one workload. Run it. Keep the ability to fail back until you are confident. Then move the next.
This is slower on paper than a coordinated cutover and faster in practice, because the first slice will teach you things about networking, identity and dependencies that no amount of planning surfaces. Learning those on a low-stakes workload is very much cheaper than learning them during a whole-estate cutover with no way back.
Watch the cost model change shape
On-premise capacity is a capital decision made occasionally. Cloud capacity is an operational decision made continuously, by whoever provisions a resource.
Without ownership and visibility, spend drifts. The fix is not complicated — tag resources by owner, review spend monthly, set alerts on unusual growth, and shut down non-production environments outside working hours. It just has to be someone's responsibility from the first month rather than a reaction to the first surprising invoice.