Migrating WordPress Hosts with Zero Downtime

Host migrations go wrong for predictable reasons: DNS changes made before the new site is proven, databases exported hours before cutover so orders and comments vanish, and hard-coded URLs discovered in production. None of these are hard to avoid. The process below is the one we use for client moves, and it is designed so that at every step you can stop, check, and if necessary walk away with the old site untouched. The goal is not speed; it is reversibility, so that at no point does the plan depend on everything going right.

Preparation: buy yourself room to manoeuvre

Days before the move, drop the DNS TTL on the site's records to 300 seconds so the eventual switch propagates in minutes rather than hours. Audit what actually needs to move: the database, wp-content, and any custom configuration such as nginx rules, cron jobs and PHP settings that live outside the web root and are easy to forget. Confirm PHP and MySQL versions on the new host match or exceed the old ones, and check licence-keyed plugins will reactivate cleanly. Agree with the site owner what done means as well: a short written smoke-test list covering the journeys that matter commercially, so the cutover ends in a verdict rather than a feeling.

Copy everything while the old site stays live

Do the heavy lifting early, while there is no time pressure. Files first, then a database snapshot, both repeatable so you can re-sync the deltas later.

# Bulk copy of files; safe to re-run for deltas later
rsync -az --delete /var/www/site/ new-host:/var/www/site/

# Snapshot and load the database
wp db export /tmp/site.sql --path=/var/www/site
scp /tmp/site.sql new-host:/tmp/
ssh new-host 'wp db import /tmp/site.sql --path=/var/www/site'

Now test the new environment properly before any DNS changes, by pointing your own machine at it with a hosts-file entry for the domain. Click through the critical journeys: forms submit, search works, checkout completes if there is one, wp-admin loads, media displays. This is the step that catches the missing PHP extension or the object-cache drop-in referencing a Redis socket that does not exist yet.

Even when the domain is not changing, check the database and configuration for the old host's filesystem paths, and run a search-replace if any turn up. While you are in there, confirm cron fires on the new server and that outbound email actually delivers; those are the two things no amount of clicking through pages will reveal.

The cutover

Pick a quiet window. If the site takes orders or comments, put the old site briefly into maintenance mode or read-only so nothing is written during the final sync; on a content site that publishes rarely, a content freeze agreed with the team does the same job with no visitor impact. Re-run the rsync for changed files, take a fresh database export, import it on the new host, and flip DNS. With the lowered TTL, traffic moves over within minutes, and because both servers hold identical, working copies, visitors hitting either during propagation see the same site. Keep a terminal open on both servers throughout with the log tails running; most problems announce themselves there first.

After the switch, and the rollback you plan but do not use

• Watch the new server's access logs to confirm traffic arriving, and the error logs to confirm nothing else is.
• Re-issue TLS certificates on the new host before cutover, or use DNS validation so there is no certificate gap.
• Keep the old hosting live and untouched for at least a week; it is the rollback plan, one DNS change away.
• Only then raise TTLs back up and cancel the old account.

Treated as a checklist rather than an adventure, a migration is a quiet non-event, which is exactly what it should be. The first one run this way takes an afternoon of care; by the third it is simply routine. If you would rather hand the whole exercise to someone who does it routinely, STRCLI moves WordPress sites for clients without the drama.