Moving Hosting and DNS Without Downtime: The Order That Works

A host move should be invisible. Visitors keep arriving, orders keep coming in, email keeps flowing, and the next week the site is simply faster or cheaper to run. When moves go wrong it is rarely the copying of files that fails. It is DNS: a record nobody knew about, a certificate that could not be issued, a mail record lost when the nameservers changed, or a cached address that sends some visitors to a server that has just been switched off.

Our hosting, server and DNS management team follows the order below whether the job is one brochure site or a group of domains. A platform change, such as a website builder to WordPress, adds content and redirect work on top, which our migration service covers; the DNS part is the same.

First, Know Which Move You Are Making

"Moving hosting" can mean three different things, with very different risks:

• New web server, same DNS provider. You change the website's address records and nothing else. The lowest-risk version.
• New DNS provider. You change the nameservers at the registrar, so every record for the domain, including email, must exist at the new provider before the switch.
• Both at once. Common when leaving an all-in-one host. We usually split it into two moves a few days apart, so if something breaks you know which change caused it.

Step 1: Inventory Every Record

Export the full zone from the current DNS provider, not just the records on the main screen, and write down what each one is for. A typical business domain has more than people expect:

• A and AAAA records for the website, and CNAMEs for www and other subdomains.
• MX records for email, plus SPF, DKIM and DMARC TXT records.
• Verification TXT records for Google, Microsoft, payment providers and other tools.
• CNAMEs for a help centre, a booking system, a shop subdomain or an email sending service.
• SRV records for phone systems or Microsoft 365, and CAA records restricting who may issue certificates.

Anything you cannot identify, keep. A record that looks redundant is often the one holding up an integration nobody has touched in years. If the old host's control panel created records automatically, such as mail or webmail subdomains, they must be recreated by hand at a new provider.

Step 2: Lower the TTLs Before You Need To

Every DNS record has a time to live: how long resolvers may cache it. If the website's A record has a TTL of 24 hours, some visitors keep going to the old server for up to a day after you change it. Lowering the TTL to five minutes or so shortens that tail, but only once the old value has expired everywhere, so the change has to be made at least one full old TTL before the move: a day or two ahead for most domains.

Nameserver changes are slower and less controllable. The delegation at the registry often carries a long TTL you cannot lower, so for a DNS provider move, plan for both providers answering correctly, with identical records, for a couple of days.

Step 3: Build and Test the New Server Privately

The new server gets the site, database and configuration while the old one keeps serving the public. We test it by pointing our own machines at the new address with a hosts file entry, so we see the real domain on the new server before anyone else does. Check forms, logins, payments in test mode, scheduled tasks, file uploads and anything that calls another service, because the outbound IP address changes with the host and some APIs only accept known addresses.

Step 4: Sort Out SSL Before the Switch

A certificate problem at cut-over looks like an outage: a full-page browser warning. The common trap is that free certificates are often issued by proving control of the website, which only works once DNS points at the new server. The options are to issue the certificate by DNS validation in advance, to copy the existing certificate across temporarily, or to issue it in the minutes after the switch while TTLs are short. Check that CAA records allow the certificate authority you are using, and confirm that automatic renewal works on the new server, not just the first issue.

Step 5: Protect Email Throughout

Email is the most expensive thing to break, because failures are silent. If you are only changing web servers, do not touch the MX records. If you are changing DNS providers, recreate MX, SPF, DKIM and DMARC exactly and compare them with the old provider using a lookup tool before changing nameservers. If the old host also provided mailboxes, that is a separate migration with its own plan, and not one for the same evening as the website.

The website's own mail can change too. If the site sent mail from the old server, the new server's address will not be in your SPF record. Our article on website emails landing in spam explains why routing site mail through an authenticated sending service avoids this, and our email deliverability team can set it up as part of the move.

Step 6: Cut Over in the Right Order

1. Pick a quiet hour, and tell whoever handles orders and enquiries.
2. For sites that take orders, bookings or comments, freeze changes on the old site, or put it into a short maintenance mode, so nothing is written there after the final copy.
3. Run a final sync of the database and uploaded files to the new server.
4. Change the A, AAAA or CNAME records, or the nameservers.
5. Test from several networks, including a phone off Wi-Fi, and watch the new server's logs.
6. Keep the old server running and watch its logs too. Traffic still arriving there shows how many visitors have the old address cached.

Step 7: Keep a Rollback Ready

Write down the old value of every record before changing it. With short TTLs, pointing back to the old server takes minutes, which is why the old server must stay untouched and running for at least a week. Rolling back after orders have been placed on the new server means copying those orders back, so decide in advance what would trigger a rollback and who makes the call. Once everything is stable, raise the TTLs again, confirm backups and monitoring run on the new server, and only then cancel the old hosting.

The Same Principle at Larger Scale

When a dental group consolidated nine practice websites from Wix and Squarespace into one WordPress site, the domains were switched only after every old URL had been crawled and 412 redirects had been tested. Nine platform subscriptions became one hosting arrangement, and Search Console was monitored after the switch to confirm the old addresses led to their new pages. The principle is the same as for a single site: test everything on the new home first, and make the switch itself the smallest possible step.

For moves into AWS, Azure or Google Cloud, our cloud migration checklist covers the infrastructure side. For anything else, tell us where the site is now and where it is going, and we will send back a cut-over plan with the record list and rollback steps before anything changes.