Moving a Website to a New Host Without Downtime

Moving a website to a new host sounds risky to most business owners, and they're right to be careful. I've seen sites go offline for two days, contact forms that quietly stopped sending, and email that vanished because someone changed the nameservers without checking what else lived there. None of that is caused by the move itself. It comes from doing the steps in the wrong order.

I move sites between hosts fairly often, usually because the old hosting is slow, expensive at renewal, or managed by someone the owner can no longer reach. This is the order I follow so visitors never see a broken site and nothing gets lost on the way.

First, find out what you're actually moving

A website is rarely just a folder of files. Before I touch anything, I make a list of every piece that depends on the current hosting:

• The files. The site code, uploaded images, PDFs and anything stored outside the main folder, like config files.
• The database. Most PHP and WordPress sites have at least one MySQL database, sometimes more than one.
• Email. If the business email runs on the same hosting, it needs its own plan. This is the part that causes the most trouble.
• DNS records. Verification records for Google, records for an email service, subdomains, anything added over the years.
• Scheduled tasks and settings. Cron jobs, the PHP version, upload limits, redirects in .htaccess and any SSL setup.

I also ask who has access to the domain registrar, because that's often a different company from the host. If nobody knows the registrar login, I sort that out before planning anything else.

Take a full backup you can actually restore

I download a complete copy of the files and a fresh export of every database, and I keep them on my own machine, not only on the old server. A backup that sits on the server you're about to cancel isn't much of a backup.

I also check the export opens and looks complete. A database dump that stops halfway because of a timeout is easy to miss until you need it.

Lower the DNS TTL a day or two before

TTL is the number that tells other servers how long to remember where your domain points. If it's set to a day, some visitors may keep reaching the old server for up to a day after you switch. A couple of days before the move, I lower the TTL on the main records to something short, like five minutes. Then the actual switch spreads quickly, and if something goes wrong I can point it back just as quickly.

Set the site up on the new host and test it there

This is the step that removes most of the risk. I upload the files, import the database, set up the same PHP version and settings, and get the whole site working on the new server while the old one is still live. Visitors don't see any of this yet.

Testing before the domain points there

There are two simple ways to look at the new copy before switching DNS. Many hosts give you a temporary address for the site. The other way is editing the hosts file on my own computer so that only my machine sees the domain on the new server. That second one is better, because the site runs on its real domain name, so links, logins and SSL behave the way they will after the switch.

Then I click through it properly, the same way I would before a launch:

• Every main page loads with its images and layout intact, on desktop and on a phone.
• Forms send, the email arrives in the owner's inbox, and the enquiry is saved if the site stores them.
• The admin login works and I can save a change.
• No database connection errors, missing uploads or pages that still point at the old server's paths.

Freeze content changes during the move

If the owner edits a page or a customer places an order on the old server after I've copied the database, that change won't exist on the new one. For most small business sites I just ask the owner not to edit anything for a day. For sites with orders or bookings, I pick a quiet time, take a final database export right before the switch and import it again.

Plan the email separately

Changing nameservers is the most common way business email breaks during a move. When the nameservers change, every DNS record moves with them, including the MX records that tell the world where the email goes. If those records aren't copied across first, the mail goes nowhere.

If the email runs on Google Workspace or Microsoft 365, I copy their MX, SPF, DKIM and verification records to the new DNS exactly as they are. If the email lives on the old hosting itself, I either set up the same mailboxes on the new host and move the old messages, or I suggest moving email to a proper email service while we're at it. Either way, it's decided before the switch, not after.

Often the simplest option is not to change nameservers at all. If the domain's DNS is managed somewhere sensible, I only change the main A record to the new server and leave everything else alone.

Make the switch

With the new copy tested and the TTL already low, the switch itself is small. I update the A record (or the nameservers, if that's the plan), then:

• Set up the SSL certificate on the new host as soon as the domain points there, and check that HTTPS works without warnings.
• Check the site from my phone on mobile data, which won't have my hosts file changes.
• Send a test through every form again.
• Look at the server error log for anything new.

Because the old server still has a working copy, anyone whose network hasn't picked up the change yet still sees a normal site. That overlap is the whole reason there's no downtime.

Don't cancel the old hosting straight away

I keep the old hosting running for at least a week after the switch. It's the fallback if something turns up that we missed, like a file that wasn't copied or a scheduled task nobody knew about. During that week I keep an eye on a few things:

• Search Console, to make sure Google isn't reporting new errors.
• The form inbox, to confirm real enquiries are still arriving.
• Any backups or cron jobs that should now run on the new server.

Once everything has been quiet for a week, I take one last backup from the old server and only then does the owner cancel it.

Mistakes I see most often

• Cancelling the old hosting first and then trying to move the site from a backup that turns out to be incomplete.
• Switching nameservers without copying the email and verification records.
• Moving to a server with a different PHP version and finding out from a blank page.
• Forgetting that hardcoded links or image paths still point at the old server.
• Doing the move on a busy weekday morning instead of a quiet time.

Is it worth moving at all?

Sometimes the honest answer is no. If the site is slow because of heavy images or too many plugins, a new host won't fix that on its own. But if the server itself is slow, the renewal price has jumped, or nobody can get into the account anymore, a careful move is usually a calm, one or two day job. If you're planning one and want a second pair of eyes on the steps, you can reach me through my contact page.