Dns Checklist During Website Migration

DNS Checklist for Low-Risk Website Migrations (Without Killing SEO or Email)

Most website migrations don’t get wrecked by code—they get wrecked by DNS that nobody really owns.

During website migration, use a DNS checklist that covers full record inventory, TTL adjustments, staged cutover, email and redirect verification, and 24–72 hours of post-launch monitoring.

In real projects, DNS becomes a game of assumption hot-potato: marketing assumes IT has it, IT assumes the agency has it, and the registrar is still controlled by an ex-employee. That’s how “small” DNS edits turn into downtime, broken email, and SEO drops.

The fix is to treat DNS as its own governed migration stream: inventory, align with the plan, test with low TTLs, cut over deliberately, then verify SEO and email while you still have rollback options.

This article gives you a copy-pasteable checklist, but more importantly, a decision model you can walk into your launch planning meeting with.

---

Why DNS Can Quietly Ruin a Website Migration

DNS looks like plumbing, but in a migration it behaves more like air traffic control. A tiny misconfiguration in the wrong minute can redirect all your traffic to nowhere—or to the wrong place—for hours.

We often see three failure modes:

1. Downtime and partial outages
   The new site goes live, but some visitors still hit the old server for hours because of long TTLs. Or the root domain works while www fails. Or a forgotten subdomain—like docs.example.com or a partner portal—goes dark because nobody realized it was wired through the old DNS settings.

2. Broken email and third-party tools
   MX, SPF, DKIM, and DMARC records are fragile during migrations. If they’re copied wrong, left behind, or overwritten in a “clean-up,” sales and support teams stop receiving email or outbound mail lands in spam.

3. SEO erosion that shows up weeks later
   DNS and host configuration can split authority between example.com and www.example.com, expose both HTTP and HTTPS, or strand redirects on the wrong endpoint. Search engines see conflicting signals, crawl errors, and unstable hosting patterns.

The pattern under all of these: no one treats DNS as a governed workstream with clear ownership, change history, and rollback options.

Use the checklist below as a runbook for your next migration planning session.

Section checks – Governance and risk framing

• Name a single DNS owner for the migration (not a team: a person).
• Decide now: is DNS in-scope as its own workstream with explicit milestones?
• Capture where DNS is currently managed (registrar vs. DNS host vs. CDN).
• Write down the rollback trigger: what conditions force you to revert DNS?

---

Step 1: Inventory Existing DNS Records Before You Touch Anything

If you don’t know exactly what you have today, you can’t know what you’re breaking tomorrow.

Before anyone logs into a control panel to “clean things up,” take a complete snapshot of current DNS. This isn’t busywork; it’s your insurance policy and your rollback plan.

Inventory at least:

• A / AAAA records for root domain and all subdomains
• CNAME records (especially for www, CDNs, and third-party apps)
• MX records (email delivery)
• TXT records (SPF, verification tokens, security tools)
• SPF, DKIM, DMARC configurations, wherever they live
• SRV, CAA, and other special records for VOIP, certificates, etc.

Then add something most teams skip: ownership mapping. Every critical record should have a business owner (marketing, sales, support, IT, finance) and a system owner (which tool or provider depends on it).

A simple spreadsheet works:

• Hostname (e.g., example.com, www.example.com, mail.example.com)
• Record type
• Current value
• TTL
• Business owner
• System / tool
• Notes (keep/delete? investigate?)

In support work, we’ve noticed that migrations stall because this basic map doesn’t exist; decisions become guesswork, and everyone is afraid to delete “mystery” records.

Section checks – Inventory

Copy these into your runbook and don’t proceed until all are true:

• All DNS zones for the domains in scope are exported or screenshotted in full.
• Every hostname and record type has at least one business owner and one system/tool noted.
• “Unknown” records are tagged for investigation, not silently deleted.
• Subdomains for docs, portals, landing-page tools, and email providers are explicitly listed.
• A read-only archive (PDF/CSV) of the current DNS is stored in your migration folder.

---

Step 2: Align DNS Changes With Your Migration Plan and Timelines

DNS isn’t a last-minute IT switch; it’s one of the main levers in your launch schedule.

Tie DNS into your broader migration plan:

• Environments: Make sure everyone understands staging vs. production. DNS should point only to production-ready infrastructure, not to ad-hoc staging servers.
• Name servers vs. records: Decide whether you’re changing the domain’s name servers (moving DNS hosting) or just editing records at your current provider. Changing name servers is more disruptive and should be treated as a separate project unless there’s a strong reason.
• Dependencies: Align DNS timing with content freeze, redirect mapping, and analytics tagging so that when traffic lands on the new host, the site is actually ready.
• Approvals: DNS changes deserve the same governance as a code deploy: request, review, and sign-off.

