Domain and DNS Migration Checklist for Hosting Changes

Changing hosting provider is often the right move for performance, cost or support reasons, but many teams hesitate because of one fear: breaking DNS and taking the site offline. A domain and DNS migration checklist can help you minimize downtime; avoiding interruption entirely depends on service overlap and application data consistency, not DNS settings alone. In this guide, we walk through a practical, step-by-step process for coordinating registrar changes, DNS zones and website moves between servers and platforms. We’ll look at how to inventory your existing DNS, plan TTL changes, sequence nameserver and A/AAAA record updates, protect email delivery and reduce SEO risks. Even if you are not a DNS expert, you’ll see how to plan a controlled change with explicit rollback prerequisites instead of taking a risky leap.

1. Understand What You’re Migrating: Domain, DNS and Hosting Roles

Before touching any setting, clarify which parts you are actually moving. Three components are involved:

• Domain (registrar level): where the domain is registered and renewed.
• DNS hosting (nameservers): where A, MX, CNAME, TXT and other records live.
• Web and email hosting: the servers that actually serve your website and handle email.

These three can live in the same place or at different providers. Example arrangements include:

• Domain at Registrar A, DNS at Registrar A, website and email at Host B
• Domain at Registrar A, DNS at Provider C, website at Host B, email at a separate SaaS provider

Zero-downtime migration starts with knowing that separation. If you only change web hosting but leave DNS and email where they are, your plan is much simpler than a full domain transfer plus DNS move.

For a quick refresher on how these components work together, our post what web hosting is and how domain, DNS, server and SSL work together is a good background read.

2. Pre‑Migration Inventory: Create a DNS and Domain Snapshot

2.1. List all domains and subdomains affected

Make a list of every hostname that depends on the hosting you’ll change. This often includes more than just example.com and www.example.com:

• Blog or shop subdomains: blog.example.com, store.example.com
• API and app endpoints: api.example.com, app.example.com
• Mail-related names: mail.example.com, smtp.example.com, webmail.example.com
• CDN or static asset subdomains: cdn.example.com, static.example.com
• Admin/staging: admin.example.com, staging.example.com

Anything that resolves via the DNS zone you’re changing must be considered in the plan.

2.2. Export your current DNS zone

Next, capture the exact DNS configuration as it exists today. Ideally, use the export function in your current DNS control panel (often called “zone file export”). If that’s not available, manually copy all records from the control panel. Use tools like dig or nslookup to check known names and record types, not as a complete zone inventory:

• A / AAAA records: web, API, FTP, mail servers
• CNAME records: www aliases, CDN hostnames, SaaS integrations
• MX records: mail exchangers and their priority
• TXT records: SPF, DKIM, DMARC, verification tokens (Google, Microsoft, etc.)
• SRV records: some VoIP, chat, or directory services
• CAA records: which CAs can issue SSL for your domain
• NS records: zone nameservers and any delegated subdomains; distinguish provider-managed apex records from delegations you must preserve

If you’re not fully comfortable with record types, our article DNS records explained step‑by‑step (A, AAAA, CNAME, MX, TXT and SRV) will help you recognise what you’re looking at.

2.3. Capture domain and security settings

At the registrar and DNS level, record:

• Registrar lock / transfer lock status
• Current nameservers (e.g. ns1.example-dns.com, ns2.example-dns.com)
• Whether DNSSEC is enabled and configured (DS records present at the registry)
• Any WHOIS privacy and contact details

When you later change DNS or transfer the domain, you’ll need to know which of these security features must be adjusted. Our detailed domain security best practices guide explains how registrar lock, DNSSEC and WHOIS privacy interact during migrations.

3. Decide Scope: DNS Change Only vs Full Domain Transfer

There are three common scenarios when moving to a new hosting provider like dchost.com:

3.1. Scenario A: Keep registrar and DNS where they are, change only A/AAAA records

In this case, your domain stays at the current registrar, DNS stays on the current nameservers, and you only point the web records to your new hosting server IP (for example, a new shared hosting plan, VPS or dedicated server).

Pros:

• Usually the simplest option when only web hosting is moving
• Fewer changes affecting email or other services, provided they do not depend on the web records being changed
• No registrar transfer or DNS provider change required

