Moving a WordPress site to a new host without downtime

The website part of a hosting move is rarely what goes wrong. Copying WordPress from one server to another is routine. What goes wrong is the email that stops arriving on Tuesday, the online order placed on the old server after the switch, or the old host being cancelled while it was still quietly running the mailboxes.

We move client sites between hosts regularly. This is the order we do it in, with the timing. Follow it and your customers shouldn’t notice a thing.

First, work out what the old host is doing for you

Before touching anything, write down everything the current host provides. It’s often more than the website.

• Website files and database. The obvious bit.
• Email. Are your mailboxes (you@yourbusiness.com.au) hosted there, or with Microsoft 365 or Google Workspace? This is the single most important question in the whole move.
• DNS. Is the host also managing your domain’s DNS records? If your domain’s nameservers point to the old host, every record (website, email, verification codes) lives there.
• Domain registration. Is the domain itself registered through them? If so, you’ll need to transfer it or at least keep control of it.
• SSL certificate. Usually free and automatic, but sometimes a paid certificate is involved.
• Anything else. Subdomains, a staging copy, scheduled backups, an old booking system on a subdomain someone set up in 2017.

Then log in to wherever your DNS is managed and take a screenshot or export of every record. Every A, CNAME, MX and TXT record. This list is your safety net. If something goes missing later, you’ll know what it was.

The order of operations

1. Set up the new hosting (day 1)

Create the hosting account and add your domain to it. Don’t change any DNS yet. The live site stays exactly where it is.

2. Copy the site across (day 1)

Copy the files and database to the new server. Many hosts offer a free migration service or plugin. Manual migration is also fine if you know what you’re doing.

If the site is a mess (old plugins, inactive themes, a media library full of unused images), this is a good moment to tidy it, ideally before the copy so you’re moving less. Cleaning up an old WordPress site explains what to look for.

3. Test the copy before anyone sees it (days 1 to 2)

You want to view the site on the new server while the world still sees the old one. There are two common ways:

• A temporary URL from your new host.
• Editing your computer’s hosts file so your browser alone goes to the new server for your domain. This is the more accurate test, because the site runs on its real address.

Then check: homepage, a few inner pages, menus, images, forms (send a real test enquiry), search, any shop or booking features, and the WordPress admin login. Check the PHP version on the new host matches or exceeds the old one, and that caching on the new host isn’t serving stale pages or breaking forms (see WordPress caching in plain English).

4. Lower the DNS TTL (at least 24 to 48 hours before the switch)

TTL (“time to live”) is how long internet providers are allowed to remember where your domain points before they check again. It’s often set to several hours or a full day. If you switch with a long TTL, some visitors keep going to the old server for that long.

At your DNS provider, lower the TTL on the records you’re about to change (usually the A record for the domain and the www record) to 300 seconds (5 minutes). Then wait at least as long as the old TTL before switching, so the shorter value has spread everywhere.

5. Freeze changes on the old site (switch day)

From this point, nobody should edit content on the old site. Anything added there after the copy will be lost.

If the site takes orders, bookings or form entries, either:

• Do a final fresh copy of the database just before switching, or
• Put the old site into maintenance mode for the switch (pick a quiet hour, like a Sunday evening), so nothing new lands on the old server.

6. Point the domain at the new server (switch day)

Change the A record (and www if needed) to the new server’s IP address. Or, if you’re moving DNS management to the new host too, change the nameservers at your domain registrar. Nameserver changes take longer to settle, and every record must be recreated at the new DNS provider first.

Use a propagation checker like whatsmydns.net to watch the change spread. With a 5 minute TTL most of the country follows within the hour.

7. Protect the email records (switch day, before and after)

This is the step that causes the most grief. If your email is with Microsoft 365, Google Workspace or another provider, the website move shouldn’t touch it, provided these records come across unchanged:

• MX records: where your email is delivered.
• SPF (a TXT record): which servers are allowed to send email as your domain.
• DKIM (TXT or CNAME records): signatures that prove your emails are genuine.
• DMARC (a TXT record starting _dmarc): tells receiving servers what to do with emails that fail the checks.
• Autodiscover and other CNAMEs for Microsoft 365.

If you change nameservers and forget to recreate one of these, email stops arriving or starts landing in spam. Compare the new DNS zone against your screenshot from the start, record by record.

If your mailboxes are hosted on the old server, moving them is a separate project. Either move them to the new host or, better, to a proper business email provider such as Microsoft 365 or Google Workspace, and copy the old mail across before the old account is closed.

One more thing: if your website sends emails (contact forms, order confirmations) and you use an SMTP service, add the new server to your SPF record if needed.

8. Check everything on the live site (switch day plus 1)

Once DNS has moved:

• Confirm the SSL certificate has issued and the padlock shows on every page.
• Submit every form and confirm the emails arrive.
• Place a test order if you have a shop, and check payment gateway webhooks still reach the site.
• Log in to WordPress and confirm you’re on the new server (most hosts show this in their dashboard, or check Tools > Site Health > Info > Server).
• Check Google Search Console for crawl errors over the following week.
• Send and receive a test email from your business address, to an outside account like Gmail.

9. Wait, then cancel the old hosting (switch day plus 14 to 30)

Keep the old hosting running for at least two weeks. Some visitors and email servers hang on to old DNS longer than they should, and you may discover something you didn’t know was there.

Before cancelling, download a final full backup from the old host and keep it somewhere safe. Then cancel, and check the cancellation doesn’t also cancel your domain registration if it was bundled.

Finally, put the TTL back up to a normal value (an hour or more).

The checklist for your notes

1. List everything the old host provides, especially email and DNS.
2. Screenshot every DNS record.
3. Set up new hosting, copy the site, test privately.
4. Lower TTL to 300 seconds, wait 24 to 48 hours.
5. Freeze the old site, do a final sync.
6. Switch the A record or nameservers.
7. Confirm MX, SPF, DKIM and DMARC are unchanged.
8. Test forms, checkout, SSL and email.
9. Keep the old host for two weeks, take a final backup, then cancel.

We do these moves for clients coming onto our managed hosting, and handle the DNS and email records as part of it. If you’re stuck on a host you can’t easily leave, our website ownership page explains how we get sites out of locked-in setups. Planning a move and not sure where your email records live? Start with a message naming your current host.