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

Why nothing has to go offline

People expect this to be the scary bit. It usually is not. To move a WordPress site to a new host you copy the site across, get it working 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 watch both machines for a fortnight.

For a while there are two working websites. The old server keeps answering until the domain stops pointing at it, and the new one is ready and tested before that happens. 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.

TTL and DNS in plain English

Every DNS record carries a time-to-live: how many seconds the rest of the internet may remember the answer before asking again. With a four-hour TTL, providers can 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 let the old value expire. Put it back up a week after you have settled.

Changing an A record moves the website and leaves everything else alone. Changing nameservers hands the whole zone to a different provider, mail records included, which is how businesses lose email during what was meant to be a website move. If mail is staying put, leave the nameservers alone, or copy every MX, SPF, DKIM and verification record across first, character for character. If the domain is behind Cloudflare with the proxy on, the change takes effect almost at once when you save it.

Our sister site has the detail on pointing a domain at a new host and how Cloudflare DNS works.

The method, step by step

1. Take stock before copying anything: PHP version, plugin list, how the site sends mail, cron jobs, redirect rules in .htaccess, the SSL certificate and the size of the uploads folder.
2. Copy the files and export the database. On a large site the files take far longer, so do them first and separately.
3. Build and test on the new server under the real domain, using a hosts file entry on your own computer. Temporary preview URLs are a poor substitute, because WordPress notices the address has changed and behaves differently.
4. Sort the SSL certificate, either issued in advance using DNS validation or ready to issue the instant the domain lands.
5. Lower the TTL a day or two ahead.
6. Take a fresh copy of the database and new uploads minutes before the switch. Tell whoever writes content to stop first, or anything published after that copy vanishes. This is the step people skip.
7. Change the record, then look at the site on your phone, off the office wifi.
8. Leave the old hosting running for a couple of weeks. One more month is the cheapest insurance you will ever buy.

The bits that catch people out

Cron running on both servers

For a day or so both copies are alive and both may run scheduled tasks against their own database: two servers sending reminder emails, two publishing 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 is changing, the old address is scattered through page builder content and widget settings. A blunt find-and-replace on the SQL file corrupts anything PHP stored as serialised data, and the damage shows up weeks later as a section that has stopped rendering. Use WP-CLI's search-replace, or a migration plugin that understands the format.

Mailboxes are not files

Copying the website does nothing for email. Mailboxes are synced separately with folders intact, and phones need reconfiguring. Treat it as its own job; our sister site covers email hosting.

Things the old host did quietly

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

Busy sites, and what to check afterwards

A brochure site can move with nobody noticing, because almost nothing is written to the database. A busy shop, membership site or booking system is different: every minute between your final database copy and the switch is a minute an order could land on the server you are leaving. Pick the quietest hour of the week, keep the gap to minutes, and check the old server afterwards for anything that arrived late. Shops also have payment gateways that may need re-authorising; see our WooCommerce hosting page.

• Submit your own contact form and confirm the message arrives in an inbox, not spam.
• Read the server error log rather than the homepage. Page 40 of the blog is where the broken thing lives.
• Make sure the test copy was not left indexable and no noindex setting travelled to the live site. Those cause most ranking wobbles blamed on migrations, as our piece on whether hosting affects SEO explains.
• Log in as an ordinary customer, not an administrator. Admins see a different site.
• Time a few pages before you cancel the old account. If nothing improved, the weight is in the pages; see why is my WordPress site slow.

Or let us do it

Migration is free for hosting customers (moving more than 5 email accounts may be charged), and it is our job rather than a form you fill in. Sites arrive one at a time, and sometimes as a whole agency client book at once. Your current hosting is left running while we work, so there is a way back at every stage. When we move a shop, we plan the cut-over so it stays open and no orders are lost.

You do not need to know what a TTL is: send us the domain, tell us who has it now, and we take it from there. Managed WordPress hosting with dijihost Complete Hosting is £1 a day + VAT, including daily backups kept for 14 days, free SSL and Cloudflare DNS. Order online or call 01623 650333.

Related