Migrating a client's site to a new host, or their domain to a new registrar or DNS provider, is one of the few genuinely high-stakes moments in this kind of work. Get it wrong and the client's site or email goes down in front of their customers — and unlike most findings you report and fix on your own schedule, a botched cutover is visible immediately and damages trust fast. This is the checklist to work through, in order, every time.
Before: document everything — this is your rollback plan
Do this before you touch anything. If the migration goes sideways, this is what gets you back to a known-good state fast instead of guessing under pressure.
Current DNS records. Run the domain through DNS Lookup and write down what you see — every A/AAAA record, the MX records, TXT records (SPF and anything else), CNAMEs, and NS records. This is your exact "before" snapshot. If the new host or provider gets something wrong, you can compare against this and know precisely what changed.
Current registrar and expiration. Run it through WHOIS Lookup and note the registrar and expiration date. You want to confirm two things before a migration: that the domain isn't about to expire mid-move (a migration is exactly the kind of distraction that causes an expiring domain to get missed), and that you actually know who currently controls the registrar account, in case you need access during the cutover.
Current SSL setup. Run the current site through SSL Checker and note the issuer and expiration date. If the new host issues its own certificate (common with managed hosting or a CDN), you'll want to confirm the new one is actually live and valid after cutover, not just assume it carried over.
Before: lower the TTL in advance
TTL (time to live) is how long resolvers are allowed to cache a DNS record before checking again. If the current A record has a TTL of 86400 (24 hours), a change you make won't be visible everywhere for up to a full day, because resolvers around the internet are still serving the cached value from before your change.
The fix is simple and easy to forget: lower the TTL well before the actual cutover, not at the same time. Drop it to something short — 300 seconds (5 minutes) is common — at least 24-48 hours ahead of the migration. That gives the old, long TTL time to fully expire everywhere first. Change the TTL and the record at the same time, and you're still stuck waiting out the old TTL, because that's the value everyone already cached.
During: what "propagation" actually means
"DNS propagation" is not a single global event that finishes at some knowable moment — it's every individual resolver's cache independently expiring and re-checking, on its own schedule, based on the TTL it saw. This is the most common misconception clients (and sometimes less experienced technicians) have about a cutover: that flipping the record should be instant everywhere.
In practice, this means: right after you make the change, some visitors will immediately see the new site (resolvers with no cached value, or a very short TTL), while others will keep seeing the old one for minutes to hours (resolvers that cached the old record with a longer TTL, or ISPs that don't strictly honor TTL and cache longer anyway). Both are correct, expected behavior — not a sign that something's broken. Set this expectation with the client before the cutover, not after they ask why their coworker sees something different than they do.
During: making the cutover
With the TTL already lowered and your before-state documented, the actual change is usually the fast part:
- Confirm the new host or DNS provider is fully ready — site or mail actually working at its new location, reachable directly by IP or a temporary hostname if possible, before you point real traffic at it.
- Update the DNS records (A/AAAA, and MX/TXT/CNAME as needed) to point at the new location.
- If moving registrars or nameservers entirely, that's a separate, larger propagation window than a simple record change — budget more time and expect a longer settling period.
- Don't raise the TTL back up yet. Leave it low for a few days after cutover, in case you need to make a quick correction or roll back.
After: verify the cutover actually succeeded
Don't consider the migration done the moment you save the change — verify it.
Re-check DNS Lookup. Run the domain through DNS Lookup again and confirm the records now show the new values — new IP, new mail routing if that changed too. If you still see old values, that's expected in the first stretch (see the propagation note above), not immediately a problem.
Check Reverse DNS on the new IP. Run the new server's IP through Reverse DNS Lookup to confirm it resolves the way you'd expect for the new host. This matters most when mail is involved — a mismatched or missing PTR record on the new IP can hurt deliverability even if everything else is correctly configured.
Re-check SSL Checker on the new host. Run the domain through SSL Checker once more, now that traffic is landing on the new host. Confirm the certificate is valid, correctly issued, and not still showing anything from the old setup.
Bookmark this page — it's built to be the checklist you actually pull up during your next migration, not just a one-time read.