What DNS and Hosting Records to Review Before a Website Migration

Before anyone touches your DNS or schedules a cutover, you need something most teams don’t have: a complete, trusted map of how your domain, hosting, email, and integrations actually work today.

Before a website migration, document and verify DNS records, name servers, hosting and backup details, SSL, email routing, redirects, and account ownership so nothing critical breaks in the move.

This isn’t about being “extra cautious.” It’s governance. If you can’t see the current wiring, you can’t safely change it—and you can’t hold anyone accountable when something breaks.

---

1. Why DNS and Hosting Records Matter More Than the Migration Date

When a migration goes badly, it’s rarely because someone couldn’t copy WordPress files or export a database. It’s because no one had a complete, verified picture of DNS records, hosting details, email routing, or who owned which accounts.

For supporting context before making that decision, WordPress Hosting articles hub explains the adjacent issue in more detail.

For supporting context before making that decision, related guidance on hosting migration checklist explains the adjacent issue in more detail.

We often see migrations rushed because a renewal is coming up, an old vendor relationship is souring, or someone wants a faster host. The pressure becomes: “Just move it this weekend.” That’s how you end up with:

• A site that loads, but contact forms quietly stop sending
• Email deliverability collapsing because SPF, DKIM, or DMARC didn’t follow
• Subdomains for login portals, careers, or microsites going dark
• No one able to fix it quickly, because the only person with registrar or DNS access left the company—or works at a previous agency

In Best Website’s migration and support work, the recurring pattern is simple: copying the site is easy; reconstructing missing records and ownership history under time pressure is what burns days and trust.

If you haven’t already framed your migration as a risk decision, it’s worth reading Why Hosting Migrations Should Start With Risk Review as a prerequisite perspective shift, because this article assumes you’re willing to slow down enough to reduce avoidable risk before touching DNS. related guidance on why hosting migrations should start with risk review

The rest of this guide focuses on one thing: making the invisible map of DNS, hosting, email, and ownership visible enough that you can decide whether you’re actually ready to migrate.

---

2. The Governance Goal: A Migration-Ready DNS and Hosting Inventory

Think of “migration-ready” as a governance threshold, not a technical badge.

A migration-ready DNS and hosting inventory means:

1. You can list every domain and subdomain in use. Not just the main www, but anything a customer, prospect, or staff member might touch.
2. You know where DNS is actually hosted and who can change it. Registrar, DNS provider, CDN, hosting—plus named people with login access.
3. You have a current snapshot of all DNS records that affect the business. A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, and key third-party integrations.
4. Hosting details are documented in human language. Where the site currently lives, how backups work, what SSL depends on, and any special configuration.
5. Email routing and critical tools are explicitly tied to DNS records. You know which records support email, forms, marketing tools, and SSO.
6. Decision rights are clear. You know who is allowed to approve changes and who is allowed to execute them.

If you don’t have this level of clarity, the right move usually isn’t “go slower on the migration,” it’s “halt the migration until the map exists.” The missing map isn’t an inconvenience; it’s a risk signal about how your website is being run.

---

3. DNS Records to Review and Document Before You Move Anything

In a 60–90 minute working session, your marketing lead, IT contact, and whoever will operate DNS during the migration should sit down (or jump on a call) and build a DNS inventory.

Below is the minimum list of DNS items to capture, with why each matters.

3.1 Name servers and DNS host

• What to record:

  • Registrar (where the domain is registered)
  • Current name servers (NS records)
  • DNS hosting provider (could be registrar, hosting company, or a separate DNS service)

• Why it matters:

  • If you don’t know where DNS is actually hosted, you can’t control the cutover.
  • If an old agency or vendor controls the DNS account, they can delay or derail the migration.
  • Migrations that discover this during a Friday night cutover often turn into emergencies.

3.2 A and AAAA records (web and key applications)

• What to record:

  • All A/AAAA records for the root domain (example.com), www, and any subdomains that point to web servers or apps.
  • For each, note: host (e.g., www), current IP, and what it actually serves (marketing site, app, portal, etc.).

• Why it matters:

  • These are the records that decide where your website lives.
  • If you miss an application subdomain (like portal.example.com), you can take down critical internal tools or customer dashboards.

3.3 CNAME records (aliases and third-party tools)

• What to record:

  • CNAMEs for www, tracking domains, link shorteners, landing page tools, and email providers (like send.example.com).
  • For each, note which vendor or tool it belongs to.

• Why it matters:

  • Many marketing tools depend on CNAMEs you set up once and forgot.
  • If a CNAME isn’t carried over, campaigns keep running but clicks land on errors or unbranded domains, eroding trust.