If you already use a broader launch checklist, this DNS stream should sit alongside content and accessibility readiness. For example, your editorial stream might use the Content Editor Accessibility Checklist as a prerequisite quality gate, while DNS and technical SEO operate as parallel gates.

As a prerequisite to this decision, Content Editor Accessibility Checklist explains the adjacent issue in more detail.

Section checks – Alignment

Before adjusting TTLs or records, confirm:

• The migration plan explicitly mentions DNS as a separate workstream with dates and owners.
• You know whether you’re changing name servers, individual records, or both.
• There is a written approval flow for DNS edits (requester, reviewer, approver).
• DNS cutover is scheduled in a defined launch window with business stakeholders informed.
• DNS tasks are linked to other launch gates (content, accessibility, analytics, redirects).

---

Step 3: Lower TTLs and Run Safe Pre-Migration Tests

DNS timing is as important as DNS values. Long TTLs can trap users on the old host for a day after you “go live.”

A few days before launch:

1. Shorten TTLs on critical records
   Reduce TTL to something like 300–900 seconds on the records you’ll change (root, www, key subdomains). Do this early so caches naturally expire.

2. Prepare test records
   Create temporary hostnames that point to the new infrastructure (e.g., test.example.com) so your team can hit the new environment using normal DNS instead of hosts-file hacks.

3. Verify SSL and basic routing
   Confirm that the new host has valid certificates for the domain variants you plan to serve, that HTTP redirects to HTTPS, and that www/root resolution behaves as designed.

4. Check performance and errors under light traffic
   Use internal teams or a small beta group through a test hostname to ensure there are no obvious 500s, routing issues, or miswired CDNs.

The goal is to protect launch-day by discovering configuration problems when TTLs are low and traffic is controlled.

Section checks – TTL and pre-cutover testing

• TTLs for all records involved in the launch are reduced well before cutover.
• You have at least one test hostname pointing to the new infrastructure.
• SSL certificates on the new host cover all production domain variants.
• HTTP→HTTPS redirects behave correctly in tests.
• New hosting has been exercised with real content and basic load, not just a placeholder page.

---

Step 4: Plan the Cutover: What Changes, In What Order, and Who Pushes the Button

Cutover is where ad-hoc behaviour causes real damage. “IT will flip it sometime Friday” is not a plan.

Instead, treat cutover like a mini-release with:

• Clear sequence: Know exactly which records change first. Typically: root and www, then key subdomains, then any supporting records that must move.
• One canonical host: Decide whether your canonical domain will be example.com or www.example.com and make every redirect and DNS choice reinforce that.
• Named roles: Who executes changes, who verifies, who can call rollback, and who communicates to stakeholders.
• Time-boxed window: A defined start time, duration, and acceptance criteria before you consider the launch complete.

During the window, avoid mixing high-risk tasks. For example, don’t change name servers and platform and email provider all at once if you can stage them.

Section checks – Cutover readiness

• A written step-by-step cutover plan lists each DNS change and its order.
• You have explicitly chosen a canonical host (root or www) and documented why.
• Execution, verification, and rollback roles are assigned to named people.
• The launch window is agreed with business stakeholders and support teams.
• High-risk changes (name server move, platform change, email move) are staged where possible, not bundled into one moment.

---

Step 5: Protect Email and Other Non-Web Services During DNS Changes

Email is usually the first thing that breaks in a rushed migration—and the last to be spotted because it doesn’t show on the homepage.

To protect it, treat email and other non-web services (VOIP, CRMs, marketing tools) as first-class DNS citizens:

• MX records: Confirm the current provider, copy the exact MX records (including priorities), and verify that the provider doesn’t require additional changes when you move hosts.
• SPF: Ensure SPF records include all legitimate sending services (your app, CRM, support, marketing platform). During migration, avoid “simplifying” SPF without understanding the impact.
• DKIM and DMARC: Check where keys and policies are managed and make sure any domain or subdomain changes don’t invalidate them.
• Third-party tools: Many tools use CNAMEs or TXT records for verification and routing. Keep these intact unless you’ve deliberately decommissioned the service.

To operationalize this decision, how our SEO & Content Strategy Services work supports this decision explains the adjacent issue in more detail.

We often see migrations where someone enthusiastically “cleans out old DNS clutter,” only to wipe out MX or verification records for tools that still matter.

Section checks – Email and services

• All current MX records and their priorities are documented and preserved.
• SPF records are reviewed with a clear list of all systems that send email on your behalf.
• DKIM and DMARC settings are verified after any DNS host or record changes.
• DNS entries for CRMs, marketing platforms, analytics, VOIP, and ticketing tools are identified and protected.
• A simple live test plan exists for email (send/receive to internal and external addresses) immediately after cutover.

