How to Migrate a WordPress Site to a New Server with Zero Downtime

Why Zero-Downtime Matters

A WordPress migration goes wrong the moment you point DNS at the new server before the new server is actually ready. Zero-downtime migration means the old server keeps serving traffic, unmodified, right up until the exact second the new server has been fully verified — visitors, search bots, and payment webhooks never see an error page or a half-synced site.

The technique that makes this possible is simple: copy files and database to the new server while the old one is still live, do a final delta sync to catch anything that changed in between, then flip DNS only after the new server has been tested under its real domain name using a local hosts-file override. The old server stays untouched as a fallback until you've confirmed the new one works.

Pre-Migration Checklist

Before touching either server, confirm four things: the new server has the same or higher PHP version, the target database character set matches (utf8mb4 on both sides — mismatches corrupt emoji and multi-byte content silently), you have working SSH key access to both servers, and you know the current DNS TTL for the domain so you can predict how long propagation will take.

Sync Files and Database

Use rsync for the file sync — it only transfers changed bytes on subsequent runs, which is what makes the final delta sync fast even on large media libraries. Run the first full sync days ahead of cutover, then re-run it right before you flip DNS:

For the database, export with --single-transaction so the dump is consistent even while the site keeps taking writes, then import on the new server and run wp search-replace to fix the domain and any absolute paths baked into serialized content:

CloudStick's Server Transfer feature automates this entire step for CloudStick-to-CloudStick moves — it handles the file sync, database export/import, and path rewriting from the dashboard, so you only need the manual rsync/mysqldump route above when migrating from or to a non-CloudStick server.

Cutover Without Downtime

Before touching DNS, test the new server under the real domain by editing your local /etc/hosts file to point example.com at the new server's IP, without changing anything for other visitors:

Browse the full site this way — check the homepage, a product or post page, the login screen, and any forms. Once it checks out, run the final rsync delta sync, update the A record at your DNS provider, and remove the hosts file override. With a 300-second TTL, most resolvers pick up the change within 5–15 minutes; the old server keeps answering correctly for stragglers the entire time because you never deleted anything from it.

Verify and Clean Up

Watch the new server's Nginx access log for a rising volume of real requests as DNS propagates — that's your confirmation traffic has shifted. Also check Search Console for crawl errors over the next 48 hours; if Googlebot hits a mix of old and new IPs during propagation, that's expected and resolves itself as the old DNS record fully expires everywhere.

See the CloudStick knowledge base: How to Migrate a WordPress Website Using Migrate Guru for a plugin-based alternative if you'd rather not run the manual rsync/mysqldump steps yourself. Keep the old server running for at least 72 hours after cutover before decommissioning it — that's your rollback path if anything surfaces post-migration that testing missed.