How long before a DNS migration should I lower the TTL?

24 to 48 hours beforehand, down to something short like 300 seconds. This gives the old, likely much longer TTL time to fully expire everywhere before you cut over, so resolvers pick up the new records quickly instead of serving stale ones.

What DNS records are most commonly forgotten during a migration?

MX and TXT records — a missed MX record doesn't break anything immediately since mail keeps flowing on cached answers, so the problem can take days to surface. CAA records are the other common miss, and their absence can cause certificate renewal to fail with no obvious link to the migration.

What happens if DNSSEC is enabled and I don't update the DS record?

Validating resolvers will refuse to resolve the domain at all, rather than just serving old data — DNSSEC turns a caching problem into an outage if the DS record at the registrar isn't coordinated with the new provider's keys before cutover.

How to Migrate DNS Providers Without Downtime

A DNS migration goes wrong for one of two reasons: a record was never copied over, or the cutover happened before caches everywhere had a chance to catch up. Both are avoidable with the same amount of care every time.

Before You Start: Export Everything

Get a complete, literal copy of every record at the current provider — an export file if one exists, screenshots if it doesn't. Pay particular attention to provider-specific record types like ALIAS or ANAME at the apex domain, since not every new provider implements them the same way, or at all.

Lower TTL in Advance

24 to 48 hours before the migration, lower the TTL on every record you're about to change to something short, like 300 seconds. This makes resolvers drop their cached answers quickly once you cut over, instead of serving the old records for however long the previous, likely much higher, TTL had left to run.

Recreate Every Record at the New Provider First

Build the full zone at the new provider while the domain's nameservers still point at the old one. Many providers let you query their nameservers directly, so you can confirm every record resolves correctly before anything is live.

The Actual Cutover

Change the nameservers at the domain's registrar to the new provider's. This is the one step that can't be tested in advance — from this point, which records the world sees depends entirely on which resolvers have already picked up the new nameservers.

Confirm Before Declaring It Done

Check propagation across many resolvers worldwide rather than just your own connection, since your own ISP's resolver having the new records tells you nothing about anyone else's.

After It's Stable

Once propagation looks complete and nothing has broken for a day or two, raise the TTLs back to a normal value — a permanently short TTL means permanently more DNS queries for no ongoing benefit.

What Gets Forgotten

MX or TXT records — email keeps working on cached answers for a while after a migration, so a missed MX record can take days to surface as a real problem
CAA records restricting which certificate authorities may issue for the domain — an omitted CAA record can make a routine certificate renewal fail with no obvious connection to the DNS migration that caused it
DNSSEC — if it's enabled, the DS record at the registrar has to be coordinated with the new provider's keys, or the domain can become unreachable for validating resolvers rather than just serving stale data

Check Propagation Before and After Cutover

Check DNS propagation →Next: DNS pitfalls when moving to Cloudflare →

Try it on your domain

See the theory in practice — run a DNS Propagation Checker for your own domain.