DNS Checklist for Website Migrations

Website migrations are one of the most common causes of self-inflicted DNS outages. You spend weeks preparing the new server, testing the application, and coordinating with your team, then at the critical moment something goes wrong with DNS and your site vanishes, your email stops delivering, or half your users land on the old server while the other half hit the new one. This checklist exists so that does not happen to you. It covers every DNS record type you need to audit, the exact sequence of changes to make, how to lower and restore TTLs correctly, and how to verify everything is working before you call the migration complete.

Before You Touch Anything: The Pre-Migration Audit

The single biggest mistake engineers make is treating DNS as an afterthought. DNS changes need to be planned at least 48 hours before cutover, and in some cases a full week ahead. Start by exporting a complete snapshot of your current DNS zone.

Export Your Current Zone File

Log into your DNS provider and export the full zone file, or manually record every record. You want this as a reference baseline and as a rollback document. If your registrar does not offer export, use dig to pull the records manually:

Save this output to a plain text file dated with today's timestamp. This is your rollback reference if anything goes sideways.

Record Every Record Type, Not Just A Records

Most engineers remember to update the A record pointing to the new server IP. They forget everything else. Here is the full list you must audit for every migration:

• A records — IPv4 address for the root domain and all subdomains (www, staging, api, mail, ftp, etc.)
• AAAA records — IPv6 equivalents; often overlooked and can cause connectivity issues for IPv6-preferring clients
• CNAME records — aliases that may point to CDN endpoints, third-party services, or subdomains that need updating
• MX records — mail exchanger records; these almost never need to change during a server migration, but confirm they are intact
• TXT records — SPF, DKIM, DMARC, Google Search Console verification, domain ownership tokens; easy to accidentally delete
• NS records — if you are also migrating DNS providers, these change at the registrar level, not inside the zone
• CAA records — Certificate Authority Authorization; if your new host uses a different CA (e.g., switching from DigiCert to Let's Encrypt), update or remove CAA restrictions
• SRV records — relevant for VoIP, Microsoft 365 autodiscover, gaming servers
• PTR records — reverse DNS for the new server IP; request this from your new hosting provider, not your DNS registrar

Step 1: Lower Your TTLs Well in Advance

TTL (Time to Live) controls how long resolvers cache your DNS records. If your A record TTL is 86400 (24 hours) and you change the IP at cutover time, some users will keep hitting the old server for up to 24 hours. You cannot shortcut this after the fact.

At least 48 hours before cutover, lower the TTL on every record you plan to change to 300 seconds (5 minutes). This is the operational sweet spot — short enough to allow fast rollback, long enough not to hammer authoritative nameservers with excessive queries.

After the TTL reduction, wait the full duration of the old TTL before proceeding. If the original TTL was 86400, you must wait 24 hours for all cached copies to expire before your new 300-second TTL is universally respected. Skipping this wait is what causes prolonged, inconsistent propagation during migrations.

Step 2: Prepare the New Server Before DNS Cutover

DNS cutover should be the last step, not the first. Before you change a single DNS record, your new server must be fully ready:

1. Application deployed and tested using the server's direct IP or a temporary hostname
2. SSL/TLS certificate installed and valid — verify with:
   openssl s_client -connect 203.0.113.50:443 -servername yourdomain.com
3. Web server configured to respond to the production domain name as a virtual host
4. Database connections, environment variables, and config files updated for the new environment
5. Any CDN or load balancer origin settings updated to point to the new backend
6. Redirects verified (especially HTTP to HTTPS and non-www to www)

Testing via IP address or a hosts file override before DNS cutover is the most reliable way to catch application issues that would otherwise surface during the live migration window.

Step 3: Execute the DNS Cutover in the Right Order

Order matters. Here is the sequence to follow at cutover time:

1. Update A records for subdomains first — api, staging, admin, ftp, etc. These have lower traffic impact and let you verify the new server responds before you flip the main domain.
2. Update the www CNAME or A record — most traffic often arrives via www, so this is your high-impact change. Confirm it resolves correctly before the next step.
3. Update the root/apex A record — the bare domain (yourdomain.com) gets the new IP last. Many DNS providers handle apex records differently (ALIAS or ANAME records for CDN setups), so verify your provider supports what the new host requires.
4. Do not touch MX records unless email is also moving — email MX records should be changed in a separate, planned maintenance window if mail is migrating. Mixing server and mail migrations in the same window doubles your risk surface.
5. Update AAAA records if you have IPv6 configured on the new server. If the new server does not have IPv6, remove AAAA records rather than leaving them pointing to the old server.

Step 4: Verify Propagation Across Multiple Resolvers

Your local DNS resolver is not a reliable test. It may have cached the old record or it may be showing you the new one before global propagation is complete. Use authoritative queries and independent resolver checks.

Use the DNS Lookup tool to quickly check your A, MX, and TXT records from multiple geographic vantage points without running manual dig commands for each resolver.

Step 5: Verify Email is Not Broken

Even if you did not touch MX records, email deliverability can break during migrations if SPF records are not updated to include the new server's IP. If the new server sends any transactional or application email using the domain, its IP must be authorized in SPF.

Also confirm that DKIM keys are configured on the new mail server if you are migrating mail. A DKIM TXT record in DNS that points to keys not present on the new server will cause DKIM failures and increase the likelihood of your email landing in spam.

Step 6: Handle CDN and Third-Party DNS Considerations

If you are using Cloudflare, AWS CloudFront, Fastly, or another CDN, DNS cutover for a CDN migration is handled differently from a direct-IP migration. The DNS record often points to a CDN hostname rather than a bare IP, and the CDN's origin setting is what changes.

• Cloudflare: Update the origin IP in the Cloudflare dashboard under your domain's DNS settings. The public-facing DNS record (which points to Cloudflare's anycast IPs) does not change — only the origin the CDN proxies to changes.
• AWS Route 53 with CloudFront: Update the CloudFront distribution's origin to the new server. The Route 53 alias record pointing to the CloudFront distribution hostname stays the same.
• Direct DNS change to a new CDN: Change the CNAME (or ALIAS at the apex) from the old CDN hostname to the new one, and ensure the new CDN distribution has the domain configured as an alternate domain name before DNS cutover.

