Cloud migration planning: from inventory to a cutover you can roll back

Assumptions and when this guide does not apply

This guide assumes you are moving a small-to-medium estate: one to a few dozen servers or virtual machines, a handful of databases, some object or file storage and public DNS you control. The target can be a VPS, cloud, managed hosting or bare metal; the method is the same.

It does not fully cover these cases:

• Petabyte-scale data. At that size, network transfer can take weeks and physical transfer appliances or staged seeding are usually cheaper and faster. The arithmetic below will tell you when you have crossed that line.
• Regulated data with residency rules. Legal review of where data may sit and travel comes first; this guide only covers the mechanics.
• Active-active multi-region systems already built for zero-downtime moves. You will use their own failover procedures instead of a cutover window.

All throughput figures in the examples are stated assumptions, not measurements of any provider. Measure your own link before you plan a window.

Step 1: build an inventory you would bet the window on

An inventory is not a list of hostnames. For each workload you need enough detail to rebuild it from scratch if the copy fails. Pull it from three sources and reconcile them, because each one misses things the others catch: what the team believes runs, what the servers report (process lists, listening ports, installed packages, scheduled jobs), and what the network shows (flow logs or connection tables over at least one full business cycle, including month-end jobs).

Outbound dependencies are the most often missed item. Payment gateways, SMS and email providers, partner APIs and database firewalls frequently allow-list your current public IP. If the new environment sends from a different address, those calls fail after cutover even though everything looks healthy from inside. List every one and request the new IPs in advance.

Step 2: map dependencies and group into move waves

Draw which workload talks to which, with the protocol and direction. The goal is to find groups that must move together because splitting them would put a slow or metered link in the middle of a chatty conversation. A web tier that makes 40 database queries per page will feel fine on a local network and painful across the internet: at an assumed 20 ms round trip, 40 sequential queries add 800 ms to every page.

Group workloads into waves. A good first wave is low risk but exercises the whole process (staging, an internal tool, a static site), proving the network path, DNS steps and runbook. Put the systems with the most inbound clients and the strictest downtime tolerance in later waves, when the team has rehearsed.

Step 3: choose rehost, replatform or something else per workload

Cloud providers describe migration strategies as the "7 Rs". You do not need all seven for a small estate, but naming the choice for each workload stops scope creep in the middle of a move.

The practical default for small teams is rehost first, replatform after. Moving and changing in the same window doubles the number of things that can break and makes rollback harder, because the old environment no longer matches the new one. The exception is an OS at or near end of support: copying an unsupported OS to a new host only moves the problem, so rebuild on a supported release and redeploy the application.

Step 4: calculate data transfer time before you pick a window

Transfer time is arithmetic, and it is the number that most often makes a planned window impossible. The formula:

time (seconds) = bytes x 8 / (link speed in bits per second x efficiency)

Efficiency covers protocol overhead, TCP behavior over distance, encryption cost, disk read speed at the source and write speed at the target, and the fact that you rarely get the whole link. For transfers across the public internet, an efficiency between 0.6 and 0.8 is a reasonable planning assumption; measure it with a test copy of a few gigabytes over the real path before relying on it. Use decimal units consistently: 1 TB = 10^12 bytes, 1 Gbps = 10^9 bits per second.

The answer to a long initial sync is not a longer outage: copy the bulk while the old system is live, then copy only the changes in the window.

Enter your own volumes, link speed and change rate in the migration capacity calculator to get the initial sync, final delta and the window you need, with a margin for verification.

Step 5: lower DNS TTLs early enough to matter

A DNS record's TTL tells resolvers how many seconds they may cache the answer (RFC 1035). If your A record has a TTL of 86,400 seconds (one day), a resolver that looked it up a minute before cutover can keep sending users to the old address for almost a day after you change it.

The rule: lower the TTL at least one full old-TTL period before cutover. If the current TTL is 86,400 seconds, set the new low value (for example 300 seconds) at least 24 hours before the change, and preferably 48 hours to absorb mistakes. After that, every cached copy has expired and been refetched with the short TTL, so the switch propagates in minutes.