3.4 MX records (email routing)

• What to record:

  • All MX records for your primary domain and any domains that send or receive email.
  • The provider they belong to (Microsoft 365, Google Workspace, another host, etc.).

• Why it matters:

  • MX records determine where inbound email goes.
  • If MX records are changed or removed accidentally, staff stop receiving email. Most teams do not have a quick recovery plan for this.

3.5 TXT records (SPF, DKIM, DMARC, verification)

• What to record:

  • All TXT records, especially:
    • SPF (v=spf1 ...)
    • DKIM (selector-based keys like selector1._domainkey)
    • DMARC (_dmarc)
    • Site verification records for tools like search consoles or marketing platforms.

• Why it matters:

  • SPF, DKIM, and DMARC drive email deliverability. If they’re dropped or misconfigured, your outbound email is more likely to hit spam or be rejected.
  • Verification records are often tied to SEO tools, email senders, and platforms that are hard to re-verify under stress.

3.6 Subdomains and microsites

• What to record:

  • Every subdomain in DNS with a description of what it does.
  • Highlight subdomains for HR portals, careers, events, legacy microsites, or partner integrations.

• Why it matters:

  • These are the pieces that break in ways leadership notices days or weeks later.
  • If you don’t know a subdomain exists, you can’t test it post-migration.

3.7 Third-party services and vendor records

• What to record:

  • Any DNS records that explicitly reference vendors: email platforms, analytics, CDNs, security tools, CRMs, marketing automation, chat widgets.
  • Include notes on which internal owner or team uses each tool.

• Why it matters:

  • Vendor records are where “shadow IT” shows up—tools nobody admits to owning.
  • During a migration, these are easy to drop because the immediate website looks fine, but tracking, alerts, or integrations quietly fail.

Governance test: If your team can’t clearly explain what each record does and what would happen if it disappeared, you’re not yet migration-ready.

---

4. Hosting, Backups, and SSL: What Your New Provider Must Know

DNS is only half the map. The other half lives in your current hosting environment—and your future host needs a clean picture of it.

4.1 Hosting environment details

Capture:

• Current hosting provider and plan type (shared, VPS, dedicated, managed WordPress, etc.).
• Server location (region) if you know it.
• Whether you use a CDN or caching layer in front of the host.

Why it matters:

• If you’re moving from a generic host to managed WordPress, some previous workarounds or plugins might no longer be necessary—or might conflict with built-in features.
• Server location and caching can affect performance and compliance expectations; changing them without planning can surprise stakeholders.

4.2 Access methods and credentials

Document, without putting passwords in a casual spreadsheet:

• How you currently access the site: control panel, SFTP/SSH, or a hosting dashboard only.
• Where database access lives and who can reach it.
• Any restrictions or unusual firewall rules.

Why it matters:

• Your new provider needs to know how they’ll pull a clean copy of the site for migration.
• If only one person at an old vendor can reach the server, that’s an ownership problem, not a technical issue—and it must be solved before you schedule a cutover.

4.3 Backups and restore points

Record:

• Where backups are stored (on-server, off-site, both).
• How often backups run and how many versions are retained.
• Whether anyone has tested a restore in the last year.

Why it matters:

• Backups are your safety net if the migration exposes a deeper problem.
• If backups live only on the current server and that server is shut down immediately after migration, you lose a clean rollback path.

4.4 SSL/TLS certificates

List for each domain and subdomain that serves HTTPS:

• Who issues the certificate (Let’s Encrypt, registrar, third-party CA, etc.).
• How it is renewed (automated or manual).
• Where validation emails go, if any.

Why it matters:

• During migration, SSL can quietly break if certificates were bound to old IPs, old control panels, or email addresses no one monitors.
• If you don’t know how SSL renews today, you risk security warnings appearing months after migration when a certificate silently expires.

4.5 Special configuration and performance notes

Note anything unusual:

• Custom redirects configured in the web server rather than in WordPress or a plugin.
• Caching plugins, security plugins, or WAF (web application firewall) rules.
• File or directory customizations beyond a standard WordPress setup.

Why it matters:

• Custom redirects often encode years of marketing decisions. If they aren’t identified and migrated, SEO and user journeys suffer.
• Overlapping caching and security layers can cause subtle bugs at the new host unless they’re reviewed deliberately.

During audits, we’ve noticed that this is where “tribal knowledge” hides—things a previous developer knew but never wrote down. If you only discover them when something breaks on the new host, you’re back in reactive mode.

---

5. Email, Forms, and Integrations That Quietly Depend on DNS

From a business perspective, “the site is working” really means “we can be found, and leads and communications still flow.” That depends heavily on DNS, even if it’s not obvious.

