How to Change WordPress Hosts With Zero Downtime

You can change WordPress hosts with zero downtime by building and testing the new server before anyone uses it, then switching traffic with a DNS change while the old server keeps running. Visitors who still reach the old server get a working site. Visitors who reach the new one get a working site too. Nobody sees an error page.

The steps below are the process we follow. Most of the work happens before the switch, which is why the switch itself is uneventful.

Why host changes usually cause downtime

Downtime during a host move almost always comes from doing things in the wrong order. Common examples:

• The DNS is changed first, and the site is copied after, so visitors hit an empty server.
• The old hosting plan is canceled on the same day as the switch.
• The DNS record has a long TTL, so some visitors reach the old server for a day or more, and that server is already gone.
• The new server is missing a PHP extension, so the site shows a fatal error after the switch.
• The SSL certificate is not ready, so browsers show a security warning.

Each of these is avoidable with planning.

Step 1: Lower the DNS TTL a week ahead

The TTL is the number of seconds that internet providers and browsers may cache your DNS records. If your TTL is 86,400 seconds (24 hours), a change can take up to a day to reach everyone.

Google’s guide to moving a site to new hosting recommends lowering the TTL at least a week before the move. We usually set it to 300 seconds (5 minutes) on the records we will change. Waiting a week matters because the old, long TTL has to expire from caches first.

While you are in the DNS settings, write down every record, not just the one that points to your web server. Email records (MX, SPF and DKIM), verification and subdomain records are easy to break if you move DNS providers at the same time. If you can, keep the DNS provider the same and change only the server address.

Step 2: Build the new server to match, or beat, the old one

Check the new environment before you copy anything:

• PHP version and extensions (such as imagick, intl, gd, mbstring and curl)
• PHP memory limit, upload size and execution time
• Database server version (MySQL or MariaDB)
• Web server rules, such as redirects in .htaccess or Nginx config
• Cron jobs and scheduled tasks
• Object cache (such as Redis) if the site uses one

The WordPress requirements page currently recommends PHP 8.3 or greater and MySQL 8.0 or greater, or MariaDB 10.11 or greater. A host move is a good chance to meet those, but resist upgrading PHP in the same step if the site has old plugins. Change one thing at a time. Our guide on how to upgrade the PHP version on WordPress covers that as a separate project.

Step 3: Copy the site and test it privately

Copy all files and export the database. For large sites, rsync for files and WP-CLI for the database are faster and more reliable than a plugin:

# On the old server
wp db export site.sql

# From the new server, copy files over SSH
rsync -avz olduser@old-server:/var/www/site/ /var/www/site/

Then test the new server before DNS points to it. The simplest way is to edit the hosts file on your own computer, which tells only your machine to use the new server’s IP address for your domain:

203.0.113.25  example.com www.example.com

Replace the example IP with your new server’s address. Now you can browse the real domain on the new server while every other visitor still uses the old one. Because the domain does not change, you do not need a search-replace in the database.

Test what matters most for your business: the homepage, key landing pages, forms, checkout, login, search, and anything that sends email. Check the PHP error log while you click around. Compare page speed with the old server. If you want a structured approach to this, our guide to safe WordPress updates with staging and tests uses the same kind of checks.

Step 4: Get SSL ready before the switch

A certificate from Let’s Encrypt is usually issued by proving you control the domain, which normally requires DNS to point to the new server already. To avoid a gap, use one of these options:

• Issue the certificate with a DNS challenge, which works before the switch.
• Copy the existing certificate and private key from the old server, if you have them.
• Use a CDN or proxy in front of the site, which handles the certificate at its edge.

Test with your hosts file entry that the site loads over HTTPS with no browser warning.

Step 5: Plan for content written during the switch

For a brochure site, you can simply avoid publishing for a day. For sites that take orders, bookings, form entries or comments, you need a plan, because some visitors will reach the old server for a while after the DNS change.

Choose one approach:

Whatever you choose, do a final database sync right before you change DNS. The test copy from step 3 may be days old.

Step 6: Switch DNS and watch both servers

Update the A record (and AAAA record for IPv6, if you have one) to the new server’s IP address. With a low TTL, most traffic moves within minutes.

Now watch both servers’ access logs. Traffic on the new server should climb while the old one drops. Google notes that you may see a short drop in Googlebot’s crawl rate right after the move, followed by a steady increase over the next few days. That is normal.

Also check:

• Google Search Console verification still works. If you verify with an HTML file, it must exist on the new server.
• Scheduled tasks run. WordPress cron, backups and any server-level cron jobs need to be set up on the new server.
• Outgoing email works. Many hosts block or limit mail sent directly from the server, so use an SMTP service.
• Old server cron jobs are disabled, so they do not send duplicate emails or run duplicate imports.

Step 7: Keep the old host for a few days

Do not cancel the old hosting until its access logs show no real visitors. Some internet providers ignore TTL values and cache records longer. Google’s own guidance is to shut down the old hosting only after traffic to it reaches zero. We keep it for at least a few days, and we take a final backup of the old server before it is shut down.

Once traffic has moved, raise the TTL back to a normal value, such as one hour.

After the move

Compare speed and error rates with your baseline from before the move. A new host should be at least as fast. If it is not, look at server configuration before blaming WordPress. Our article on WordPress server tuning for PHP-FPM, OPcache and Redis explains the settings that usually matter. If you are still choosing a new host, see our comparison of managed WordPress hosting vs a VPS.

If your URLs or domain also change, this is no longer a simple host move. Follow our WordPress migration SEO checklist as well.

Want someone else to handle the switch?

We move WordPress sites between hosts regularly, including busy stores and membership sites where every order counts. We build the new server, test it privately, and stay on watch during the switch. See our WordPress migration service or contact us to plan your move.

Frequently asked questions

Will my WordPress site go down when I change hosts?

It does not have to. If you build and test the new server first, lower your DNS TTL in advance, and keep the old server running during the switch, visitors reach a working site the whole time.

How long does DNS propagation take?

It depends on the TTL of your DNS records. If you lower the TTL to a few minutes a week before the move, most visitors switch to the new server within minutes of the change. Some resolvers ignore TTL, so keep the old server running for a few days.

Do I need to tell Google when I change hosts?

No. If your URLs stay the same, you do not use the Change of Address tool. Google recommends keeping your Search Console verification in place and watching crawl stats after the move.

What happens to orders or form entries during the switch?

During the DNS switch, some visitors may still reach the old server. On a site that takes orders or entries, freeze changes for a short window or sync new records from the old server after the switch so nothing is lost.