Three caveats. Some resolvers and runtimes apply their own cache limits, so expect a tail of old traffic. Records you are creating rather than changing are subject to negative caching, controlled by the SOA record's minimum field (RFC 2308), so a lookup for a name that did not exist yet can be cached as "does not exist". And if you are also moving the DNS hosting itself, the NS records at the registry have their own TTL, often long, which you cannot shorten on the parent side; move DNS hosting in a separate, earlier change.

Step 6: move databases by replication, or by dump and restore

There are two ways to move a database, and the choice is about how much downtime you can accept.

With replication, the outage shrinks to the time it takes to stop writes, confirm the replica has applied everything (replication lag at zero), promote it and repoint the application. In PostgreSQL logical replication, the official documentation lists restrictions that bite at cutover: DDL is not replicated, so freeze schema changes during the migration; sequence values are not replicated, so set every sequence on the target above the current maximum before you open it for writes; and large objects are not replicated at all. For MySQL, check binary log format and GTID settings in its manual.

Step 7: write a cutover runbook with rollback criteria

A runbook is a timed list of steps, each with an owner, a check and the decision that follows. Rehearse it on staging and agree rollback criteria with the business owner in advance, so nobody argues at 03:00 about "good enough".

1. T-48 h: freeze. TTLs lowered, schema and config changes frozen, final rehearsal done, outbound IP allow-lists updated at third parties.
2. T-1 h: last incremental sync. Record its duration to predict the final delta.
3. T-0: go/no-go call. Named people confirm backups of the old system are fresh and restorable, the target passed smoke tests, and rollback steps are ready.
4. Stop writes. Maintenance page or read-only mode; disable scheduled jobs on the old side.
5. Final sync and database switch. Confirm replication lag is zero or the restore completed; fix sequences.
6. Switch traffic. Change DNS or load balancer targets.
7. Validate. Run the checklist below against the new environment from outside your network.
8. Decision point. Declare success or roll back, using the criteria agreed in advance.
9. Re-enable jobs on the new side only.

Rollback criteria should be measurable. Examples: error rate on key pages above an agreed level for 15 minutes; any failed payment or order write; login failure for a test account; data checks (row counts, checksums) not matching. Set a point of no return: the moment after which new writes land only in the new system and rollback would mean losing or hand-merging them. Before that point, rollback is "point DNS back and re-enable the old side". After it, rollback needs a reverse sync, so plan it or accept that you will fix forward.

Validation checklist

Run these from outside your network before declaring success.

• DNS answers with the new address from at least two public resolvers (dig @1.1.1.1, dig @8.8.8.8).
• TLS certificate is valid for every hostname, with the full chain, and not close to expiry.
• Key user journeys work end to end: sign-in, search, checkout or form submit, password reset email.
• Writes land in the new database, and none reach the old one.
• Row counts and checksums match for critical tables between the final source snapshot and the target.
• Outbound calls to payment, email, SMS and partner APIs succeed from the new IPs.
• Scheduled jobs are enabled on the new side and disabled on the old side.
• Backups run on the new environment, and one test restore has succeeded.
• Monitoring and alerting point at the new hosts, and a test alert reached a human.
• Logs are flowing to wherever you keep them, with the right retention.
• Error rates and response times are within the ranges you recorded before the move.

Post-cutover tasks

The migration is not finished when traffic moves. In the following weeks:

• Right-size. Compare the first two weeks of real usage with what you provisioned. Rehosted servers are often oversized because they were sized for old hardware.
• Raise TTLs back to a normal value once you are sure you will not roll back.
• Decommission deliberately. Take a final backup of the old system, keep it for the retention period you agreed, then wipe and cancel. Remove old IPs from allow-lists and firewall rules.
• Review costs against the estimate with the first full invoice; see the hosting TCO guide.

Common mistakes

• Lowering TTL on the day of cutover. It has no effect on answers already cached with the old long TTL.
• Planning the window from the dump time only. Restore and index builds usually take longer than the dump.
• Using line rate in transfer estimates. A 1 Gbps port does not move 125 MB/s end to end across the internet; measure efficiency.
• Running cron jobs on both sides. Invoices, emails or billing runs fire twice.
• Forgetting outbound allow-lists. Payments and partner APIs fail even though the site loads.
• Deleting the old environment too soon. It is your rollback path.
• No backup test on the new side. See the backup and recovery guide.

Related