How to Migrate WordPress to a Faster Host Without Downtime

A WordPress migration feels like it should be a file copy. The outage usually comes from something else: DNS that still points at the old IP, a serialized URL that still says the old domain, email that lived on the old cPanel, or SSL that is not provisioned on the new vhost when you flip the record.

This is the sequence HostSignal uses as a checklist. It assumes you are moving the same domain to a faster host, not renaming the site.

0. Decide what “no downtime” means

You will not get a mathematically perfect zero. You can get no noticeable public outage: old site stays up until the new one answers HTTPS on the same hostname, and caches expire quickly.

Plan for a maintenance window anyway. WooCommerce and membership sites should pause orders or switch to a short “we’re moving checkout” state if you cannot accept a duplicate-order risk.

1. Inventory before you touch DNS

Write down:

• Current host, IP, and whether you are on Cloudflare or another proxy.
• PHP version, WordPress version, and must-have plugins.
• Where email lives. If mail.yourdomain.com is the old host, a DNS cut will break inboxes even if the website is fine.
• Cron jobs, redirect rules, and any object cache (Redis/Memcached).
• How large wp-content/uploads is. That is the transfer time.

Take a full backup you have downloaded, not only a host-dashboard backup.

2. Lower TTL at least a day early

If your DNS TTL is 21,600 or 86,400 seconds, a cutover will trickle for hours. Set A/AAAA (and the proxied equivalent) to 300 seconds a day before the move. After the move is healthy, raise it again.

If the domain uses a proxy (Cloudflare orange-cloud), you can often retarget the origin IP without waiting on the whole internet. That is the cleanest “no downtime” pattern we know. Do not pause the proxy unless you have a reason.

3. Provision the new host first

Create the site on the destination. Install a matching PHP version. Do not point the domain yet.

Preferred path: let the new host run its migrator (Kinsta includes unlimited migrations on published plans; Hostinger advertises free migrations; SiteGround and WP Engine have their own tools). Then still verify the clone yourself. Vendor migrators fail in boring ways — especially on custom tables and very large uploads.

Manual path:

1. Copy files (SFTP, rsync, or a migration plugin).
2. Export/import the database.
3. Run a serialized-safe search-replace from the temporary URL to the production domain or keep the production domain in the database and use a hosts-file test.

If you use a plugin such as All-in-One WP Migration or WP Migrate, watch the upload-size limit on the destination. That limit, not the plugin, is why “easy” moves stall at 87%.

4. Test on a hosts file or a temporary URL

Before DNS changes, you should be able to load the new stack as the production domain (via /etc/hosts) or as a temporary URL with the search-replace already done.

Check:

• Home, a long post, a paginated archive, and a form.
• wp-login.php and the customizer.
• HTTPS. A hosts-file test can use the destination certificate if you added the domain to the new account early; otherwise use the temp URL.
• Cron (DISABLE_WP_CRON reality) and scheduled posts.
• Search. Some hosts disable or throttle it.

If the new host forbids a plugin you rely on (often caching or related-posts clones), fix that now.

5. Freeze writes, then recopy

For a busy site, do a second database pass (and a delta of uploads) right before cutover so comments, orders, and form entries are not stuck on the old host.

WooCommerce: put the old checkout in a holding state, recopy, then cut. Two live checkouts are worse than two minutes of “please wait.”

6. Cut DNS, then watch the right things

Update the A/AAAA or the proxy origin. Purge CDN cache.

Watch:

• HTTP status on the apex and www.
• Mixed-content warnings (old http:// assets).
• The old host’s access logs going quiet — and the new host’s error log staying quiet.
• Email. If MX still points at Google or Fastmail, do not copy the old host’s MX. If email was on the old cPanel, move mail before or without touching MX, or accept that this is a second project.

Leave the old host paid through the money-back or next billing cycle until you have a week of clean backups on the new side.

7. Aftercare that prevents the “it got slow again” ticket

• Turn on the new host’s page cache. Turn off duplicate cache plugins.
• Reinstall object cache only if the new host supports it.
• Set up daily backups and a restore test.
• Reconnect cron, sitemaps, and any server-side cron ping.
• Raise DNS TTL once you trust the new IP.

When to pay for a concierge move

Pay the host (or a freelancer) if you have WooCommerce, multilingual plugins, a 10 GB+ uploads directory, or a host-specific mu-plugin you do not understand. The migration fee is cheaper than a weekend of serialized URL damage.

Kinsta’s published position is unlimited free migrations. Hostinger’s is free automatic migration. Those offers are real product features; they are not a promise that a pathological site will be instant. Read the qualifier on the plan you buy.

Placeholder affiliate links live in this post’s frontmatter. They do not change the checklist.