← Back to Learning Hub

Setup Guides • Intermediate • 9 min read

The DNS Migration Checklist: Lookup, Trace, Propagation

Moving DNS providers without downtime is a process, not a prayer. A before/during/after checklist using lookup, nameserver trace and propagation.

Changing DNS providers is one of the few operations that can take an entire online presence down in one move, website, email, everything. The good news: done in order, it's routine and safe. Here's the checklist, mapped to the three tools that de-risk each phase.

Before: inventory everything (Lookup)

You cannot recreate what you haven't recorded. At the old provider, run a DNS lookup and capture every record: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verification tokens), NS, SOA, and any SRV/CAA. Two things people forget and regret:

  • TXT records, a missing SPF or domain-verification token silently breaks mail and third-party services.
  • TTL values, note them; you'll lower them next.

Lower your TTLs (e.g. to 300s) at the old provider a day or two before the move so resolvers pick up the change quickly when you cut over.

During: recreate, then re-delegate (Trace)

  1. Create every record at the new provider first, while the old one is still authoritative. Nothing is live yet, so there's no risk.
  2. Only then change the nameservers at your registrar to the new provider.
  3. Immediately run a nameserver trace to confirm the parent (registrar/TLD) now delegates to the new nameservers and that parent and child NS agree. This is the single most important check, if the delegation still points at the old provider, nothing you did at the new one is visible yet.

Watch for missing glue records if your nameservers live inside the domain, and for a parent/child mismatch that means the delegation hasn't fully switched.

After: verify convergence (Propagation)

Delegation switching doesn't mean every resolver sees it instantly. Run a DNS propagation check on your key records (apex A, www, MX) and watch resolvers converge on the new answers. Keep the old zone live and unchanged until propagation is broadly complete, usually within a TTL window, occasionally up to 48 hours for stubborn caches.

Then confirm the dependent services actually work: load the site, check the SSL certificate, and send a test email.

Rollback safety

Because you kept the old zone intact and identical, rollback is simply pointing the registrar's nameservers back. That's why "recreate first, re-delegate second, decommission last" matters, never delete the old zone until the new one is proven.

FAQ

How far ahead should I lower TTLs?

At least one old-TTL window before the move, if your records were at 3600s, lower them 1–2 hours ahead; if 86400s, a day or two ahead.

I switched nameservers but the site didn't change. Why?

Either the registrar delegation didn't fully update, or resolvers are still caching. Run a nameserver trace to confirm the parent points at the new provider, then a propagation check for caches.

When is it safe to delete the old zone?

Only after propagation is broadly complete and every dependent service (web, mail, TLS) is verified on the new provider. There's no rush, leave it a few extra days.

Related guides

Troubleshooting box

If results look inconsistent, compare authoritative nameservers first, then recursive resolvers by region. Capture snapshots every 10 minutes for deterministic incident timelines.

Try VallaDNS free →