Cons:

• Your DNS panel remains at the old provider
• You depend on their DNS uptime and performance
• If DNS or email is bundled with the old hosting, confirm the service entitlement before choosing this approach: establish which active plan will keep each retained service available after web hosting is cancelled, including any separate charges or account requirements.

3.2. Scenario B: Change DNS to the new hosting provider, keep registrar

Here the domain remains registered where it is, but you move DNS management to the new hosting provider’s nameservers, if DNS hosting is available with the chosen plan. You will recreate the DNS zone in the new panel and then switch the domain’s nameserver records at the registrar.

Pros:

• Single place for hosting and DNS management
• Potential integration with the hosting panel; compare the available DNS tooling before choosing this option

Cons:

• Requires careful zone copy and nameserver cutover planning
• DNSSEC and glue records (for private nameservers) need special attention

For choosing between hosting DNS and third-party DNS, see our comparison of Cloudflare DNS vs hosting DNS and nameserver strategies.

3.3. Scenario C: Full move — registrar, DNS and hosting

Sometimes you want to transfer the domain, move DNS, and change hosting as part of one project. Treat these as staged changes rather than a single simultaneous switch. Avoiding downtime depends on keeping the existing services available until the replacements are ready:

• Domain transfer (EPP code, transfer lock management)
• DNS zone recreation at the destination
• Hosting migration (files, database, email)
• DNS cutover for web and mail

Our article how to transfer a domain without downtime covers registrar-level details; in this post we’ll focus more on DNS and hosting interaction.

4. Plan TTL and Propagation: Allow Time for Cutover and Rollback

DNS changes don’t apply instantly worldwide. Each record has a TTL (Time To Live) value that tells resolvers how long they may cache the answer. Review TTLs in advance to reduce cache delays during cutover and rollback; shorter TTLs do not make either change instantaneous.

4.1. Lower TTL before the migration window

A practical TTL schedule looks like this:

1. At least one existing TTL period before cutover: Lower TTLs on records that will change (A/AAAA for www & root, MX if mail servers move, and any affected TXT records) to something like 300–600 seconds (5–10 minutes), where supported.
2. Wait for the old TTL period to elapse: For example, if the old TTL was 4 hours, wait at least 4 hours after all authoritative nameservers serve the lower TTL before cutover. Previously cached answers retain their old expiry; this wait is not a guarantee of a simultaneous global switch.
3. Perform the migration during a maintenance window when the shorter TTL is active.

This reduces cache delays if you need to revert a changed record, but rollback still requires the old service to remain available and its data to be consistent. Lowering A/AAAA TTLs does not shorten cached nameserver delegations, so a nameserver rollback needs separate planning. Our dedicated article TTL playbook for zero‑downtime migrations dives deeper into realistic TTL values and timing.

4.2. Understand DNS propagation expectations

Even with short TTLs, some recursive resolvers or local systems cache longer than they should, and some networks have their own DNS peculiarities. For business-critical sites, we recommend assuming that:

• With short TTLs already in effect, visitors may begin reaching the new destination within minutes
• Others may continue reaching the old server longer; do not treat a couple of hours as a guaranteed upper limit

That’s why a true zero-downtime migration normally keeps both old and new hosting environments online in parallel during the transition. For a clear explanation of why “24 hours” is often quoted and how to monitor propagation, see what DNS propagation is and why it takes time.

5. Prepare the New Hosting Environment Before DNS Cutover

Prepare and test the new hosting environment before DNS cutover. The preparation checklist typically includes:

• Web space / virtual host created for the domain
• PHP, database and caching configured for the application
• SSL/TLS certificate installed and tested for the production hostnames, whether issued by Let’s Encrypt or another CA
• Database imported and application config updated with new DB credentials

5.1. Sync website files and databases

Copy your site content to the new server using SFTP, rsync or control panel migration tools. For dynamic sites (WordPress, WooCommerce, Laravel, custom apps):

• Take a fresh backup of the database on the old host
• Import it on the new host
• Update config files (e.g. wp-config.php, .env) with new DB host, user and password
• Before cutover, synchronize changes made since the initial copy, including uploads. Plan how to handle writes from users, background jobs and webhooks during the overlap: use a coordinated shared-data or replication design, or pause writes for a final sync. Do not let independent database copies accept divergent orders or updates.