---

Step 6: Verify SEO-Critical DNS Behaviors After Cutover

Once cutover is complete, your primary question is not just “is the site up?” but “is the site resolvable and crawlable in the way we intended?”

Here DNS and technical SEO meet.

Check for these SEO-critical behaviours:

1. Canonical domain resolution
   Hit both http://example.com, http://www.example.com, and their HTTPS equivalents. You should see one canonical host, with every other variant 301-redirecting to it.

2. HTTPS and certificates
   Ensure all live hostnames have valid certificates and no mixed-content warnings. Browsers and crawlers both penalize inconsistent HTTPS.

3. Redirect chains and loops
   DNS can send users to the wrong host, which then redirects elsewhere. Use simple tools or browser plugins to check you don’t have http → oldhost → newhost → https chains that slow down or confuse crawlers.

4. Robots.txt and sitemaps
   Once DNS points to the new host, confirm that robots.txt and XML sitemaps are available at the expected URLs.

5. Bots can actually reach you
   Confirm that common checks (like basic curl requests) succeed and aren’t blocked by firewalls that only allowed the old IP range.

If you’re deep into technical SEO topics, this DNS checklist should sit alongside broader Technical SEO articles that deal with crawling, rendering, and performance. DNS is one layer in that stack.

For a deeper treatment of this decision, related Technical Seo articles guidance explains the adjacent issue in more detail.

Section checks – SEO and crawlability

• Only one domain variant serves as canonical; all others 301-redirect to it.
• All relevant hostnames respond with valid HTTPS and no certificate errors.
• Redirect chains from old to new hosts are minimized and free of loops.
• robots.txt and sitemaps are accessible on the new host.
• Basic curl or monitoring checks from external locations can reach the site without firewall or routing blocks.

---

Step 7: Monitor, Roll Back Safely, and Document for the Next Migration

The migration isn’t over when the homepage loads. It’s over when traffic has stabilized, monitoring is quiet, and you’ve documented what actually happened.

Immediately after cutover and over the next 24–72 hours:

• Monitor uptime and errors
  Keep an eye on uptime checks, HTTP error rates, and server logs. Some routing problems only surface under real visitor patterns.

• Observe traffic patterns
  Watch analytics for unexpected drops to key sections or spikes in 404s that could indicate DNS or redirect gaps.

• Keep rollback options open
  Don’t change TTLs back to very long values until you’re confident. If a serious issue appears, you want to be able to revert quickly.

• Document reality, not just the plan
  Update your DNS runbook with what you actually changed, when, why, and what you observed. This becomes a reusable node in your broader migration archive, not a one-off emergency script.

This is where the governance model matures: migrations stop being isolated fire drills and start feeding a repeatable operating model.

Section checks – Monitoring and documentation

• Uptime and error monitoring is in place before cutover and reviewed during the 24–72 hours after.
• Someone is actively watching analytics for abnormal traffic or 404 patterns.
• TTLs remain relatively low until you’re satisfied with stability.
• A DNS change log records timestamps, changes, reasons, and outcomes.
• Lessons learned from this migration are captured in your shared migration documentation.

---

Turning This DNS Checklist Into a Governed Migration Practice

If this checklist feels heavier than what your team usually does, that’s a signal: you’ve outgrown ad-hoc launches.

On smaller sites, a developer making a quick DNS tweak might be fine. But as soon as:

• multiple teams depend on the site for leads or revenue,
• email and third-party tools are mission-critical, or
• migrations touch multiple domains or environments,

you need a governed model, not heroic individual effort.

Think of your web archive as an interconnected system, not a pile of isolated posts and launches. A solid migration runbook will tie together DNS, hosting, redirects, accessibility, analytics, and troubleshooting. Articles like this DNS checklist sit alongside pieces such as the Content Editor Accessibility Checklist as prerequisite quality streams, and broader resources in your archive help you expand into related areas like performance or technical debt over time.

That’s the buyer maturity path we see: teams move from “we just need this launch to not break” toward “we want an operating model that makes launches repeatable and safe.” DNS is one lens on that shift.

If you’re ready to translate this DNS workstream into a fully governed migration runbook—one that maps your redirects, technical SEO, DNS, and content dependencies—we design that kind of framework inside our SEO & Content Strategy Services offering at Best Website, including the checklists, decision gates, and measurement loops that keep future launches from turning into emergencies.

And if you’re staring down an upcoming migration with unclear DNS ownership, reach out through our contact form so we can assess your current plan, highlight the riskiest gaps, and help you decide whether to adjust, stage, or fully redesign your launch approach before it goes live.

Before the next website change, document and approve the ownership decision this article has outlined.