DNS Migration Checklist: Moving Your Domain Without Downtime

Moving a domain's DNS to a new provider is routine, and it can be done with no visible downtime at all. Most failed migrations are not caused by anything technically difficult; they happen because a record was forgotten, a setting was not checked, or the old provider was shut down too early. This DNS migration checklist breaks the job into phases with clear exit criteria, so you can tick your way through it and know when it is safe to move on.

Phase 1: Discovery

Goal: know exactly what you have and who depends on it.

☐ Identify the current registrar and DNS provider. A WHOIS lookup shows both the registrar and the current name servers.
☐ Export the full zone from the current provider. A BIND-format zone file is ideal.
☐ If no export exists, copy every record manually, including TTLs and MX priorities.
☐ List subdomains that are easy to forget: _dmarc, *._domainkey, autodiscover, _sip._tls and other SRV records, verification TXT records, and any wildcard records.
☐ Note special features: ALIAS or flattened CNAMEs at the apex, geo or weighted routing, health checks, DNSSEC, and dynamic DNS clients updating records through the old provider's API.
☐ Find automation that writes to DNS: certificate tools using DNS-01 validation, infrastructure-as-code, and scripts that need new API credentials.
☐ Identify the owners of each service (website, email, CRM, phone system) so you can ask them to test.

Exit criterion: a complete, written record inventory that has been compared against live lookups, not just against the control panel.

Phase 2: Preparation

☐ Lower the TTLs on the NS records inside your zone and on critical records to 300 seconds, at least one full old-TTL period before cutover. This mainly helps if you need to change individual records quickly during the migration.
☐ Check DNSSEC. If a DS record exists at the registrar, plan either a coordinated key rollover between providers or removal of the DS record before the move, waiting for its TTL to expire. Moving name servers with a mismatched DS record makes the domain fail for validating resolvers.
☐ Confirm you can log in to the registrar, with two-factor authentication, and that the domain is not about to expire.
☐ Pick a cutover window with people available afterwards, not the last hour before a weekend.
☐ Write down the rollback plan: the old name servers, ready to paste back in.

Phase 3: Build the new zone

☐ Create the zone at the new provider and import or recreate every record.
☐ Replace any apex ALIAS or flattened records with the new provider's equivalent, or with A/AAAA records.
☐ Check long TXT values (DKIM keys especially) were not truncated or split incorrectly.
☐ Check MX priorities and that MX targets are host names, not IP addresses.
☐ Recreate CAA records so certificate renewals keep working.
☐ Set sensible TTLs for normal operation after the migration, such as 3600.

Phase 4: Verify before cutover

The new name servers already answer queries for your zone even though nobody is sent to them yet. Compare them, record by record, with the old ones. A short script makes this repeatable:

for name in example.com www.example.com _dmarc.example.com; do
  for type in A AAAA MX TXT CNAME CAA; do
    old=$(dig @ns1.oldprovider.net $name $type +short | sort)
    new=$(dig @ns1.newprovider.net $name $type +short | sort)
    [ "$old" != "$new" ] && echo "DIFF $name $type"
  done
done

Extend the list of names with every host from your inventory. On Windows, Resolve-DnsName -Server can do the same job in PowerShell.

☐ Every name and type returns identical answers on old and new name servers.
☐ The SOA and NS records in the new zone list the new provider's name servers.

Exit criterion: no differences, or only differences you have deliberately chosen.

Phase 5: Cutover

☐ At the registrar, replace all old name servers with the new provider's set. Do not leave a mix.
☐ If moving DNSSEC with a planned rollover, add the new DS record as your plan requires.
☐ Freeze DNS edits on both providers during the transition, or make any necessary edit on both.

The delegation at the registry has its own TTL, commonly up to 48 hours, which you cannot shorten. That is why both providers must serve identical data during this period: whichever one a resolver asks, the answer is right.

Phase 6: Monitor

☐ Watch NS records switch over around the world with the DNS propagation checker.
☐ Load the website and key subdomains over HTTPS from outside your network.
☐ Send email to and from the domain with an external account, and confirm SPF, DKIM and DMARC still pass using the SPF, DKIM and DMARC checker.
☐ Confirm automated certificate renewals and any dynamic DNS updates now work against the new provider.
☐ Ask the owners of each dependent service to confirm everything works.

Phase 7: Decommission the old provider

☐ Wait at least several days after cutover, and longer than the longest TTL involved, before deleting anything at the old provider.
☐ If DNSSEC was removed for the move, enable it at the new provider and publish the new DS record at the registrar.
☐ Restore normal TTLs.
☐ Revoke old API keys and remove any remaining integrations with the old provider.
☐ Delete the old zone and, if relevant, close the account.
☐ Update your documentation with the new provider, login owner and support contacts.

When migration is more than DNS

This checklist covers moving DNS hosting only. If you are also moving the website, email or the domain registration itself, do those as separate, planned changes rather than all at once. Changing one thing at a time makes it obvious what caused any problem and keeps rollback simple.

Key takeaways

Inventory everything, including easily forgotten TXT, SRV and DKIM records, and compare it against live DNS.
Query the new name servers directly and diff them against the old ones before switching.
Handle DNSSEC before the name server change, never after.
Keep both providers serving identical data until the delegation change has fully propagated.

DNS & Domains articles