How to move a WordPress site to a new host, step by step

People expect this to be the scary bit. It usually isn’t. To move a WordPress site to a new host without your visitors noticing, which is a fair aim for a brochure site and a question of keeping the gap down to minutes for a busy shop, you copy the site across, get it working properly on the new server while the old one carries on serving the public, shorten your DNS time-to-live a day beforehand, point the domain at the new address, and then watch both machines for a fortnight.

That’s the whole method. Everything below is the detail that decides whether it goes smoothly or ruins a Thursday.

Why nothing has to go offline

The thing to understand is that for a while there are two working websites. The old server keeps answering until the domain stops pointing at it, and the new server is ready and tested before that happens. There is never a moment where the site does not exist somewhere.

Outages come from doing things in the wrong order: cancelling the old account on the day, or pointing the domain at a server before the site has been rebuilt on it. Handled properly the overlap is harmless. Handled badly, it is the reason somebody’s order landed on a server that was deleted on Friday.

TTL, in plain English

Every DNS record carries a time-to-live: a number of seconds telling the rest of the internet how long it may remember the answer before asking again. If your record has a TTL of four hours, internet providers all over the country are entitled to keep sending people to the old server for four hours after you change it.

So a day or two before the move, drop the TTL on the records you are changing to five minutes, and wait for the old longer value to expire everywhere. Now the real change reaches people in minutes rather than half a day. Put the TTL back up to something sensible a week later, once you have settled in.

There is a difference worth knowing between changing an A record and changing nameservers. Changing the A record moves the website and leaves everything else alone. Changing nameservers at the registrar hands the whole zone to a different provider, and your mail records go with it. That is how businesses lose email during what was supposed to be a website migration. If mail is staying put, either leave the nameservers where they are, or copy every MX, SPF, DKIM and verification record across first, character for character.

If your domain sits behind Cloudflare with the proxy switched on, the change happens inside Cloudflare and takes effect almost at once, because the wider internet still sees the same addresses. Handy, but it is instant and public the moment you save it.

The method, step by step

1. Take stock before you copy anything. PHP version, plugin list, how the site sends mail, any cron jobs, redirect rules living in .htaccess, the SSL certificate, and the size of the uploads folder. Surprises live in that list.
2. Copy the files and export the database. On a large site the files take far longer than the database, which is exactly why they get done first and separately.
3. Build the site on the new server and test it under the real domain name. The trick is a hosts file entry on your own computer, pointing your machine at the new server while every other visitor still sees the old one. Temporary preview URLs are a poor substitute, because half of WordPress notices the address has changed and behaves differently.
4. Sort the SSL certificate. Traffic arrives over HTTPS from the first second, so either pre-issue the certificate using DNS validation, or have the new host ready to issue it the instant the domain lands.
5. Lower the TTL, a day or two ahead.
6. Take a fresh copy of the database and any new uploads, minutes before the switch, and load it over the version you tested with. Tell whoever writes content to stop first, because anything published after that copy is going to vanish. This is the step people skip.
7. Change the record. Then go and look at the site on your phone, off the office wifi.
8. Leave the old hosting running for a couple of weeks. It costs one more month and it is the cheapest insurance you will ever buy.

The bits that catch people out

Cron running on both servers

For a day or so after the switch, both copies are alive and both may still be running scheduled tasks against their own database. Two servers sending your reminder emails, two servers publishing your scheduled posts. Turn the scheduler off on the old one as soon as the domain has moved.

URLs buried in the database

If the domain itself is changing, or you tested under a temporary address, the old address will be scattered through the database in page builder content and widget settings. A blunt find-and-replace on a SQL file corrupts any of it that PHP stored as serialised data, and the damage surfaces weeks later as a section of a page that has stopped rendering and nobody can say when. Use WP-CLI’s search-replace, which understands the format, or a migration plugin that does the same job.

Mailboxes are not files

Where email is moving too, copying the website does nothing for it. Mailboxes have to be synced across with their folders intact, and everybody’s phone and laptop needs reconfiguring afterwards. It is a separate job with its own timing, and worth reading up on email hosting before you tie the two together.

Things the old host was doing quietly

Server-level redirects, IP blocks, a firewall rule somebody added in 2021, a cron job set up in the control panel rather than in WordPress. None of that is in your file copy. When something works on the old site and not the new one, that gap is usually where it is hiding.

When a short interruption is the honest answer

A brochure site can move with nobody noticing, because nothing is being written to the database except the odd contact form entry. A site where customers write data all day is different. A busy shop, a membership site, a booking system: every minute between your final database copy and the domain switching is a minute where an order could land on the server you are about to abandon.

The way to handle it is to pick the quietest hour of your week, keep the gap down to minutes, and check the old server afterwards for anything that arrived late. We would rather say that than promise an invisible changeover nobody can guarantee. Shops have more moving parts on top, including payment gateways that need re-authorising, and there is more about those on our WooCommerce hosting page.

What to check once it has moved

• Submit your own contact form and confirm the message arrives from the new server, in an inbox rather than a spam folder.
• Read the server error log rather than the homepage. The homepage almost always works. Page 40 of the blog is where the broken thing lives.
• Make sure the test copy has not been left indexable, and that no noindex setting has travelled across from staging. Those two account for most of the ranking wobbles blamed on migrations, because the move itself does very little either way, as our piece on whether hosting affects SEO goes into.
• Log in as an ordinary customer or subscriber, not as an administrator. Admins see a different site.
• Time a couple of pages before you cancel the old account. If the new server has not made an obvious difference, the weight is in the pages rather than the machine, and the twenty-minute check in why is my WordPress site slow will show you where.

Moving a WordPress site FAQs

Or you can let us do it

Migration is free for hosting customers, and it is genuinely our job rather than a form you fill in. Sites arrive here one at a time, and sometimes as a whole agency client book at once. Your current hosting is left alone and running while we work, so there is a way back at every stage. You do not need to know what a TTL is to be our customer: send us the domain, tell us who has it now, and we will take it from there. Fully managed UK WordPress hosting starts at £1 a day + VAT.