5.1 Email sending and deliverability

Beyond MX, your DNS records control whether your emails look legitimate to receiving servers.

Checklist:

• Confirm SPF includes all systems that send mail for your domain (CRM, marketing automation, transactional tools, ticketing, etc.).
• Confirm DKIM records exist for each major email-sending tool.
• Check whether a DMARC record exists and note its policy.

Risk: If you move hosting and adjust DNS without checking these, you may not notice deliverability issues until campaigns underperform or customers complain that they never saw password resets or invoices.

5.2 Form notifications and routing

Most business-critical forms send email notifications or route data to another system. Map:

• Which forms exist (contact, quote, demo, support, careers, etc.).
• Where each form sends data (email addresses, CRMs, helpdesks, HR systems).
• Whether any of those destinations depend on the same domain’s email configuration.

Risk: It’s common for forms to keep showing a “thank you” message while their email notifications silently fail after migration. If no one is watching, you lose leads without realizing it.

5.3 Marketing and analytics integrations

List tools like:

• Tag managers and analytics platforms
• Ad platforms and conversion pixels
• Landing page or webinar systems using custom subdomains

Then tie them to DNS:

• Which DNS records point to them (CNAMEs, A records, TXT verification).
• Which pages or campaigns depend on those records.

Risk: If tracking or verification records are dropped, you might lose attribution and reporting exactly when leadership wants to see whether the new hosting improved performance.

5.4 APIs, SSO, and internal tools

For more complex setups, identify whether DNS underpins:

• API endpoints that external partners hit (e.g., api.example.com).
• SSO and identity providers that rely on specific URLs or certificates.
• Internal tools or VPN entry points that ride on the same domain.

Risk: These are rarely visible to marketing teams but highly visible to operations when they go down. If they fail during a weekend migration, you may be waking up IT leadership instead of celebrating a smooth launch.

Governance rule: For every DNS change you plan, ask: “What email, forms, or integrations depend on this, and how will we know if they’re still working after the cutover?”

---

6. Ownership, Access, and Decision Rights: Who Can Actually Change DNS?

The most sophisticated record inventory is still dangerous if you don’t control the accounts that manage those records.

During migrations, we often see a pattern like this generalized scenario:

• The marketing director believes “IT has the domain.”
• IT assumes the old agency is still watching DNS.
• The old agency claims they transferred everything years ago.
• No one can log into the registrar without digging through personal inboxes from three job changes ago.

That’s not a technical problem; it’s an ownership and governance failure.

6.1 Map every critical account

At minimum, list:

• Domain registrar account(s)
• DNS hosting account(s) (if different from registrar)
• Web hosting account(s)
• CDN or WAF accounts (if used)
• Email service provider account(s)
• SSL certificate management or automation (if separate)

For each, capture:

• Which legal entity owns the account (your company vs. a vendor)
• Who has admin-level access
• How access is shared (individual logins, shared password tool, SSO)

6.2 Clarify decision rights

Before migration planning goes too far, you should be able to answer:

• Who approves DNS and hosting changes at the business level?
• Who has the technical skills and access to execute them?
• Who is on-call or reachable during the cutover window?

If decision-making is fuzzy, you’re relying on goodwill and memory during a high-risk change.

6.3 Bring agency-controlled accounts back into your orbit

If an agency or vendor currently controls:

• The registrar
• The DNS account
• The primary hosting account

then your first project is not “move the site,” it’s “regain ownership and documentation.” That’s why we treat pieces like What Website Teams Should Document Before an Agency Also Controls the Domain, DNS, and Hosting as escalation guidance when agency control becomes a risk, not just an inconvenience. related guidance on what website teams should document before an agency also controls the domain dns and hosting

No serious migration should proceed until critical accounts are owned by your organization, with vendors granted access rather than the other way around.

---

7. A Simple Maintenance-Maturity Lens for Pre-Migration Record Review

To keep this practical, apply a simple three-level Maintenance Maturity lens to your DNS and hosting records before approving any migration date.

Level 1: Reactive and opaque

Signs:

• You don’t know where DNS is hosted without asking multiple people.
• Only one external vendor can change DNS or hosting settings.
• There is no written inventory of DNS records or hosting details.
• Migrations are driven by renewal panic or cost-cutting.

Implication: Any migration at this level is high-risk. Expect outages, lost leads, and time-consuming forensics afterward.

Decision: Do not schedule migration yet. Commit to an ownership and documentation project first.

Level 2: Documented but fragile

Signs:

• You can produce a basic DNS export and hosting overview.
• Critical records (MX, SPF, key subdomains) are identified, but some tools remain “mystery records.”
• Account ownership is mostly correct, but a few logins still sit with legacy vendors or individuals.

