I'm the de facto IT person for our small business, and we're planning to migrate our website and email hosting to a new provider next month. I realize I need to understand our current DNS management setup to ensure a smooth transition and avoid extended downtime. Our records are currently managed through our old hosting company's panel, which is confusing. For those who have handled similar migrations, what is your recommended process for auditing and transferring DNS records safely? Should I move management to a dedicated DNS service like Cloudflare before the hosting switch, and what are the critical record types beyond A, MX, and CNAME that I need to verify to ensure email, website, and any subdomains continue to function correctly after the cutover?
Here's a practical, field-tested plan you can follow for a DNS migration: 1) Inventory every DNS record in use (A/AAAA, MX, CNAME, TXT for SPF/DKIM/DMARC, SRV, NS, SOA, and CAA; note TTLs). 2) Mirror the zone in parallel on the new provider (Cloudflare or others) so you can flip quickly. 3) Lower TTLs for critical records to 300 seconds (or 60 if feasible) at least 24–48 hours before cutover. 4) Validate the new zone in a controlled test: use a staging host or a test subdomain, and verify website, subdomains, and mail flow. 5) Keep mail-related records consistent and, if using Cloudflare, set MX/DKIM/SPF to DNS-only (don’t proxy mail). 6) Plan the cutover window and switch NS at your registrar to the new provider only after you’re confident the new zone is a faithful replica. 7) Maintain a fallback plan (secondary DNS) for 24–48 hours post-cutover and monitor mail and site performance closely. 8) After go-live, recheck all records and consider enabling DNSSEC where supported for extra integrity.
Beyond A, MX, and CNAME, you’ll want to audit and verify several other records to keep email, apps, and subdomains functioning: AAAA (IPv6), NS and SOA (zone management and serials), TXT (SPF, DKIM, DMARC, domain verification tokens), SRV (service endpoints like autodiscover or SIP), CAA (which CAs can issue certs), and any mail-related subdomains (mail.yourdomain, autodiscover.yourdomain). If you use newer controls, also check for MTA-STS, TLSA (DANE), and DS/DNSSEC. Don’t forget any NAPTR records that might be in play for legacy services.
Cloudflare notes: you can move DNS there, but remember to keep mail records in DNS-only (gray) to avoid breaking mail delivery; the orange proxy only covers HTTP/S. For web traffic you can proxy A records to gain performance, but ensure your origin IPs remain protected and you’ve got proper SSL. After migration, verify propagation with multiple tests and consider pausing Cloudflare’s proxy on critical services during the cutover if you’re unsure. Also make sure DNSSEC is enabled if you plan to sign your zone and have DS records ready with your registrar.
Testing plan you can run before switch: create a staging/subdomain (e.g., test.yourdomain.com) that points to the new hosting; modify hosts files on several devices to resolve the domain to the new IP, and run a battery of checks (HTTP around the site, email delivery tests, and subdomain resolution). Use dig/nslookup +trace, curl -I, and even a quick mail send/receive test from multiple networks. Keep a test matrix and log any issues.
Cutover day playbook: set a maintenance window, ensure all critical records TTLs are low, and have backups of current zone. On cutover, update registrar NS to the new provider, monitor DNS propagation and site/email uptime, and be prepared to rollback if anything goes wrong. Afterward, verify delivery and site reachability for 24–72 hours, watch for flaky subdomains, and recheck TLS certs and mail flow.