How to migrate DNS without downtime

Why DNS migrations break

Almost every DNS outage during a move comes from one of four mistakes:

1. Records missing at the new provider. Public lookups can't list a zone, so records under unusual names (DKIM selectors, verification tokens, internal hosts) get forgotten when a zone is rebuilt by hand.
2. Provider features that don't exist elsewhere: proxied records, apex aliases, flattened CNAMEs, weighted or geo routing, URL redirects.
3. DNSSEC left pointing at the old provider's keys. Validating resolvers then return SERVFAIL for the whole domain.
4. Turning off the old provider too early. Resolvers can keep using the old nameservers for as long as the parent zone's NS TTL, which is 48 hours for .com.

1. Export the complete zone

Get the zone from the provider's API or a zone file export, not from public lookups. Our migration checker shows what's publicly visible, which is useful for spotting provider features, but only an export contains every record.

Look for records that need translation: apex CNAMEs and aliases, proxied records, routing policies, and provider-specific redirect records. The provider guides list what changes for each pair.

2. Recreate the zone and compare answers

Create the zone at the new provider and load the records. Then ask the new provider's nameservers directly, before anything is delegated to them:

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

Compare every name and type against the old provider's authoritative answers. DNSMigrator does this automatically for every record set after it applies a migration.

3. Lower TTLs ahead of time

Lower the TTL of records you might need to change quickly to 300 seconds, then wait at least one old TTL before the switch. You can't change the TTL on the NS delegation at the registry, which is why the old provider must keep serving after the switch. More in lowering TTLs before a migration.

4. Take DNSSEC out of the path

If the domain is signed, remove the DS record at the registrar first and wait for it to expire from caches (the DS TTL for .com is one day). Only then change nameservers. Re-enable DNSSEC at the new provider once it's serving. The full order is in migrating with DNSSEC enabled.

5. Switch nameservers at the registrar

Replace the nameservers with the new provider's set. The registry usually publishes the change within minutes, but resolvers that cached the old delegation keep using it until it expires. Both providers answer identically in the meantime, so visitors see no difference.

6. Watch propagation and verify

Check what public resolvers return with the propagation checker. Send a test email, load the site over HTTPS, and check any service that relies on TXT verification records.

7. Keep the old zone for a week

Don't delete the old zone or cancel the old provider for at least seven days. Avoid record changes during that window, or make them at both providers. If anything looks wrong, pointing the nameservers back is an instant, complete rollback.

Checklist

• Full zone exported from the API or a zone file
• Provider-specific records translated or replaced
• New nameservers return the same answers as the old ones
• TTLs lowered at least one old TTL before the switch
• DS record removed and expired, if DNSSEC was on
• Nameservers changed at the registrar
• Propagation checked; email and HTTPS tested
• Old zone kept unchanged for 7 days
• DNSSEC re-enabled at the new provider and DS published