Implication: A carefully run migration is possible, but you’re still vulnerable to surprises. Cutover should include extended monitoring and contingency plans.

Decision: Proceed only with a clear migration plan and test window. Use the project to close remaining ownership and documentation gaps.

Level 3: Proactive and governed

Signs:

• DNS and hosting inventories are current, versioned, and accessible to the right people.
• Account ownership resides with your organization; vendors have delegated access.
• Changes follow a simple but real change-approval process.
• You can quickly answer: “If we move hosts, which records and tools must we touch?”

Implication: Migrations are still work, but they’re predictable projects instead of fire drills.

Decision: You’re migration-ready. Focus on the hosting tradeoffs themselves rather than whether the basics will break.

This Maintenance Maturity lens isn’t only useful for migrations. It’s how we evaluate whether a website is run as infrastructure or as a string of emergencies.

For a broader view of how hosting concerns can graduate into a real improvement plan, the post on what to review before turning WordPress hosting concerns into a website improvement plan expands this maturity thinking beyond migrations into ongoing change decisions. related guidance on what to review before turning wordpress hosting concerns into a website improvement plan

---

8. Turning Your Record Review Into an Ongoing Hosting Practice

Once you’ve built your DNS and hosting inventory, the worst thing you can do is treat it as a one-time migration artifact and let it rot.

8.1 Run a migration-ready working session

Before approving a migration date, run a structured 60–90 minute session with:

• A business owner or marketing leader who understands priorities
• An internal IT contact (or technical partner)
• The current and prospective hosting partners

Agenda:

1. Walk through the DNS inventory and highlight high-impact records.
2. Review hosting, backups, and SSL details.
3. Confirm ownership of registrar, DNS, hosting, and email accounts.
4. Classify your Maintenance Maturity level (1–3).
5. Decide: migrate now, delay for cleanup, or change the plan.

8.2 Tie migrations to a recurring review cadence

Migrations expose weaknesses in how your website is run. Use that exposure:

• Establish a quarterly or semiannual DNS and hosting review.
• Update your inventory with each major site or tool change.
• Add a simple checklist to your marketing and IT workflows whenever a new domain, subdomain, or vendor is added.

Connecting this work to a regular cadence is how you prevent “record chaos” from slowly returning.

8.3 Separate governance from heroics

If your team relies on one highly technical person to rescue the site during each change, that’s a warning sign. Sustainable operations don’t depend on heroics; they depend on clear records, ownership, and processes that survive staff changes.

That’s why our hosting content doesn’t stop at checklists. The Hosting Migration Checklist for Business Websites is helpful as an expansion when you want a step-by-step project view, but it assumes you’ve already done the governance work this article focuses on. related guidance on hosting migration checklist

8.4 Decide how you want DNS and hosting to be managed long term

After doing this inventory once, most leaders see the same thing: keeping DNS, hosting, backups, SSL, and ownership aligned is real work. It needs a home.

You effectively have three choices:

1. Keep everything in-house and mature your own process. Build repeatable checklists and train more than one person.
2. Rely on a patchwork of vendors, each controlling a piece. Fast in the short term, but fragile and hard to govern.
3. Centralize on a partner that treats WordPress hosting as ongoing infrastructure, not just server space.

If your review uncovered confusing records, unclear ownership, or a fragile maturity level, this is where a fully managed hosting relationship can remove a lot of hidden risk.

A managed WordPress hosting engagement that takes governance seriously doesn’t just provide a server; it helps maintain a clean DNS and hosting inventory, reviews backups and SSL renewals, and brings Maintenance Maturity conversations into regular planning.

If you want that kind of operating model, it’s worth looking at how Best Website’s WordPress Hosting (Fully Managed) service handles infrastructure, DNS coordination, and ongoing review—so hosting decisions support your marketing and leadership priorities instead of constantly disrupting them. our Wordpress Hosting work

And if your inventory revealed messy ownership, agency-controlled domains, or records no one can fully explain, start a focused conversation with us about your specific migration risk and governance gaps; a short message outlining your current setup and concerns is often enough for us to recommend a practical path forward. To apply this decision to your own website, discuss the next step with our team.

From there, migrations stop being last-minute scrambles and start looking like what they should be: planned infrastructure projects grounded in clear records, sensible governance, and a hosting model that can keep up with the rest of your business.

For ongoing perspective and patterns on hosting infrastructure, risk, and Maintenance Maturity, you can also treat the broader collection of WordPress hosting articles as your reference library as you keep improving your operations over time. WordPress Hosting articles hub