The migrations that go wrong tend to go wrong the same way. Someone decides to “move to the cloud,” a date gets set, and the plan is to lift everything across one long weekend. Then the weekend arrives, a dependency nobody documented breaks, the rollback is shaky, and Monday morning is spent explaining why checkout is down.
The migrations that go well are boring by comparison. They move one thing first, learn from it, and only then move the rest. That is the whole trick, and it is less about clever tooling than about sequencing the work so a mistake stays small.
Here is the plan we run.
Phase 1: Assess before you touch anything
You cannot move what you do not understand, and most teams understand their system less well than they think. There is always a cron job on a forgotten server, a hardcoded IP, a database nobody is sure is still in use.
So the first phase is inventory. List the workloads. Map what talks to what, including the awkward integrations and the scheduled jobs. Get a rough read on cost and risk for each piece. Then pick the first workload to move, and pick it for being low-risk and self-contained rather than important. The goal of the first move is to learn, not to impress anyone.
This phase produces a plan and a cost range, not code. It is tempting to skip. Don’t. Every painful migration we have been called in to rescue skipped it.
Phase 2: Pilot with one real workload
Now move that first low-risk app, and do it properly, because this pilot becomes the template for everything after.
Properly means a few specific things. The infrastructure goes into code, with a tool like Terraform, so it is reproducible and reviewable instead of clicked together in a console and forgotten. A real deployment pipeline gets set up, so shipping a change is one reliable step rather than a manual ritual. And you watch how it behaves under actual traffic, not just whether it boots.
By the end of the pilot you should have a playbook: this is how we containerize, this is how we deploy, this is how we roll back, this is what we monitor. The second workload is far easier than the first because you are following a path you already walked.
Phase 3: Migrate piece by piece
With a proven playbook, you move the rest. The pattern that keeps this safe is the strangler approach, named after a vine that grows around a tree and gradually replaces it.
Instead of a big cutover, you route a slice of traffic to the new system while the old one keeps running. You move one component, confirm it behaves, then move the next. The old and new run side by side for a while, which feels redundant and is worth every penny, because if something is wrong you shift traffic back in seconds instead of restoring from backup at 2am.
You only retire the old system once the new one has earned it. No heroic weekend. No single moment where everything has to work at once.
Phase 4: Optimize once it is stable
Here is the part teams forget: the cloud bill after a straight migration is almost always too high. You moved your old sizing assumptions to a place that charges by the hour, and those assumptions were built for hardware you had already paid for.
So once things are stable, you tune. Right-size the instances that are clearly overprovisioned. Turn on autoscaling so you stop paying for peak capacity around the clock. Move cold data to cheaper storage. Switch off the environments nobody uses overnight. We have seen this phase alone recover a meaningful share of the monthly bill, and it costs almost nothing to do.
Optimization is also when you finish the observability story, so that the next problem shows up on a graph before it shows up in a support ticket.
The thread running through all of it
Every phase is built so a mistake stays contained. One workload at a time. Both systems running during the switch. Infrastructure you can rebuild from code if you have to. None of it is exciting, and that is the point. A migration should be the least dramatic project on your roadmap.
If you are planning a move and want it to go the boring way, that is what we do. Have a look at how we approach cloud and DevOps, or book a scoping call and we will sketch a first phase with you.