DNS10 min read

Domain Migration Guide: Move DNS With Zero Downtime

Migrating a domain involves careful planning of DNS record exports, TTL reduction, server configuration, and staged cutover. This guide covers the complete process for zero-downtime migrations.

Domain migrations are high-risk operations — a mistake can take your website and email offline for hours. But with proper planning, you can migrate a domain to a new hosting provider, DNS provider, or registrar with zero downtime. This guide covers the complete migration process with a step-by-step checklist.

Types of Domain Migrations

"Domain migration" can mean different things depending on what you are moving:

Migration TypeWhat ChangesRisk Level
Web hosting migrationA record points to new serverLow (TTL-based)
DNS provider migrationNameservers change to new DNS hostMedium (requires careful record export)
Domain registrar transferRegistrar changes; nameservers may changeMedium (7-day lock period)
Full migration (all of the above)Registrar + DNS + hosting all changeHigh (stage carefully)

Pre-Migration Checklist

Complete all of these before touching any settings:

  • Export all DNS records from the current provider (zone file backup).
  • Document the current A records with their IPs.
  • Document all MX records and their priorities.
  • Export TXT records (SPF, DKIM selectors and values, DMARC, domain verifications).
  • Note all CNAME records and their targets.
  • Check the SSL certificate setup on the new server before cutover.
  • Test the new server works correctly before updating DNS.
  • Set up email authentication on the new server if email is hosted there.
  • Identify the lowest TTL on any existing record.

Phase 1: Prepare the New Environment

Set Up the New Web Server

Deploy and configure the new server completely before changing any DNS. Test that it serves your website correctly using a hosts file override:

bash
# Temporarily override DNS to test the new server # Add to /etc/hosts (Linux/macOS) or C:WindowsSystem32driversetchosts (Windows): 203.0.113.1 example.com 203.0.113.1 www.example.com # Visit example.com in your browser — you should see the new server # Remove these entries after testing

Install SSL on the New Server

If using Let's Encrypt, you cannot install the certificate until DNS points to the new server (HTTP challenge). Use an alternative approach:

  • Use DNS challenge instead of HTTP challenge: certbot --preferred-challenges dns
  • Or transfer the existing certificate files temporarily.
  • Or use a different CA that allows pre-issuance.

Configure Email on the New Server (if applicable)

If email is hosted on the new server, configure the mail server, DKIM signing, and test with test emails before cutover.

Phase 2: Reduce TTLs

At your current DNS provider, reduce TTLs on all records you plan to change to 300 seconds (5 minutes):

text
# Before (typical values): example.com. 3600 IN A 93.184.216.34 (old IP) www.example.com. 3600 IN A 93.184.216.34 # After reducing TTL: example.com. 300 IN A 93.184.216.34 (still old IP — do NOT change yet) www.example.com. 300 IN A 93.184.216.34

Wait at least as long as the old TTL (e.g., 3600 seconds = 1 hour) before proceeding. This ensures all resolvers have refreshed their cache with the new TTL.

The TTL waiting period is criticalAfter reducing TTLs, you must wait at least one full old TTL period before changing the actual record values. This ensures the old (long) TTL has expired everywhere. Skipping this step means some resolvers will cache the old server IP for hours after you switch.

Phase 3: Update DNS Records

After the TTL wait period, update A records to point to the new server:

text
# Update A record to new server IP example.com. 300 IN A 203.0.113.1 # New IP www.example.com. 300 IN A 203.0.113.1 # New IP

With a 5-minute TTL, the switch will propagate to most resolvers within minutes. Monitor traffic on both the old and new server to see when traffic shifts.

Phase 4: Migrate DNS Provider (if applicable)

If you are also changing DNS providers:

  1. Set up the zone at the new DNS provider with all records already pointing to the new server.
  2. Reduce NS record TTL at the current provider to 300 seconds (this may not be possible at all registrars).
  3. Update nameservers at the registrar to the new provider's nameservers.
  4. Monitor NS propagation using the DNS Propagation Checker.

Phase 5: Verify Everything Is Working

After cutover, systematically verify all services:

bash
# Verify A record points to new server dig example.com A +short # Should return: 203.0.113.1 # Verify HTTPS works curl -I https://example.com # Verify email is working dig example.com MX +short # Check SSL certificate openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates # Verify SPF and DMARC dig example.com TXT +short | grep spf dig _dmarc.example.com TXT +short

Also test manually: visit the website, send a test email, verify any subdomains and APIs.

Phase 6: Restore TTLs

Once you have confirmed everything is working correctly on the new server:

text
# Restore normal TTL values example.com. 3600 IN A 203.0.113.1 www.example.com. 3600 IN A 203.0.113.1

Higher TTLs improve performance and reduce DNS query load. Restore them to 3600 (1 hour) or higher once the migration is confirmed stable.

Registrar Transfer vs DNS Migration

Transferring the domain itself (moving to a different registrar) is separate from changing DNS. Registrar transfers:

  • Require the domain to be unlocked at the current registrar.
  • Require an EPP/auth code from the current registrar.
  • Take 5–7 days to complete due to ICANN rules.
  • Should be done separately from DNS migrations to reduce complexity.
  • Do not require DNS to change — you can transfer the registrar while keeping the same DNS provider.

Frequently Asked Questions

Can I migrate a domain without any downtime?

Yes — with proper TTL management. By reducing TTLs before the migration and ensuring the new server is ready before switching DNS, you can achieve a near-seamless transition where visitors are automatically directed to the new server within minutes.

What if traffic stops after I update the A record?

Check that the DNS change has propagated using dig example.com A +short. If it returns the new IP but the site doesn't load, the problem is on the new server (configuration, firewall, SSL). If it still returns the old IP, the change hasn't propagated yet — wait and check again.

Should I cancel my old hosting immediately after migration?

No. Keep the old server running for at least 48–72 hours after the DNS switch. Some resolvers may still send traffic to the old IP due to caching. Shut down the old server only after you confirm no significant traffic is arriving there.

Related Articles