A zero-downtime WordPress migration means visitors keep hitting the old server until DNS points at the new one, and you have already tested the copy. You cannot get a true zero by clicking “migrate” and hoping. You get it by copying files and the database first, testing on a hosts-file override, then switching DNS after a low TTL.
Zero-downtime migration checklist
| Step | What to do | Typical time |
|---|---|---|
| 1. Lower TTL | Set the A record TTL to 300 seconds, at least 24 hours before cutover | 5 minutes, then wait a day |
| 2. Inventory | Note PHP version, cron jobs, SSL, redirects, object cache, CDN | 30 minutes |
| 3. Full backup | Files + database on the old host. Keep a copy off that host | Depends on size |
| 4. Copy to new host | rsync or SFTP the files, import the SQL, match PHP | 1-3 hours |
| 5. Search-replace | If the test URL differs, use WP-CLI search-replace, never a text editor on the SQL dump | 10 minutes |
| 6. Test via hosts file | Point your PC at the new IP, click every form, login, checkout, search | 30-60 minutes |
| 7. Freeze writes | Put WooCommerce / comments / bookings into maintenance for the last sync | 15 minutes |
| 8. Final sync | Re-copy changed files and a fresh DB dump | 15-45 minutes |
| 9. Switch DNS | A record to the new IP. Issue SSL on the new host | 5 minutes + TTL wait |
| 10. Watch | Keep the old host 48-72 hours. Do not cancel it the same day | 2-3 days |

Tools, and their free limits
All-in-One WP Migration, Duplicator and Migrate Guru all work for small sites. Their free tiers cap archive size (All-in-One WP Migration’s free export limit is small, on the order of tens of MB; confirm the current number on the plugin page). For a site with years of media, use rsync or SFTP plus mysqldump, then WP-CLI:
wp search-replace ‘https://old.example’ ‘https://new.example’ –all-tables
Run it with –dry-run first. Then flush permalinks, disable a full-page cache plugin until you confirm the new host, and test wp-cron.
Mistakes that cause downtime anyway
- Leaving TTL at 24 hours, then changing the A record. Old resolvers keep the previous IP.
- Editing wp-config.php URLs by hand and breaking serialized PHP in the database.
- Forgetting to copy mu-plugins, .htaccess, nginx rules, or a real cron entry.
- Issuing SSL only after DNS, with no temporary cert on the new IP.
- Deleting the old host the same afternoon. You need it if TTL is still spreading.
After the move, run the WordPress SEO checklist and resubmit the sitemap in Search Console. Creator sites that also post video can use the YouTube formats guide. More how-tos are in Solutions.
How the hosts-file test actually works
On Windows, edit C:WindowsSystem32driversetchosts as Administrator and add a line with the new server IP and your live domain. Flush DNS, then open the site in a private window. You should see the copy on the new host while the rest of the internet still hits the old IP. Click login, search, a contact form, a random post, and checkout if you run WooCommerce. If permalinks 404, save permalinks twice on the new copy. If mixed content appears, you still have http URLs in the database and need another search-replace pass, not a theme edit.
Keep object cache, Redis and full-page cache off until that test is clean. A stale cache on the new host will show old pages and make you think the sync failed. Match PHP versions. A plugin that ran on PHP 8.1 can fatal on 8.3, which looks like downtime even before DNS moves. Copy mu-plugins, the real crontab, nginx or .htaccess rules, and the SSL private key plan. A Let’s Encrypt cert on the new IP can be issued with a temporary vhost before you switch the A record, so visitors who arrive early still get HTTPS.
Cutover day, in order
Freeze comments, orders and bookings. Take a fresh mysqldump and rsync the uploads folder. Import on the new host. Run WP-CLI search-replace with –dry-run, then for real, then flush permalinks. Switch the A record. Sit on the old host for 48-72 hours. If a resolver is still on the old IP, that copy should stay read-only, not deleted. After cutover, fetch the home page in Search Console and resubmit the sitemap so lastmod updates. Rankings usually hold when the domain, URL path and HTTPS stay the same. They slip when you change permalinks during the move, which this checklist does not do.
Sources
- WP-CLI search-replace command.
- WordPress documentation, Moving WordPress.
- All-in-One WP Migration plugin page (check current free size cap).
Can you migrate WordPress with zero downtime?
Yes, if you copy the site first, test it on the new IP with a hosts file, lower DNS TTL in advance, then switch the A record. There is still a short DNS spread, not a site-off outage.
Is a migration plugin enough?
For a small brochure site, yes. For a large media library or WooCommerce store, copy files with rsync and the database with mysqldump, then WP-CLI search-replace.
How long should I keep the old host?
At least 48-72 hours after DNS changes, longer if your TTL was high.
Will Google rankings drop?
Not if the domain, URLs and HTTPS stay the same. After cutover, fetch the home page in Search Console and watch the sitemap.


