How to Plan a Host Migration Checklist Before You Touch DNS

A host migration checklist is an ordered list of everything that must be true before, during, and after you move a site from one server to another, and its purpose is to make the DNS change the least interesting step in the process. The order matters more than the length: inventory first, staging second, DNS cutover third, verification last, because each stage depends on facts the previous one established.

The single most common failure in a host move is treating DNS as the starting gun. It is not. DNS is the switch you flip once everything else already works on the new host, with the old host still serving traffic and still available to switch back to. Plan the move so that at the moment of cutover, nothing is being tested for the first time.

Stage one: inventory before the host migration checklist grows

You cannot migrate what you have not enumerated. Start with the domain's DNS zone, because it is the authoritative description of everything the outside world asks of you. Pull the full zone from the current provider rather than reading it off a control panel screen, since panels hide records and truncate long values.

dig +noall +answer example.com AXFR @ns1.example.com
# or, without zone transfer access, enumerate what you know:
dig +short example.com A
dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short www.example.com CNAME

Record every entry: A, AAAA, CNAME, MX, TXT (including SPF and DKIM selectors), SRV, and any delegation via NS for subdomains. Note the TTL on each record, because TTLs govern how long stale answers linger in resolvers after you change them. Lowering TTLs is a change you make days ahead of the move, not on the day, otherwise the old long TTL is still in caches when you flip.

Then inventory the application itself. Which document root, which PHP or runtime version, which extensions, which scheduled jobs in crontab -l, which daemons under systemd, which TLS certificates and how they renew, which outbound mail path, which storage buckets or external services are reached by IP allowlist. An IP allowlist is the quiet killer of migrations: the new server's address is not on someone else's list, and a payment or API integration fails silently after cutover. Write down every place your current server's IP appears.

Finally, inventory data volume and write patterns. Dump sizes tell you how long a copy takes; write rates tell you whether a simple copy will be stale by the time it finishes. For a busy database, plan a consistent snapshot plus a short freeze or a replication catch-up, not a naive mysqldump over a live, heavily written table.

Stage two: build and test the new host in parallel

The new host should be a complete, working copy of the site before any public DNS record changes. The cleanest way to test without DNS is to point your own resolver at the new server for the domain. On a machine you control, add an entry to /etc/hosts mapping the domain to the new IP, or use curl's resolve option so the test does not depend on local DNS at all.

curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ \
  -o /dev/null 2>&1 | grep -E '^(<|>) (HTTP|location|set-cookie)'

That request exercises TLS, the virtual host, the application, redirects, and cookies against the new server while the rest of the internet still sees the old one. If the site uses absolute URLs generated from a configured hostname, check that the staging configuration does not bake the wrong hostname into links, sitemaps, or password reset emails. Verify the certificate chain with openssl s_client -connect 203.0.113.10:443 -servername example.com and confirm the served certificate matches the name you expect.

Rehearse the data copy on the real volume, not a toy subset, and time it. Then rehearse it again with the delta you expect between the first copy and cutover. Confirm that file ownership, permissions, and any .htaccess or server config rules behave identically, since a rule that relied on an Apache module the new host lacks will simply be ignored. Check the mail path end to end: send a message through the new host and read the Received headers to confirm it left through the expected relay with valid SPF alignment.

Stage three: the DNS cutover itself

Cutover is a sequence of small, reversible steps, each verified before the next. Lower TTLs well in advance, confirm the reduced TTL is what resolvers actually see with dig example.com A +ttlid, then make the change. Change the records at your authoritative nameservers first, and only move the registrar's NS delegation if you are also changing DNS providers. Those are two separate operations and doing them in the same hour makes failures hard to attribute.

Keep the old host running and reachable throughout. If the application writes to a database, decide explicitly whether the old and new hosts share it, replicate it, or whether you accept a short maintenance window. A maintenance window with a clear start and end beats a silent split-brain where two servers both accept writes.

Watch propagation from outside your own network, because your resolver is the least representative observer you have. Query public resolvers directly and confirm they return the new address:

dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8
dig +short example.com NS
dig +trace example.com A | tail -n 20

If old answers persist past the TTL you set, check for a second authoritative source, a hidden secondary, or a CDN in front of the domain that is caching independently of DNS.

Stage four: verification after the switch

Verification is not "the homepage loads". Walk the site as three different clients: an anonymous visitor, a logged-in user, and a crawler. Confirm that forms submit, that sessions persist across requests, that uploads land in the right place and are served back, that transactional email arrives, and that any background job actually runs on schedule. Check the server error log and the application log for the first hours after cutover; a 500 on one seldom-used endpoint is easy to miss and hard to explain later.

Verify mail authentication with the records that matter, not just the ones that are easy: SPF, DKIM, and DMARC all resolve and align, and the sending IP is not on a blocklist you inherited. Confirm backups run from the new host to storage you control, and restore one file from a backup to prove the backup is not empty. Keep the old host in a read-only or suspended-but-restorable state for a defined cooling-off period, with its data intact, until you are confident nothing is missing.

What to do next

Take the inventory step seriously before anything else: dump the full zone, list every cron job, daemon, certificate, and IP allowlist entry, and write the cutover sequence down as literal commands with the expected output beside each one. Then rehearse the whole thing end to end against the new host using --resolve or a hosts file override, so that on the day of the move the only new thing is the DNS change itself. If any step in your checklist cannot be verified from a terminal, rewrite that step until it can.