How to Switch DNS Providers Without Downtime: A Step-by-Step Checklist

Moving your domain to a new DNS provider has a reputation for being scary. In reality, the DNS protocol is remarkably forgiving — most "migration outages" are not protocol failures at all. They're sequencing failures: records missing on the new provider before the switch, TTLs left high so a mistake takes a day to heal, or the old zone deleted while some resolvers are still asking it.

This checklist is the sequence that avoids all three. It works for a personal blog, a SaaS product, or a storefront, and every step can be done with free tools.

Why migrations break: caches, not the protocol

DNS is cached at every layer — your OS, your browser, and thousands of recursive resolvers at ISPs and public providers. When you change nameservers, old answers keep circulating until their TTLs expire. That's by design: caching is what makes DNS fast.

The catch is that a migration changes two things independently:

• Your records (what the answers are), served by your DNS provider.
• Your delegation (who is authoritative), set at your domain registrar.

If you flip the delegation while the new provider's zone is incomplete, some resolvers get correct answers from the old servers while others get empty or wrong answers from the new ones. That's the classic self-inflicted outage, and it's entirely avoidable with the right order of operations.

Step 1: Inventory every record before you touch anything

Before signing up anywhere, export or manually record your complete zone:

• A / AAAA records for every hostname, including wildcard entries.
• CNAME records, plus any apex-level alias (more on that below).
• MX records and their priorities.
• TXT records — especially your SPF, DKIM, and DMARC strings, which are long and easy to truncate by accident.
• SRV, CAA, NS and anything else in the zone.

Two warnings from experience:

1. Email is what breaks first. MX and mail-authentication TXT records are the most commonly dropped records in a migration.
2. CAA records fail silently. Drop a CAA record and everything keeps working — until a certificate renewal weeks later suddenly fails, and nobody connects it back to the migration.

A screenshot of your provider's dashboard is not a backup. If your provider supports zone file export, use it. If not, copy records into a zone file template by hand and keep it in version control.

Step 2: Lower TTLs 24–48 hours before the cutover

This is the step people skip, and it's the one that determines whether a mistake costs you five minutes or a full day.

TTL (time-to-live) is how long resolvers are allowed to cache an answer. Many providers default to TTLs of several hours or more. At least a day before your migration, lower the TTL on every record in the zone to something short — 300 seconds is a common choice for the migration window.

One subtlety: a TTL change itself propagates at the old TTL. If a record currently has a 24-hour TTL and you lower it to 300 seconds today, resolvers that cached the record yesterday will keep honoring the old value for up to 24 hours before they see and respect the new one. That's precisely why the lowering has to happen before the switch — not on the day of.

If you're unsure how a given TTL translates to real-world cache behavior, run the numbers through a TTL calculator rather than guessing: https://www.matchdns.com/tools/ttl-calculator

After the migration settles, raise TTLs back to something sane (an hour or a few). Permanently low TTLs just increase query load everywhere for no benefit.

Step 3: Replicate the zone at the new provider — then diff it

Create the zone on the new provider and add every record from your inventory, with the TTLs you just lowered. If the provider supports zone file import, use it — then verify manually anyway, because importers routinely miss exotic records (SRV with unusual formatting, multiline TXT strings, wildcard/alpex aliases).

Pay attention to two record types where providers genuinely differ:

• Apex CNAMEs. The protocol doesn't allow a CNAME at the zone apex alongside other required records. Providers solve this differently — some offer an ALIAS-style flattened record, some don't support it at all. If your apex relies on one, confirm the new provider handles it the same way before you commit.
• Wildcard records. Make sure *.example.com came across, and that the provider's wildcard behavior (and interaction with existing records) matches what you had.

If your new provider offers a side-by-side comparison of the old zone against the new one, use it. Even if not, build your own diff table — name, type, value, TTL, old vs new. Mismatched values are the single most common cause of "weirdness" after a move.

