DNS Management During Migration: Complete Guide | Dragnoc Blog

DNS is the invisible infrastructure that makes the internet work. When a visitor types your domain name into their browser, it is DNS that translates that human-readable name into the IP address of the server hosting your site. During a migration, DNS management is the critical bridge between your old server and your new one. Get it wrong, and your site goes dark. Get it right, and the transition is seamless for your visitors.

Yet DNS remains one of the most misunderstood aspects of web migrations. The concepts of propagation, TTL, record types, and caching create confusion that leads to avoidable downtime. Transfer guides you through DNS changes during migration, but understanding how DNS works will give you the confidence to manage any migration scenario.

Understand how DNS works

Think of DNS as the internet's phone book. When you type example.com into your browser, the following chain of lookups happens in milliseconds:

The critical concept here is caching. At every level of this chain, the result is cached for a duration specified by the TTL (Time To Live) value. When you change your DNS records during a migration, these cached values must expire before the change takes effect everywhere. This is what "DNS propagation" really means -- it is not the records "spreading" across the internet, but rather old cached values expiring at different rates across thousands of resolvers worldwide.

DNS record types explained

During a migration, you will interact with several types of DNS records. Understanding each one is essential to making the right changes at the right time.

Prepare DNS for migration

Proper DNS preparation starts days before the actual migration. Here is a systematic approach that minimizes risk and downtime.

Document your current DNS zone

Before changing anything, export or screenshot your entire DNS zone. Record every A, AAAA, CNAME, MX, TXT, and SRV record currently configured. This serves as your rollback plan -- if anything goes wrong, you can restore the exact original configuration in minutes.

• Log in to your DNS provider (registrar or DNS management service) and list all records
• Pay special attention to records you might not have created yourself: hosting providers and third-party services often add records automatically
• Note the current TTL values for each record -- you will need to restore them after migration
• Identify which records need to change (typically A and possibly AAAA) and which must stay unchanged (MX if email is separate, TXT for SPF/DKIM/DMARC)

Identify email vs. web hosting

One of the most dangerous DNS mistakes during migration is accidentally disrupting email delivery. Before you change any records, clearly identify where your email is hosted:

• Email on the same server as the website -- you need to update both A records (for the website) and MX records (for email) to point to the new server. Also update SPF and DKIM TXT records
• Email on a separate service (Gmail Workspace, Microsoft 365, dedicated email hosting) -- only change the A record for the website. Do NOT touch MX, SPF, or DKIM records. These must continue pointing to your email provider
• Email on the old hosting, website moving -- this is the trickiest scenario. You need to move email separately (using Sync) or set up email on the new server before switching DNS

Reduce TTL before migration

This is the single most important preparatory step for DNS during a migration, and it must be done 48 hours before the planned switch.

Why TTL matters

TTL (Time To Live) tells DNS resolvers how long to cache a record before checking for updates. A typical default TTL is 3600 seconds (1 hour) or even 86400 seconds (24 hours). If your A record has a 24-hour TTL and you change the IP address, some visitors will continue reaching the old server for up to 24 hours while cached values expire.

How to reduce TTL

At least 48 hours before migration day, change the TTL of your A record (and AAAA if applicable) to 300 seconds (5 minutes). The reason you must do this 48 hours in advance is that the old TTL value is currently cached by resolvers worldwide. If the old TTL was 24 hours, it can take up to 24 hours for all resolvers to pick up the new, lower TTL. Only then will the lower TTL actually be in effect.

• Log in to your DNS provider and change the TTL of the A record to 300
• If you have a CNAME for www, reduce its TTL as well
• Do NOT reduce TTL on MX records unless you are migrating email
• Do NOT reduce TTL on NS records -- nameserver TTL changes have their own complexities
• Wait a full 48 hours before proceeding with the migration

Switch DNS to the new server

Once your site is fully migrated and verified on the new server (using a hosts file override or temporary URL), it is time to update DNS.

The switch process

• Verify the new server is ready -- the site must be fully functional on the new server before you touch DNS. Test all pages, forms, and functionality via the direct IP or a temporary domain
• Update the A record -- change the IP address to your new server's IP. If you also have a www CNAME or A record, update it accordingly
• Update AAAA record if the new server has a different IPv6 address
• Generate SSL certificate -- if using Let's Encrypt, you need DNS to point to the new server before you can generate the certificate. Some hosts handle this automatically; others require manual action. During the brief gap, consider using a certificate from the old server or a temporary self-signed certificate
• Do NOT change other records unless specifically needed for the migration

After the switch

Once DNS propagation is complete (typically 5 to 30 minutes with a 300-second TTL), restore the TTL to a normal value. A TTL of 3600 (1 hour) is a good default -- it balances between fast updates when needed and reduced DNS query load. There is no benefit to keeping a 5-minute TTL permanently; it only increases DNS resolver traffic.

Verify DNS propagation

After updating your DNS records, you need to verify that the changes are propagating correctly across the global DNS infrastructure.

Online propagation tools

• whatsmydns.net -- checks DNS resolution from dozens of servers worldwide. Enter your domain and select the record type (A, MX, etc.) to see the current value at each location. The most widely used propagation checker
• dnschecker.org -- similar to whatsmydns, with a visual world map showing which servers have updated and which still return the old value
• MXToolbox -- comprehensive DNS diagnostic that checks all record types, identifies configuration errors, and verifies MX record health

Command-line verification

For more precise diagnostics, use command-line tools to query specific DNS resolvers:

• dig example.com A +short -- query your default resolver and show just the IP address
• dig @8.8.8.8 example.com A -- query Google's DNS directly to see what they resolve
• dig @1.1.1.1 example.com A -- query Cloudflare's DNS for a second opinion
• nslookup example.com -- the Windows-friendly equivalent for basic DNS lookups

Compare the returned IP address against your new server's IP. When all major resolvers return the new IP, propagation is essentially complete.

Post-propagation checklist