Migrating Hosting Without Losing Your Website: A Safe DNS Sequence

Migrating hosting often seems straightforward: copy files, import the database, and then point the domain to the new server. In practice, the most vulnerable part is not the data copying process, but the DNS transition. If the sequence is incorrect, some visitors may see the old website, others may encounter errors, and company emails may stop coming in.

The good news is that migration can be done with minimal disruption if you separate three tasks: setting up the new server, testing the website before redirecting the domain, and only then changing the DNS. With this pattern, DNS is no longer a "hope for the best" button, but the final switch after everything is ready.

First, understand: what actually changes?

DNS is the system that translates domain names like example.com into server addresses. The A record usually points to an IPv4 address, while AAAA points to IPv6. There are also MX records for email and TXT records for service verification, SPF, DKIM, or DMARC.

When migrating hosting, you typically change one of two things:

• A/AAAA Records: the nameserver remains the same, but the destination server address is changed.
• Nameserver: DNS management is moved to another provider, so the entire DNS zone must be set up again.

The difference is important. If DNS is managed by Cloudflare, for example, you can keep the Cloudflare nameserver and simply change the records to point to the new server. If DNS is still managed by the old hosting and you change the nameserver to a new provider, all records—including MX and TXT—must be ensured to be available in the new location. The nameserver is the authoritative server that provides definitive answers for your domain. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/nameservers/?utm_source=openai))

Step 1: Copy and set up the new server

Do not change the DNS until the new server is fully ready. Create a hosting account, install the appropriate PHP version, create a database, import data, and copy the contents of public_html or the application's document root.

For WordPress, check the database configuration file, site URL, file permissions, PHP version, and rewrite configuration. For PHP applications, ensure that the required extensions are available and environment variables are set. If using cPanel and WHM, the Transfer Tool can help move accounts along with file structures, databases, and DNS zones. However, the DNS update options need to be checked to ensure that custom records are not missed. ([docs.cpanel.net](https://docs.cpanel.net/whm/transfers/transfer-tool/?utm_source=openai))

The new server should be tested using one of the following methods:

• Temporary URL from the hosting provider.
• Testing subdomain like staging.example.com.
• Local hosts file that directs the domain to the new server's IP.

The hosts file method is useful because it only affects your computer. General visitors will still be directed to the old server until the DNS is changed.

Step 2: Inventory DNS before touching the nameserver

Create a list of all active records. Do not just note the website records. Also check:

• A and AAAA for the main domain and subdomains.
• CNAME for services like www, store, or third-party applications.
• MX for email servers.
• TXT for SPF, DKIM, DMARC, Google Search Console, and other service verifications.
• Special records like CAA or subdomain delegation.

Email sections are often overlooked because websites and emails can use different servers. If you delete or incorrectly copy the MX records, the website migration can turn into an email disruption.

If DNS is managed at the old hosting, export or copy the DNS zone first. If you are using Cloudflare, check the list of records in the dashboard and ensure that email records remain DNS only, not proxied like website traffic. Cloudflare itself illustrates MX and TXT as records that need to be configured according to each email service. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/?utm_source=openai))

Step 3: Lower TTL for a clear reason

TTL, or Time to Live, determines how long a DNS resolver can cache the answer. A long TTL makes DNS changes persist longer in the cache; a shorter TTL helps changes apply faster but makes the resolver ask again more frequently.

If you are planning a migration and have control over the DNS, lowering the TTL of the website records a day or two in advance is a practical step. This is not a guarantee that all users will switch immediately, as resolvers can have different caching behaviors, but it usually reduces the transition period.

Cloudflare explains that proxied records with automatic TTL generally use 300 seconds, while DNS-only records can use different TTL values. Old data may still be visible until the previous cache expires. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/?utm_source=openai))

Step 4: Redirect traffic, but do not turn off the old server

Once testing is complete, change the A or AAAA records to the new server's IP. If you are indeed moving DNS management, change the nameserver at the registrar after the new DNS zone is complete.

Do not turn off the old server immediately. Keep it running at least until you are sure that traffic has switched and no important processes are still pointing to that server. On websites that receive orders, comments, uploads, or transactions, the old server may still receive requests during the propagation period.

For applications with frequently changing data, perform one last database synchronization just before the switch. If the website accepts uploads, also copy any new files that come in during the transition. This is a part that is often overlooked in simple migrations.

Step 5: Verify from outside your network

Do not just open the website from your office Wi-Fi or your own laptop. Local resolvers may still hold the old answer. Check from several networks, such as a mobile connection, public resolvers, or different locations.

On macOS and Linux, you can use:

dig example.com A +short
dig www.example.com A +short
dig example.com MX +short
dig example.com TXT +short

To check the nameservers published by the parent zone, use:

dig +trace example.com NS

The dig +trace command helps see the delegation from the root to the domain's nameserver, not just the answer from one resolver that may still be using cache. Cloudflare also recommends checking directly with the authoritative nameserver when DNS results appear inconsistent. ([developers.cloudflare.com](https://developers.cloudflare.com/dns/troubleshooting/dns-issues/?utm_source=openai))

Do not forget SSL and email

Once the domain points to the new server, open both HTTP and HTTPS versions. Ensure the certificate covers the main domain as well as www if both are used. If the certificate is reissued through DNS validation, the required challenge records must be readable by the certificate authority.

Also test sending and receiving emails. Send a message from an external address to your domain, then reply from that domain account. Check the email headers if necessary to ensure SPF, DKIM, and DMARC are still correct.

What does this mean for us?

Safe hosting migration is not about how quickly the "change nameserver" button is pressed. The key is to prepare the new server first, inventory all DNS, maintain the old server during the transition, and then verify from multiple networks.

A brief checklist: backup, copy data, test without public DNS, inventory records, lower TTL if necessary, redirect traffic, check SSL and email, then monitor logs. If these steps are done in order, the hosting transition can be felt by the administrator—but hardly noticeable to visitors.

Sources & further reading

• Cloudflare: Time to Live (TTL)
• Cloudflare: Nameservers
• Cloudflare: General DNS issues
• Cloudflare: Change your nameservers (Full setup)
• cPanel & WHM: Transfer Tool
• Cloudflare: Zone stuck in Pending Nameserver Update

– Rio Yotto @rioyotto