Migrating your DNS from one provider to another sounds risky. Your entire online presence, your website, your email, your APIs, depends on DNS resolving correctly. A mistake during migration can take everything offline. But with the right process, DNS migration can be done with zero downtime, and it's far less dangerous than it seems.
The key is understanding that DNS migration isn't a single switch you flip. It's a careful sequence where you prepare the new provider completely, verify it works, and only then redirect traffic, with the old provider standing by as a fallback throughout. Done correctly, users never notice anything changed.
This guide walks through the complete process: preparation, the actual migration, verification, and the common mistakes that cause the downtime you're trying to avoid.
Why Migrate DNS Providers?
Organizations move DNS providers for many reasons: better performance through a larger anycast network, lower costs, advanced features (traffic management, better APIs, DNSSEC support), consolidation of services, improved security and DDoS protection, or moving away from a provider that's being deprecated. Whatever the reason, the migration process is the same.
Understanding What Actually Changes
Before migrating, it's important to understand the two distinct things that can change:
1. The Authoritative DNS Provider (Your Records' Host)
This is where your DNS records (A, MX, TXT, etc.) are hosted and served. Moving this means recreating your records at the new provider and updating your domain's nameserver delegation to point to them.
2. The Nameserver Delegation (at the Registrar)
Your domain registrar holds the NS records that tell the world which nameservers are authoritative for your domain. Changing DNS providers means updating this delegation at the registrar to point to the new provider's nameservers.
The migration is essentially: replicate everything at the new provider, then change the delegation to point to it. The delegation change is the moment of cutover, and it's where careful timing matters.
Phase 1: Preparation (Before Touching Anything)
Step 1: Inventory Your Current DNS Records
You cannot migrate what you don't know about. Export or document every single DNS record at your current provider. This includes obvious records (A, AAAA, CNAME, MX) and easily forgotten ones (TXT records for SPF, DKIM, DMARC, domain verification; SRV records; CAA records; any subdomains).
Use the DNS lookup tool at dnsassistant.com/tools to query each record type and confirm your inventory is complete. Many providers also offer a zone file export that captures everything at once. Missing a record during migration is the most common cause of post-migration problems.
Step 2: Note Your Current TTL Values
Record the TTL for each record. You'll need these to plan timing, and you'll restore them after migration. Pay special attention to your NS record TTLs and your SOA settings.
Step 3: Lower TTLs in Advance
This is the single most important step for a zero-downtime migration. Several days before the migration, lower the TTLs on your records at the current provider to a short value (300 seconds or lower).
Why: when you make the cutover, resolvers that have cached your old records will keep serving them until the TTL expires. If your TTL is 86400 seconds (24 hours), some users could be pointed at the old provider for a full day after you switch. By lowering the TTL in advance, you ensure that when you cut over, the old cached entries expire within minutes.
Lower the TTL at least as far in advance as the current TTL value. If your records currently have a 24-hour TTL, lower them to 300 seconds at least 24 hours (ideally 48) before the migration, so the old high-TTL entries have fully expired from caches by migration time. We cover this in depth in our TTL best practices guide.
Phase 2: Set Up the New Provider
Step 4: Recreate All Records at the New Provider
At the new DNS provider, create every record from your inventory exactly as it exists at the old provider. Match record types, names, values, and TTLs (using the lowered TTLs). Take your time and double-check each one against your inventory. This is where completeness matters most.
Step 5: Verify Records at the New Provider Directly
Before changing any delegation, verify that the new provider is serving your records correctly. You can query the new provider's nameservers directly to confirm they return the right answers, even though the delegation hasn't changed yet. Most providers show you the nameserver hostnames assigned to your zone. Confirm each record resolves correctly when querying those nameservers specifically.
This step is critical: you're confirming the new provider works before you send any real traffic to it. If something is wrong, you find out now, with zero impact, rather than after cutover.
Step 6: Configure DNSSEC (If Used)
If your domain uses DNSSEC, this requires special care. DNSSEC migration involves coordinating the signing keys and DS records between providers. The safest approach is often to temporarily disable DNSSEC before migration (remove the DS record at the registrar, wait for it to expire), complete the migration, then re-enable DNSSEC at the new provider. Disabling DNSSEC briefly reduces security during the migration window but prevents the chain-of-trust breakage that causes SERVFAIL outages. Plan this carefully and consult both providers' DNSSEC migration documentation.
Phase 3: The Cutover
Step 7: Update Nameserver Delegation at the Registrar
This is the actual migration moment. At your domain registrar, update the nameserver (NS) records to point to the new provider's nameservers instead of the old provider's.
Important: do not delete anything at the old provider yet. Both providers should be serving identical records during the transition. As the delegation change propagates, some resolvers will query the old nameservers and some the new ones. Because both have identical records, users get correct answers regardless of which they hit.
Step 8: Understand the Propagation Window
The nameserver delegation change is governed by the TTL of the NS records at the TLD level, which is set by the registry (typically 24-48 hours) and is outside your control. During this window, resolution is split between old and new providers. This is why keeping both providers active with identical records is essential. There's no downtime because both answer correctly.
Phase 4: Verification and Cleanup
Step 9: Verify the Migration
After the delegation change, verify that your domain resolves correctly through the new provider. Use the DNS lookup tool to confirm your records return the expected values and that your NS records now show the new provider's nameservers. Run a Free Domain Risk Report to confirm your full configuration, including email authentication and TLS, is intact.
Step 10: Wait Before Decommissioning the Old Provider
Do not cancel or delete your zone at the old provider immediately. Wait at least 48-72 hours after the delegation change (longer if the TLD NS TTL is high) to ensure all resolvers worldwide have picked up the new delegation. Deleting the old provider's records while some resolvers are still querying them would cause resolution failures for those users.
Step 11: Restore Normal TTLs
Once the migration is confirmed stable, raise the TTLs at the new provider back to their normal operating values (3600 seconds for most records, 86400 for NS records). This reduces query load and improves caching efficiency now that you're no longer in a rapid-change window.
Step 12: Re-enable DNSSEC (If Applicable)
If you disabled DNSSEC for the migration, re-enable it at the new provider and add the new DS record at your registrar. Verify the chain of trust validates correctly.
Migration Checklist
| Phase | Step | Timing |
|---|---|---|
| Prep | Inventory all records | 1 week before |
| Prep | Lower TTLs to 300s | 48 hours before |
| Setup | Recreate records at new provider | Day before |
| Setup | Verify new provider directly | Day before |
| Cutover | Update NS at registrar | Migration time |
| Verify | Confirm resolution via new provider | After cutover |
| Cleanup | Decommission old provider | 48-72 hours after |
| Cleanup | Restore normal TTLs | After stable |
Common Migration Mistakes
Forgetting Records
The most common mistake. An overlooked TXT record breaks email authentication. A missed subdomain breaks a service. A forgotten CAA record blocks certificate renewal. Thorough inventory and verification prevent this. Cross-check the new provider against your documented inventory before and after cutover.
Not Lowering TTLs in Advance
If you skip the TTL-lowering step, the cutover still works, but resolvers serve cached old records for up to the original TTL duration. With a 24-hour TTL, you get a 24-hour window where some users hit the old provider. If you've already started decommissioning the old provider, those users experience an outage.
Deleting the Old Provider Too Soon
Decommissioning the old provider before the delegation change has fully propagated causes resolution failures for resolvers still using the old nameservers. Always wait 48-72 hours minimum.
Mishandling DNSSEC
DNSSEC migration done incorrectly causes SERVFAIL outages, the same failure mode as the .de TLD outage. If your domain uses DNSSEC, handle it deliberately: disable before migration, re-enable after, and verify the chain at each step.
Not Monitoring During and After
Migration is exactly when you want maximum visibility. If something goes wrong, you want to know immediately, not when users complain.
How DNS Assistant Helps With Migration
DNS Assistant is valuable throughout the migration process:
- Pre-migration inventory: Before migrating, DNS Assistant gives you a clear record of your current DNS configuration, so you know exactly what needs to be replicated at the new provider.
- Verification: After cutover, DNS Assistant confirms your records resolve correctly and that nothing was missed in the migration.
- Change detection during migration: DNS Assistant tracks every record change, giving you a clear log of what changed and when, which is invaluable for troubleshooting.
- NS delegation monitoring: DNS Assistant confirms your nameserver delegation updated correctly and that the new nameservers respond authoritatively.
- DNSSEC validation: If you use DNSSEC, DNS Assistant validates the chain of trust before, during, and after migration, catching the chain-breakage that causes outages.
- Real-time alerting: If anything goes wrong during or after migration, you're notified immediately via email, Slack, Microsoft Teams, webhooks, or SMS.
Having monitoring in place before you migrate means you have a baseline to compare against and immediate visibility into any issues the migration introduces.
Get Started
Before your next DNS migration, establish a baseline. Run a Free Domain Risk Report to document your current configuration, and use the DNS lookup tool to inventory your records.
For continuous monitoring that gives you confidence before, during, and after migration, sign up at dnsassistant.com.
Top comments (0)