Cloud migration checklist: what breaks and what costs

A cloud migration is rarely an infrastructure problem. It is a sequencing problem with a network topology attached. Move the wrong thing first and you spend the rest of the project working around a decision you cannot undo without starting over.

Most migration plans start with a list of workloads and a target architecture. That list is useful, but it is not the thing that determines whether the migration succeeds. What determines success is the order, and the order follows a pattern that repeats across every migration I have done or audited.

1. Network before compute

The most expensive mistake is deploying a service before its network path exists. The service is unreachable, or reachable in one direction, or reachable with a latency profile nobody tested — and now you are debugging routing while the migration clock is running.

Build the VPC or VNet first. Peer it. Test reachability from every source that matters — CI runners, developer machines, dependent services still in the old environment. Only then provision compute.

The rule is simple: if you cannot curl the empty endpoint from where it will be called, do not deploy the thing that answers the call.

2. DNS is the hidden migration

Every cloud migration includes a DNS migration, whether or not the plan mentions one. Services discover each other by name, and those names resolve to IPs that change when the service moves.

The pattern that works:

• Set TTLs low (60–300 seconds) on all records that will move, at least one TTL window before the migration starts. A migration that waits for a 24-hour TTL to expire is a migration that takes 24 hours longer than planned.
• Do not point a live record at two targets that serve different data. The traffic split is not 50/50, and the inconsistency is invisible until a user reports it.
• Know who controls each domain. In a company of 50+ engineers, the person who owns the DNS zone for internal.example.com is often not the person who requested the migration — and finding them takes two days.

3. Data before compute (again)

Services that migrate without their data are not services. The database, the object store and the configuration store have to move first, and they set the timeline.

Databases in particular have a minimum migration duration determined by the size of the dataset and the write throughput it sustains. You cannot make a 500 GB database transfer faster by deploying the application earlier — you can only deploy the application to an empty database and wonder why nothing works.

For databases with active writes, use the cloud provider's replication tooling where it exists (AWS DMS, Azure Database Migration Service). Where it does not, or where the source is self-managed, plan for a read replica and a cutover window. The window exists whether or not the plan names it; naming it is how you prevent it from being midnight on a Saturday.

4. The cost spike nobody forecasts

Every migration includes a period of double-running — the old environment and the new one, both billing, for as long as the cutover takes. In a carefully sequenced migration this is days. In one where step 1 was deployed before the network existed, it is weeks.

Model the double-run cost explicitly. It is a line item in the migration budget, not a surprise on the first post-migration invoice. If the number is high enough to make someone nervous, it is also the argument for sequencing carefully enough that the window is short.

One more cost spike that repeats: data transfer. A migration that moves a petabyte of data into a cloud provider's object store pays egress from the source and nothing for ingress — but if you move it out again, you pay. Know the egress pricing before you pick a target region, and know whether your data is coming back out.

5. Security and compliance before launch

The new environment has to pass the same controls as the old one. If the old environment was SOC 2-compliant, the new one is SOC 2-scoped — and deploying first and documenting later means operating an unaudited production environment.

At minimum, before the first production workload lands:

• Encryption at rest and in transit, configured by policy, not by prayers
• Access controls — IAM roles / RBAC with least privilege, not a shared admin credential
• Logging and audit trail enabled and shipping to a destination your compliance team can access
• Network segmentation — production isolated from non-production, data plane isolated from control plane

These are not migration tasks. They are the platform tasks that have to be done once, and doing them after migration means retrofitting security onto a running system — which is harder, slower and more expensive than building them first.

6. Cutover without a rollback plan is a prayer

Every service that moves should have a rollback path. The rollback path is not "restore from backup" — it is the list of steps you will follow if the new deployment does not pass its health checks within the cutover window.

A workable rollback has three properties:

1. It is written down, not held in someone's head
2. It has been tested on a non-production instance
3. It completes within the cutover window, not an hour after it

If the rollback takes longer than the cutover window, the cutover window is wrong — either it is too short for the risk, or the rollback is too slow for the window. Fix one or the other.

The truth about migration timelines

A migration that is "two months of prep and one weekend of cutover" is a migration where the prep was not deep enough, or the cutover was not honest. The prep that matters is the one that makes the cutover boring — because a boring cutover is a successful one, and an exciting one is an incident with a deadline.

---

Hitting this on a migration? I take on cloud cost audits and Kubernetes platform builds as freelance and contract work — independently, for teams in the US, EU and APAC.