How to Migrate DNS to a New Provider Without Downtime

Changing DNS providers, whether you're switching hosts, adding Cloudflare, or moving DNS management to a different service, doesn't have to cause downtime. The process is straightforward if done in the right order. Done wrong, it can cause outages that last hours. This guide covers the full zero-downtime workflow, step by step.

Why DNS Migrations Cause Downtime

Downtime during a DNS migration usually happens for one of three reasons: records weren't fully recreated at the new provider before switching, TTLs were too high so propagation took hours, or DNSSEC was misconfigured causing SERVFAIL responses. Understanding the cause makes avoiding it straightforward.

The core principle: your new DNS zone must be an exact working copy of your old zone before you change the nameservers. Any record missing from the new zone will stop working the moment the nameserver change propagates.

Step 1: Export and Document All Existing DNS Records

Before changing anything, get a complete picture of your current DNS configuration. Log in to your current DNS provider and export the zone file if the option is available (usually labelled "Export Zone" or "Download Zone File"). If not, manually note every record.

Pay particular attention to:

• All A and AAAA records, including any subdomains.
• MX records and their exact priority values.
• All TXT records: SPF, DKIM selectors, DMARC, domain verification tokens from Google Search Console, and third-party services.
• CNAME records for third-party integrations (Shopify, HubSpot, Zendesk, Stripe, Vercel, etc.).
• SRV records if you have any (VoIP, Microsoft Teams federation, etc.).
• The TTL value on each record.

Keep this as a reference document. You'll need it in Step 3 and as a rollback reference if something goes wrong.

Step 2: Lower TTLs at Your Current Provider

Reduce the TTL on all records to 300 seconds (5 minutes) at your current DNS provider. This minimises the propagation window when you make the cutover: resolvers will have discarded their cached copies within 5 minutes rather than hours.

After lowering the TTL, you must wait for the original (higher) TTL to expire before the cutover. If your records had a TTL of 86400 (24 hours), you need to wait 24 hours after lowering the TTL before making the switch. Only then will all resolvers be respecting the new 5-minute TTL.

This waiting period is critical and commonly skipped, skipping it means many resolvers will still be caching the old records for hours after the nameserver change.

Step 3: Recreate All Records at the New Provider

Log in to your new DNS provider and recreate every record from Step 1. Use identical values: same IP addresses, same hostnames, same MX priority numbers, same TXT content. Do not change any values at this stage, the goal is a perfect copy of your current working DNS.

Check each record type methodically:

• A/AAAA records: all hostnames and their IPs, including bare domain, www, and any subdomains.
• MX records: all mail exchange records with correct priorities. A wrong MX priority can cause email to fail or be routed to the wrong server.
• TXT records: SPF must be complete and identical. DKIM records must have the exact key values, even a single character difference breaks the signature. DMARC policy record, and all verification tokens.
• CNAME records: all subdomain aliases for third-party services.

Email records deserve extra care. Email failures after a DNS migration are almost always caused by incomplete TXT or MX records at the new provider.

Step 4: Test the New Zone Before Cutting Over

Your new DNS provider will give you the nameservers you'll be switching to. Before touching anything at the registrar, test those nameservers directly using dig. This confirms the zone is correctly configured at the source without affecting any live traffic:

# Test A record
dig @new-ns1.provider.com yourdomain.com A +short

# Test MX records
dig @new-ns1.provider.com yourdomain.com MX +short

# Test SPF TXT record
dig @new-ns1.provider.com yourdomain.com TXT +short

# Test DMARC
dig @new-ns1.provider.com _dmarc.yourdomain.com TXT +short

Verify every response matches what you exported in Step 1. If anything is missing or wrong, fix it before proceeding. This step costs you nothing and prevents a production outage.

Step 5: Handle DNSSEC If Enabled

If DNSSEC is currently enabled for your domain, you must handle it carefully. Changing nameservers with a stale DS record at your registrar will cause DNSSEC validation failures, making your domain unresolvable for all DNSSEC-validating resolvers (including Google 8.8.8.8 and Cloudflare 1.1.1.1).

The safe sequence if DNSSEC is enabled:

1. Remove the DS record from your registrar. Wait for that removal to propagate (a few hours).
2. Change the nameservers to the new provider.
3. Enable DNSSEC at the new provider and get the new DS record values.
4. Add the new DS record at your registrar.

Step 6: Change Nameservers at the Registrar

Log in to your domain registrar and update the nameservers to the ones provided by your new DNS provider. Save the change. This is the actual cutover moment.

Because you lowered TTLs in Step 2 and waited, most resolvers will pick up the nameserver change within 5 to 15 minutes. The window during which some users hit the old provider and some hit the new one will be short.

Step 7: Monitor and Clean Up

Use our DNS Propagation Checker to check propagation progress. Within 1 to 4 hours, the vast majority of resolvers globally should be using the new nameservers. Monitor your site, check email delivery, and verify any third-party integrations are still working.

Once confirmed stable:

• Raise TTLs back to 3600 or higher at the new provider.
• Keep the old DNS provider account active for 48 to 72 hours as a safety net before cancelling.
• Update any documentation or runbooks that reference the old DNS provider.