Step 4: Test the new zone before it's live

You don't have to wait for delegation to test. Every DNS provider publishes its nameserver hostnames; query them directly with dig, bypassing caches entirely:

dig @ns1.new-provider.example www.example.com A +norecurse
dig @ns1.new-provider.example example.com MX +norecurse
dig @ns1.new-provider.example example.com TXT +norecurse

Compare each answer against what the old provider returns. They should be identical. This step catches the incomplete-zone problem while it's still free to fix — before any real user can hit it.

Step 5: Flip the NS records at your registrar

Now the actual cutover: at your registrar, replace the nameserver entries with the ones your new provider assigns. Three small things to get right:

• Replace, don't append. The delegation should point only at the new provider's nameservers. Leaving one old nameserver in the set means some resolvers keep consulting it.
• Exact hostnames, no typos. A typo here produces SERVFAIL-style failures across the board.
• Glue records, if your nameservers happen to be under the domain itself (rare with hosted DNS, but worth knowing about).

Delegation changes don't spread the way record changes do. Resolvers learn your nameservers from the parent (.com, .net, etc.) zone, whose NS TTL is set by the registry — commonly on the order of a day, and not under your control. Plan your timeline around that.

Step 6: Watch propagation instead of guessing

After the flip, different resolvers and regions will switch over at different times as caches expire. That's normal — what you're watching for is convergence: every region eventually returning identical answers served by the new nameservers.

Checking this by hand means querying public resolvers one at a time and hoping they're representative. A propagation checker that queries the same record from many vantage points turns guesswork into observation — this one checks A/AAAA/CNAME/MX/TXT/NS answers across regions side by side: https://www.matchdns.com/tools/dns-propagation

If one region keeps returning the old answer well past your lowered TTL, two usual suspects: that record's TTL was never actually lowered (old TTLs haunt you exactly as described in step 2), or an ISP resolver in that region ignores TTLs and caches aggressively. Both resolve with time; the second one you simply wait out.

Step 7: Keep the old zone alive through the tail

Here's the detail that saves you: after the delegation flips, most resolvers correctly start asking the new nameservers — but resolvers that cached the old delegation keep asking the old ones until their cached NS set expires. That tail can run a day or more.

If your old provider's zone still exists during that window, those stragglers get correct answers and nobody notices anything. If you cancelled the old plan the same afternoon, they get failures. Keep the old provider serving for at least as long as your longest original TTL — overlap is cheap; an outage is not.

The mistakes, ranked by how often they bite

1. Email breaks. MX or SPF/DKIM/DMARC records dropped or truncated in the move. Test mail delivery explicitly after the flip.
2. Apex alias behavior differs. Works on the old provider, unsupported or subtly different on the new one.
3. Wildcards missed. Everything you tested works; the untested random.example.com subdomain 404s.
4. CAA dropped. Fine for weeks, then certificate renewal fails out of nowhere.
5. TTLs never lowered. Everything else done right, but a rollback now takes a day instead of five minutes.

About rollback

If something is wrong after the flip, the first move is fixing records on the new provider. If the new zone is fundamentally broken, flipping NS back to the old provider also works — provided the old zone still exists and your TTLs are low. That's the quiet payoff of steps 2 and 7: a real rollback path that measures in minutes, not days.

Wrapping up

A DNS migration is boring when it's sequenced right: inventory → lower TTLs → replicate and diff → pre-test → flip → watch → overlap. Nothing in the list requires paid tooling, and the two most useful checks — TTL math and multi-region propagation — are exactly the kind of thing free online tools handle well.

If you're comparing providers mid-move, it's worth knowing that MatchDNS is an authoritative DNS hosting service (not a public resolver) that also ships a free toolset — including a TTL calculator, a multi-region propagation checker, and a side-by-side DNS migration comparator — all usable without an account, which is convenient precisely when you're moving between providers: https://www.matchdns.com/tools/dns-migration