Cloud migrations have earned their bad reputation honestly. Nearly everyone has heard the story: a rushed lift-and-shift that doubled the bill, a cutover weekend that bled into a cutover month, a critical workload that behaved nothing like it did on-premises. The horror stories are real. They are also almost entirely avoidable, because the disasters share a cause -- migrating before understanding, and moving for its own sake rather than for an outcome.
A migration done well is undramatic. It moves the right workloads, in the right way, in a sequence that keeps the business running and the bill predictable. Here is how to get there.
Know why you are moving
The first question is not how to migrate. It is why. "Everyone is in the cloud" is not a reason, and migrations driven by fashion rather than outcome are the ones that disappoint. Good reasons are specific:
- Reliability and scale the current environment cannot deliver.
- Speed of delivery -- provisioning and shipping faster than owned hardware allows.
- Exiting a data center or aging infrastructure on a real deadline.
- Access to managed services that remove undifferentiated operational work.
The reason matters because it decides the approach. A move purely to exit a data center may favor speed; a move for long-term agility justifies more rework up front. Name the outcome, and the right path gets clearer.
Assess before you touch anything
Most migration disasters are really discovery failures. The workload that misbehaved in the cloud was misunderstood before it ever moved. So the first real phase is not migration -- it is mapping.
This is the Discover phase in practice: inventory the workloads, map their dependencies, understand their performance and data, and flag the ones that are load-bearing or poorly understood. The output is a clear-eyed picture of what you have and how hard each piece is to move.
This is exactly the analysis our Cloud, DevOps and Platform Engineering work produces as a cloud assessment: a workload inventory, a dependency map, and a migration plan that sequences the move by value and risk rather than moving everything at once and hoping.
Choose the right move for each workload
Not everything should be migrated the same way, and treating every workload identically is how costs balloon. Sort each one into a deliberate approach:
- Rehost (lift-and-shift). Move it largely as-is. Fast and low-risk, but it carries old inefficiencies -- and old costs -- with it.
- Replatform. Make targeted changes, such as moving to a managed database, to gain cloud benefits without a full rebuild. Often the pragmatic sweet spot.
- Refactor. Re-architect for the cloud. The most effort and the most reward, justified for the workloads that matter most.
- Retire or replace. Some workloads should not move at all -- retire what is unused, replace what a service does better.
The discipline is matching the effort to the value. Refactoring everything wastes money; rehosting everything carries your problems into a more expensive home.
Control cost from day one
The runaway bill is the most famous horror story, and it almost always comes from treating cloud like a rented data center -- everything always on, sized for a peak that rarely arrives, with no attribution. Avoid it from the start:
- Tag and attribute spend so every resource maps to an owner and a purpose. Untagged spend is unmanaged spend.
- Right-size to real usage, with headroom for spikes rather than provisioning for a worst case that never comes.
- Schedule and autoscale -- non-production does not run nights and weekends; production scales with demand.
Cost is a design decision, not an invoice surprise. Built in early, it stays controlled.
Migrate in waves, with a way back
The cutover weekend that turns into a cutover month is the product of a single, all-at-once leap. The safer path is waves: move a small, low-risk group first, learn from it, then move the next. Each wave is small enough to validate and, crucially, to roll back if it misbehaves. Value arrives continuously and risk stays bounded, rather than betting the business on one switch flipping cleanly.
Carry it through to operations
A migration that ends at "it runs in the cloud" is only half done. The same discipline that moved the workload has to keep it healthy:
- Secure -- build cloud controls and identity in as you go, not after.
- Deploy -- automated, governed releases so changes ship safely.
- Operate -- monitoring, support, and clear ownership so the new environment does not quietly decay.
- Recover -- tested backup and recovery for the migrated workloads.
The same partner carrying an idea through to operations is what keeps a migration from becoming a more expensive version of the problem you started with.
If the cloud is on your roadmap but the horror stories are giving you pause, the antidote is assessment, not nerve. A cloud assessment or a Technology Health Check can map your workloads, match each to the right approach, and lay out a wave-by-wave plan that protects both uptime and budget.