If you’re moving from shared hosting to a VPS, our post moving from shared hosting to a VPS without downtime covers application-side details like background jobs and cache.

5.2. Test the site on the new server without DNS changes

You can usually test the new hosting by:

• Using a temporary URL or preview link (if your panel provides one), or
• Editing your local hosts file to map example.com and www.example.com to the new server IP

Browse the entire site, including login, checkout, forms, and any custom flows. Restrict access to any preview or staging environment containing production data with authentication; robots.txt is not access protection. Disable or isolate scheduled jobs and outbound integrations on the test copy so they cannot duplicate production orders, emails or webhooks. Use sandbox payments and controlled email recipients so test transactions do not trigger real charges or customer notifications. Verify the production hostnames and HTTPS as well as any preview URL. Check logs and fix any errors before DNS cutover. If you’re using a CDN, verify that it can reach the new origin server and that cache rules work as expected.

5.3. Prepare DNS zone at the new provider (if changing nameservers)

If you’re moving DNS to your new hosting provider, create the DNS zone but do not change the registrar nameservers yet. Use your earlier export as an inventory of the records to recreate, rather than blindly importing provider-managed zone data:

• For web: point applicable root and www A records to the new IPv4 address and AAAA records to the new IPv6 address; preserve any intended CNAME or CDN routing
• For email: preserve the same MX records if mail stays where it is. If mail moves, prepare the intended MX records, but do not expose them through a nameserver change or record update until the mailbox-readiness and overlap gates in Section 7 are met.
• All required TXT, CNAME, SRV, CAA and other service records from the old zone, with provider-managed records handled according to the new provider’s migration instructions

Double-check that nothing is missing, especially TXT records for SPF, DKIM and DMARC.

6. Step‑by‑Step DNS Cutover: Minimize Downtime

The exact steps depend on which scenario you’re in. We’ll cover the two most common: “A/AAAA change only” and “nameserver change”. In both cases, we assume you already lowered TTLs.

6.1. Case 1: Only changing A/AAAA records (DNS provider stays the same)

1. Confirm TTLs are low (e.g. 300–600 seconds) for the records you’re about to change, and that the previous TTL has elapsed since lowering them.
2. Update applicable A/AAAA records for the root and www: Use the new IPv4 address for A and the new IPv6 address for AAAA. Do not leave AAAA pointing at a retiring server; if the new host has no IPv6 service, plan its removal. Preserve intended CNAME or CDN routing.
3. Update any other hostnames that should now point to the new server (api, admin, staging, etc.).
4. Wait 5–15 minutes and test from multiple networks (home, mobile, VPN) using dig, nslookup or online tools to sample which IPs those resolvers return, rather than infer global completion from a few checks.
5. Keep the old server online through the expected cache overlap and while monitoring shows it is still needed. Treat 24 hours as a planning allowance, not proof that all traffic has moved, and keep application writes coordinated as described above.
6. Once you’re confident all traffic has shifted, you can raise TTL back to more cache-friendly values (e.g. 1–4 hours).

6.2. Case 2: Changing nameservers to a new DNS provider

This is slightly more complex, because you switch the entire DNS authority from one provider to another.

1. Ensure new DNS zone is complete: Reconcile the old zone’s service records with the new zone, updating destinations where necessary and handling provider-managed records according to the migration instructions.
2. Plan the DNSSEC trust-chain transition before changing nameservers. DNSSEC support at the new provider does not make its keys match the existing parent DS. If both providers support a documented migration that preserves validation, follow that coordinated procedure. Otherwise, plan a temporary unsigned delegation: remove the old DS through the registrar, verify its removal at the parent, and wait for the previously published DS TTL to expire before changing authority or disabling the old zone’s signing. Keep the old zone signed while cached DS records can still require its keys. This approach temporarily removes DNSSEC protection; do not treat a fixed number of hours as universally sufficient.
3. At the registrar, change nameservers to the exact NS values assigned by the new DNS provider.
4. Sample DNS answers with a domain and record type, for example dig @1.1.1.1 example.com A and dig @1.1.1.1 example.com NS. Replace example.com with your domain and repeat through other resolvers. Compare returned addresses and NS records with the intended zone. These queries show the selected resolver’s answers, which may be cached; they do not reveal which authoritative server it contacted or prove that every resolver has changed.
5. Keep the old DNS zone active at the previous provider for at least 48–72 hours as an initial planning allowance; do not retire it until the relevant cache lifetimes and monitoring support doing so.

