The cloud migration checklist we actually use

We have run more than twenty migrations, from a single overloaded server in a Midrand office to a 40-application estate at an insurer. Every one that went badly went badly for a reason that was visible weeks earlier, in the planning. So this is not a philosophy piece. It is the actual checklist, with the reasoning attached, so you can run it yourself or know what to demand from whoever runs it for you.

Inventory first, and expect surprises

The migration you plan is never the migration you run, because nobody remembers everything the old environment does. Budget a full week for discovery even in a small estate. The checklist for this phase:

• Every application, service, and scheduled job, with an owner named for each. Unowned things break silently.
• Every integration crossing the boundary: file drops, VPN tunnels, IP-whitelisted partners, that one SQL job the finance system depends on.
• Data volumes per system, because moving 4 TB over a 100 Mbps line takes four days by itself.
• Licences and support contracts that care where software runs.
• Hardcoded IPs, hostnames, and connection strings. Grep everything. You will find some.

Decide the style per workload, not per company

The classic options are rehost (lift and shift as-is), replatform (small changes, like swapping a self-managed database for a managed one), and refactor (rebuild for cloud services properly). Teams get stuck arguing which one "the migration" should be. Wrong question. Decide per workload.

At Vantage Mutual, 31 of 40 applications were rehosted in eight weeks, six were replatformed onto managed databases, and three were retired once discovery showed their last real login was in 2022. Only the policy engine earned a refactor, as its own project the following year.

The pre-cutover checklist

1. 1Stand up the target environment with infrastructure as code, even for a rehost. Clicked-together environments cannot be rebuilt or reviewed.
2. 2Move a low-stakes system first, end to end, to shake out the process before anything important travels.
3. 3Rehearse the data migration against production-sized copies and time it. The rehearsal timing decides your cutover window.
4. 4Define rollback per system: the exact conditions and the exact steps back. Untested rollback is a wish, not a plan.
5. 5Set up monitoring and alerting in the target before cutover, matching or beating the old environment.
6. 6Prepare DNS with low TTLs at least 48 hours ahead.
7. 7Freeze changes on the source a week out. Migrating a moving target is how data gets lost.
8. 8Write the cutover runbook as a timed, ordered list with a name against every step, and get every named person to read it.

Cutover day

Good cutovers are boring because the runbook did the thinking already. Keep the bridge call open, work the list in order, and record actual timings against estimates. Have a single decision-maker for the rollback call, decided in advance, because the worst moment to design a decision process is 02:40 with a half-migrated database. If a step runs more than double its rehearsed time, stop and diagnose rather than pushing on.

The first 30 days after

The migration is not done at cutover. Keep the old environment on standby but untouched for two to four weeks. Watch cost daily, because the first bill always contains surprises: oversized instances copied from on-premises specs, data transfer nobody predicted, forgotten test resources. Compare application performance against the baseline you captured before the move. Then, and only then, decommission the source and celebrate.

If you are planning a move and want a second pair of eyes on the inventory or the runbook, our cloud services team does exactly this. And once you land, the next job is keeping the bill honest, which we cover in cutting cloud spend without breaking things.