Domain and DNS Migration Checklist When Changing Hosting Provider

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. The good news is that with the right domain and DNS migration checklist, you can switch hosting providers with zero or near-zero downtime. In this guide, we walk through a practical, step-by-step process we use at dchost.com when moving customer domains, DNS zones and websites 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 keep SEO intact. Even if you are not a DNS expert, you’ll see how to treat this as a predictable, reversible change instead of 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. Many customers come to us with:

• 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 or use tools like dig or nslookup to query them:

• 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 inside the zone (rare but possible)

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 at dchost.com).

Pros:

• Fastest and simplest option
• Almost no risk of breaking email or other services
• 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

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 (for example, to dchost.com nameservers). 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
• Often better DNS tooling and integration with hosting panel

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 a clean slate: transfer the domain, move DNS, and change hosting all together. This is fully doable without downtime, but requires the most disciplined checklist:

• 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: Make Changes Reversible

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. To make your migration painless and reversible, you must control TTLs in advance.

4.1. Lower TTL before the migration window

Our usual playbook looks like this:

1. 7–48 hours before cutover: Lower TTLs on critical records (A/AAAA for www & root, MX if mail servers move, some TXT records) to something like 300–600 seconds (5–10 minutes).
2. Wait for the old TTL period to elapse: For example, if the old TTL was 4 hours, wait at least 4 hours after lowering it before you trust the shorter TTL to be respected globally.
3. Perform the migration during a maintenance window when the shorter TTL is active.

This way, if you make a mistake, you can revert the record and most users will see the fix within a few minutes. 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:

• Most visitors will see the new destination within minutes
• A small percentage might continue to hit the old server for up to a couple of hours

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

Never start DNS changes before your new hosting environment is fully prepared and tested. On dchost.com this typically means:

• Web space / virtual host created for the domain
• PHP, database and caching configured for the application
• SSL/TLS certificate installed (or ready via Let’s Encrypt)
• 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

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. Check logs and fix any errors before touching DNS. 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. Recreate all records from your earlier export:

• For web: root and www A/AAAA records pointing to the new server IP
• For email: same MX records (if mail stays where it is) or updated MX (if mail moves)
• All TXT, CNAME, SRV, CAA and other records from the old zone

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

6. Step‑by‑Step DNS Cutover: Zero‑Downtime Playbook

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.
2. Update A/AAAA for the root and www: Set them to the new server IP.
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 confirm that most resolvers now return the new IP.
5. Keep the old server online for at least several hours (ideally 24 hours) to serve visitors who still hit the old IP due to caching.
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: Every record from the old zone must exist in the new one, with updated IPs where necessary.
2. Temporarily disable DNSSEC at the registrar if it’s currently enabled and your new DNS stack is not yet set up for DNSSEC. Failing to do this correctly can cause resolution failures.
3. At the registrar, change nameservers to the new provider’s NS values (for example, dchost.com’s nameservers).
4. Monitor propagation using dig @resolver against various public resolvers and online tools. You should see more and more resolvers querying the new nameservers over time.
5. Keep the old DNS zone active at the previous provider for at least 48–72 hours

During this overlap period, some users may still look up records from the old NS set, but because both old and new zones contain valid records pointing to working servers, they won’t see downtime.

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

After most resolvers are using the new nameservers and the new DNS provider supports DNSSEC, you can:

• Enable DNSSEC for the zone at the new DNS provider
• Obtain the DS record details (key tag, algorithm, digest type, digest)
• Add/update the DS record at the domain registry via your registrar

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

Most migration issues we see are not about the website but about email. When DNS or domain settings change, it’s easy to accidentally break MX records, SPF/DKIM or IMAP/SMTP hostnames.

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, make sure your new DNS zone keeps the existing MX records and related TXT records exactly as they are.

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): Should allow the IPs and sending domains that actually send emails for your domain (web server, transactional services, marketing tools, etc.).
• DKIM (TXT): Copy selector records (e.g. default._domainkey.example.com) from the old DNS zone if the mail server remains the same.
• 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. Beware of domain transfers that change nameservers automatically

Some registrars change your nameservers during a domain transfer (for example, to their default DNS) if you’re not careful. That’s one of the most common reasons email suddenly stops working after a domain move. 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)
• Decommission the old hosting environment (after taking final backups)
• Document the new architecture (where domain, DNS, web and email now live)

10. Putting It All Together: A Calm, Repeatable Domain and DNS Migration

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. In real projects at dchost.com, the most successful migrations are the ones treated as planned change management, not emergency surgery: all records documented, TTLs lowered early, both environments running in parallel, and a simple rollback plan ready if something looks wrong.

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 decide to move your domains, DNS or hosting to dchost.com, our team can help you review your current DNS, design a safe TTL and cutover strategy, and execute the migration step by step so your visitors and email users barely notice anything changed—except for the faster, more stable hosting on the other side.