How to Migrate DNS to a New Provider with Zero Downtime
Migrating your DNS to a new provider without downtime is entirely achievable — the secret is order of operations: replicate everything first, lower TTLs in advance, and only switch nameservers once the new setup is verified. Rushing any step is what causes outages. Here is the safe playbook.
Step 1: Lower your TTLs in advance
Several days before the move, reduce the TTLs on your records (to a few minutes) at your current provider. This must be done at least one old-TTL period ahead so caches expire and start holding the short value — the key to a fast, clean cutover. See how propagation works.
Step 2: Recreate every record at the new provider
Export your current zone and recreate all records at the new provider before changing anything live:
- A / AAAA — every host.
- MX — so email keeps flowing.
- TXT — including SPF, DKIM and DMARC, or mail breaks.
- CNAME, SRV, CAA and any others.
Missing even one record (a stray subdomain, a DKIM key) is the most common cause of a broken migration.
Step 3: Verify the new zone before switching
Query the new provider's nameservers directly with dig @newns yourdomain.com for each record type, and compare against the old zone. Confirm they match exactly. Do this before touching your nameservers — you are testing the destination while the live site is untouched.
Step 4: Update the nameservers
Once verified, change your domain's nameservers at the registrar to the new provider — see updating nameservers. Because both old and new zones are identical, visitors get the same answers whichever they hit during the transition, so there is no downtime.
Step 5: Wait, then decommission
Keep the old zone live and unchanged until the nameserver change has fully propagated (allow a couple of days, as registry/TLD changes are slower). Only after traffic has clearly moved to the new provider should you remove the old zone. Then raise your TTLs back to normal.
Frequently asked questions
Will my site go down during a DNS migration?
Not if both zones hold identical records before you switch nameservers. Since visitors get the same answer from either provider during the transition, there is no gap — the whole point of recreating and verifying first.
Why keep the old DNS live after switching?
Because nameserver changes take time to propagate, some resolvers keep using the old nameservers for a while. Keeping the old zone identical and live means those users still get correct answers until everyone moves over.
What most often breaks a DNS migration?
Forgetting records — especially TXT records like SPF and DKIM, or an obscure subdomain — so email or a service breaks after the switch. Export everything, recreate it all, and verify each record type against the old zone before cutting over.
Was this article helpful?