Step 7: Keep the Old Server Alive During the Transition

Do not decommission or reconfigure the old server immediately after flipping DNS. With TTL set to 300 seconds, most resolvers will pick up the new record within 5 to 10 minutes, but some ISP resolvers ignore TTLs and cache records for hours regardless. Keep the old server running and capable of serving your site for at least 24 to 48 hours post-cutover.

Monitor old server access logs during this window. If you are still seeing significant traffic on the old server six hours after cutover, investigate which resolvers are responsible and whether there is a CDN or proxy layer still pointing to the old origin.

Step 8: Restore TTLs After Successful Migration

Once you have confirmed the migration is stable — typically 24 to 48 hours after cutover — raise your TTLs back to a sensible production value. A TTL of 3600 (1 hour) is a reasonable default for most sites. Values of 86400 (24 hours) are fine for records that rarely change, but they increase your recovery time if you ever need to make an emergency DNS change.

The Complete Migration DNS Checklist at a Glance

• Export and save a full zone file snapshot before any changes
• Record all A, AAAA, CNAME, MX, TXT, NS, CAA, SRV, and PTR records
• Lower TTLs to 300 seconds at least 48 hours before cutover
• Wait the full duration of the old TTL before proceeding
• Deploy and test the new server using IP or hosts file override
• Install and verify SSL on the new server before cutover
• Update subdomains first, then www, then root apex
• Do not change MX records unless email migration is also planned
• Update SPF TXT record if the new server sends email
• Verify propagation using dig against multiple public resolvers
• Keep the old server live for 24 to 48 hours post-cutover
• Monitor old server logs for residual traffic
• Restore TTLs to production values once migration is confirmed stable
• Update any hardcoded IPs in firewall rules, monitoring tools, and third-party integrations

Common Mistakes That Cause Migration Failures

Changing DNS at the same time as deploying application changes makes it impossible to determine which layer caused a failure. Separate DNS changes from application deployments where possible.

Forgetting wildcard records — if your zone has a wildcard A record (*.yourdomain.com), it needs to be updated along with the explicit subdomain records.

Migrating nameservers and server at the same time is the highest-risk combination. If you are switching both your DNS provider and your web host, do one first and fully verify it before doing the other.

Not having a rollback plan — your rollback plan is the saved zone file from Step 1 and your old server staying live. Know exactly what commands or dashboard clicks restore the old A records if something goes wrong.

DNS migrations are not complicated when approached systematically. The checklist above has been used to migrate everything from small business sites to high-traffic e-commerce platforms with zero unplanned downtime. The difference between a smooth migration and a three-hour outage is almost always preparation done 48 hours before anyone touches a live record.