Planning a Cloud Migration That Does Not Overrun

Build the inventory first

1. Every server, with its purpose, size and actual utilisation.
2. Every database, with size, engine, version and who reads it.
3. Every scheduled job, including ones on individual machines rather than a scheduler.
4. Every integration — inbound and outbound, including anything with an IP allow-list on the other side.
5. Every domain, DNS zone and TLS certificate, with expiry dates.
6. Every credential, and where it is stored.
7. Every dependency between the above.

The dependency map is the part that determines sequencing, and the cron jobs are the part most often missed. Check every machine, not only the ones in the documentation.

Choose a strategy per workload

Run the retire assessment seriously. Most estates carry systems nobody uses, and every one removed is work you do not have to do.

Rehost first and optimise later is usually right. Refactoring during a migration combines two risky changes and makes it impossible to tell which one broke something.

Sequence from the edges inward

1. Start with something low-risk and self-contained, to establish the process and find the surprises early.
2. Move stateless components before stateful ones.
3. Move development and staging first; they are a genuine rehearsal.
4. Group tightly coupled systems and move them together — splitting them across environments creates latency and egress cost.
5. Move the database last within each group, since it is the hardest to reverse.
6. Keep a rollback path until each group has run under real load.

Cutover

The moment of switching. Plan it in writing:

• Lower DNS TTLs at least 48 hours in advance.
• Run both environments in parallel where possible, with data replicating.
• Choose a window with low traffic and full team availability.
• Write the rollback procedure before you need it, and set the deadline at which you will use it.
• Have a checklist of what to verify afterwards, agreed in advance.
• Decide who makes the call to proceed or roll back, and make sure everyone knows who that is.

The rollback deadline is the discipline that matters. Without one, teams push on through a failing cutover because stopping feels like defeat.

Costs that surprise people

• Egress from the old provider during data transfer, which can be substantial for large datasets.
• Running both environments in parallel for weeks — budget for it explicitly.
• Right-sizing not done, so the old server specifications are copied and over-provisioned.
• New line items — NAT gateways, load balancers, managed service premiums.
• Support plan, if the new provider requires one for reasonable response times.
• Engineering time, which is almost always the largest cost and rarely in the estimate.

Several providers now waive egress charges for a full migration away, following regulatory change. Ask before assuming you will pay it.

After the move

1. Right-size everything using two weeks of real utilisation data.
2. Decommission the old environment deliberately, after a defined retention period.
3. Cancel old contracts and subscriptions — this is often forgotten for months.
4. Set budgets and alerts on the new environment.
5. Document what actually happened, including what went wrong.
6. Review whether replatforming or refactoring is now worth doing on the highest-cost workloads.

Common questions

Where to go next

See migrating a website to a new server and database migration strategies.