During this overlap period, some users may still look up records from the old NS set. Keeping both zones valid and their destinations operational reduces downtime risk, but HTTPS and application data consistency must also work on both paths.

6.3. Re‑enable DNSSEC (if you use it)

For the temporary unsigned-delegation procedure above, wait for the previous delegation/NS cache lifetime to expire before publishing the new DS. Confirm the new authoritative zone is complete, reachable and correctly signed, then follow your provider’s activation procedure. A few recursive-resolver samples showing new NS records are not a substitute for that cache interval.

• Enable DNSSEC signing at the new provider and verify its published DNSKEY and signed records according to the provider’s checks.
• Obtain the new DS details (key tag, algorithm, digest type and digest) from that provider.
• After the delegation overlap described above, publish the matching DS at the parent through the registrar; verify the resulting chain with a DNSSEC validation tool and monitor for validation failures.

Follow the provider’s instructions closely to avoid a misconfiguration that could cause DNS failures. If DNSSEC is a core part of your security posture, our guide what DNSSEC is and how to enable it step‑by‑step provides an operator-friendly walkthrough.

7. Email, SPF/DKIM and Other Gotchas During Domain & DNS Migration

Email needs a separate migration check from the website. When DNS or domain settings change, it’s easy to accidentally break MX records, SPF/DKIM or IMAP/SMTP hostnames. This checklist covers mail-DNS continuity and readiness gates, not a complete mailbox-migration procedure. If email hosting is moving, require a separate provider-specific plan for mailbox provisioning, existing-message migration, client settings and synchronization before changing mail routing.

7.1. Decide whether email is moving

Ask yourself:

• Is email staying on the old provider, or moving to the new hosting provider?
• Is email hosted on a separate SaaS platform (e.g. a cloud email suite) that should not change?

If email is not moving, preserve the existing MX records, mail-host address records and authentication records needed by that service. Confirm that the mail service and its DNS dependencies will remain available under an active plan if the old web hosting is cancelled. Separately review any website-generated email: a new sending server may require an authentication update even when mailboxes stay put.

If email is moving, complete these gates under the separate mailbox-migration plan before exposing new MX destinations:

• Provision destination mailboxes, aliases and required routing rules; verify capacity, account access, receiving and authenticated sending.
• Back up and copy existing messages and required folders, and verify the migration results. Prepare the new service’s SPF, DKIM and other required authentication settings, along with the IMAP/SMTP settings users and applications will need.
• Agree how to capture and reconcile messages delivered to the old destination while senders still use cached routing. Use a supported synchronization or forwarding procedure that avoids loops and accounts for users accessing either system; an initial message copy is not sufficient.
• Keep both mail services available through the overlap. Before retiring the old service, complete final message synchronization, check for remaining arrivals there, and verify sending, receiving and user access at the destination. Base retirement on the migration plan, cache lifetimes and monitoring, not a fixed waiting period alone.

7.2. Preserve or update MX, SPF, DKIM and DMARC

Pay particular attention to:

• MX records: They must point to your active mail servers with correct priority values.
• SPF (TXT): Authorize the sending IPs used for your domain’s envelope MAIL FROM or HELO identity, including applicable web servers and email services. SPF does not directly authenticate the visible From header. Update the existing single SPF policy using appropriate mechanisms, not a bare hostname or a second SPF policy. Account for the ten-term limit on DNS-causing terms, including nested evaluation. Publish authorization before the new source starts sending, and retain authorization for the old source until it stops sending.
• DKIM (TXT): Copy selector records (e.g. default._domainkey.example.com) from the old DNS zone if the mail server remains the same. If the sending service changes, publish its required selector public-key records before sending begins. Retain previous selector records while earlier signed mail may still need verification.
• DMARC (TXT): Make sure policy and reporting addresses remain correct.

For a deeper dive on sender authentication, check our guide SPF, DKIM and DMARC explained for cPanel and VPS email.

