Moving a Website to a New Host Without Downtime

The four stages

Google's guide to changing your hosting splits a move into four stages: prepare the new hosting and test it; start the move by changing the DNS settings; monitor traffic on both old and new hosting; and shut down the old hosting "when you're confident that all users, including Googlebot, are receiving content correctly from the new infrastructure". The key idea is overlap. For a while both hosts run the site, so visitors are served whichever one their DNS points to, and nobody sees an error.

This guide covers a move where the domain and page addresses stay the same. If you are also changing domain or URLs, that is a site move with redirects; our guide to redesigning without losing search traffic covers that side.

Before you start: backups and an inventory

Take a full backup of the files and the database, and keep a copy somewhere that is not either host. Our guide to website backups explains what a complete backup includes.

Then write a short inventory of everything the old host does for you, because a move breaks whatever you forgot existed:

• the website files and database, and the software versions they run on (for example the PHP version);
• every DNS record, if the old host also runs your DNS: export the zone or screenshot it;
• email accounts and forwarders;
• scheduled tasks (cron jobs), such as sending reminders or clearing caches;
• redirects and server rules, subdomains, and any other sites on the same account;
• who has the logins for the domain registrar, the DNS and both hosts.

Our guides on domain names and DNS and web hosting explain how these pieces fit together.

Copy and test the site on the new host

Copy the files, import the database and set up the same software versions on the new server. Google's guide says what a copy means "depends entirely on your old content management platform": it may be plain HTML files or a database export to import.

Then test it before any visitor can reach it. Google suggests a testing environment, possibly restricted by IP address, or a temporary hostname such as beta.example.com, and adding a noindex rule so the test copy does not get indexed. You can also point only your own computer at the new server using your computer's hosts file. Check pages, images, forms, logins, downloads, checkout and any emails the site sends. Our website launch checklist works well as a test list.

If you verify Google Search Console with an HTML file or a meta tag, make sure the new copy still has it, as Google's guide reminds you.

Lower the DNS TTL a week ahead

DNS answers are cached for as long as each record's TTL (time to live) says. If your records have a long TTL, some visitors will keep reaching the old host for that long after you switch. Google recommends lowering the TTL "to a conservative low value (for example, a few hours) at least a week in advance of the move", so caches refresh quickly when the change comes.

Lower the TTL on the records you will change, usually the main address and www. After the move has settled, you can raise it again.

Do not forget email

Email is the part most often broken by a hosting move. If your mailboxes are hosted by the old provider, closing that account closes them too. Decide where email will live before you start:

• Email with a separate provider (such as Google Workspace or Microsoft 365): copy its MX and verification records exactly to any new DNS, and do not change them.
• Email moving to the new host: create the mailboxes there first, plan when to change the MX records, and move old messages across.

Either way, keep the SPF, DKIM and DMARC records, and update SPF if the server that sends your site's emails changes. Our guide to SPF, DKIM and DMARC explains these records.

HTTPS certificates

The new host needs a valid certificate for your domain from the first minute it receives traffic. Many hosts use Let's Encrypt, which checks that you control the domain before issuing one. Its documentation on challenge types explains that the common HTTP-01 check fetches a file from your web server, so it only succeeds once the domain points to the new server. The DNS-01 check uses a TXT record instead and can be done before the switch.

In practice: either have the certificate issued by DNS check before cutover, move an existing certificate across, or plan for a few minutes of certificate setup right after the DNS change, at a quiet time.

Cutover day

1. Pick a quiet time using your analytics, and avoid days with campaigns or deadlines.
2. Freeze changes on the old site. For a shop, booking system or membership site, new orders or sign-ups on the old server after the final copy would be lost, so briefly put the site into maintenance mode or stop accepting orders.
3. Take a final copy of the database (and any new uploads) and import it on the new host.
4. Remove test blocks. Google reminds you to remove any robots.txt disallow rules or noindex tags used during testing.
5. Update the DNS records to point to the new server.
6. Test again on the live address: pages, forms, checkout, logins, the certificate and the emails your site sends.

After the switch, and when to close the old host

Google advises watching the server logs on both hosts: traffic on the old one should fall while the new one rises. It also suggests checking that public DNS checking tools in different regions see the new records, and watching crawling in Search Console. Google notes it is normal to see "a temporary drop in Googlebot's crawl rate immediately after the launch", followed by a recovery over the next few days.

Keep the old hosting running until its logs show traffic has reached zero, as Google recommends, and until you have checked that nothing still depends on it: scheduled tasks, email, other sites, files you forgot. Download a final backup before you cancel.

Your rollback plan

Because the old host stays untouched until the end, rolling back is simple: point the DNS records back to the old server. With a low TTL, most visitors follow within the TTL period. Decide in advance what would make you roll back, such as checkout failing or errors you cannot fix within an hour, and who makes the call. If orders were placed on the new server before rolling back, note them so they can be copied across.

Frequently asked questions

Can I move my website to a new host without downtime?

Usually, yes. Copy and test the site on the new host while the old one keeps running, lower the DNS TTL in advance, then switch the DNS. Both hosts serve the site during the changeover, so visitors do not see an error.

How long does a DNS change take?

Visitors move over as cached DNS answers expire, which depends on the records' TTL. Google suggests lowering the TTL to a few hours at least a week before the move so the switch spreads faster.

Will moving host affect my Google rankings?

A hosting change that keeps the same URLs does not need redirects. Google notes a temporary drop in crawl rate right after the move is normal and usually recovers within a few days, as long as the new server works well.

What happens to my email when I change host?

If your mailboxes are with the old host, they stop when that account closes. Either keep email with a separate provider and copy its DNS records exactly, or set up mailboxes on the new host before changing the MX records.

When can I cancel the old hosting?

When its server logs show traffic has dropped to zero and you have confirmed nothing else depends on it, such as email, scheduled tasks or other sites. Take a final backup before cancelling.

Planning a move? Our website maintenance service covers updates and backups, and hosting on our managed server. See all our services, or email info@creahive.com.