7.3. Verify nameservers when transferring a domain

Do not assume a registrar transfer also requires changing DNS providers. If the transfer workflow includes a nameserver change, confirm that it is intended: pointing to a zone without the required mail records can make email suddenly stop working. We’ve covered this in detail in why domain transfers break email and how to avoid it.

The short version: when transferring a domain, explicitly confirm which nameservers will be used after the transfer, and ensure the correct DNS zone (with MX, SPF, DKIM, etc.) exists and is active there.

8. SEO and HTTPS Considerations During DNS Migration

DNS and hosting changes, if done correctly, should not harm your SEO. The two big risks are:

• Prolonged downtime or serving errors (4xx/5xx) to crawlers
• Serving different content or broken redirects on the new host

8.1. Keep content and URLs identical across old and new hosts

During the parallel-running phase, both old and new servers should serve the same URLs and content. That way, regardless of which IP a user or search engine hits during propagation, they see a consistent site.

If you plan a redesign or URL structure change, do that after the hosting migration is stable. Trying to change everything at once increases the chance of SEO impact.

8.2. Ensure SSL/TLS is active on the new host before cutover

Install and test HTTPS on the new server before you point traffic to it. Verify:

• Certificates match the domain and intermediate chains are correct
• HTTP to HTTPS redirects work exactly as on the old host
• No mixed-content errors on key pages

If you’re using Let’s Encrypt or another ACME-based setup, prepare challenges and automatic renewals ahead of time so that you don’t hit certificate errors right after the move.

9. Post‑Migration Checklist: Verify, Monitor and Then Decommission

Once DNS changes are live and traffic is flowing to the new hosting, don’t rush to delete the old environment. Use a structured post-migration checklist.

9.1. Technical verification

• Check the site from multiple networks and locations
• Confirm that A, AAAA, MX and TXT records resolve correctly from different public resolvers
• Send and receive test emails from various providers (Gmail, Outlook, corporate accounts)
• Verify SSL/TLS status using browser tools and online checkers

9.2. Application-level checks

Walk through all business-critical actions:

• Log in / log out
• Contact forms and lead capture forms
• Shopping cart, checkout and payment gateways
• File uploads and downloads
• Admin actions (creating posts/products, editing settings)

9.3. Monitoring and logs

For at least a few days after cutover:

• Watch error logs (web server, PHP, application logs)
• Monitor resource usage (CPU, RAM, disk, database performance)
• Keep uptime monitoring active for key URLs and services

If you see any persistent errors or slow paths that didn’t exist before, investigate quickly while the old environment is still available as a reference.

9.4. Clean up and raise TTLs

Once you’re confident everything is stable:

• Increase DNS TTLs to reduce query load and take advantage of caching (e.g. 1–4 hours for most records)
• Before cancellation, review service entitlements and dependencies with the old provider. Confirm that any retained DNS or email service has an active plan and will survive cancellation of the web hosting or registrar bundle; do not assume that an accessible control panel proves continued entitlement.
• Keep the old authoritative DNS service active until the relevant delegation, record and DNSSEC cache lifetimes and monitoring support retirement. Web traffic moving to the new host is not sufficient reason to remove the old zone.
• If email moved, complete the mailbox plan’s final synchronization and delivery checks before retiring the old mail service. If email stayed, leave its mailboxes, routing and required address records operational.
• Take final backups and decommission only the old hosting resources that no retained service, cache-overlap path or rollback plan still needs
• Document the new architecture (where domain, DNS, web and email now live)

10. Putting It All Together

Domain and DNS migrations don’t have to be scary or mysterious. When you break the process into clear stages—inventory, TTL planning, environment preparation, careful cutover and structured verification—you can move between hosting providers with little or no user-visible downtime. Treat the migration as planned change management: document all records, lower TTLs early, keep both environments available during the transition, and prepare a rollback plan that accounts for any data written after cutover.

Whether you’re moving a single business site or dozens of customer domains, you can reuse the checklist above to make the next migration far less stressful. If you want migration assistance, agree with the chosen provider on who will review the DNS inventory, plan TTL changes, execute the cutover and verify web and email service afterward. Confirm the support scope before scheduling the move.