How to migrate a WordPress site without downtime

Most WordPress migrations go wrong in one of two ways. Either the site is switched before the new server is genuinely ready, or content changes between taking the copy and pointing the domain — so orders, comments and posts made during the move quietly disappear.

Both are avoidable with sequencing. Nothing here requires a paid plugin.

Lower your DNS TTL first, days ahead

This is the step people skip, and it is the one that decides how long the risky window lasts.

Your domain's DNS records have a time-to-live telling resolvers how long to cache them. If it's set to 24 hours, some visitors will keep hitting your old server for a day after you switch.

Drop it to 300 seconds at least 24–48 hours before the migration, so the old long TTL has expired everywhere by the time you move. After the migration settles, put it back up.

Build the new site before touching the domain

Copy files and database to the new host and get the site fully working there while the live site carries on untouched.

To reach it before DNS changes, edit your local hosts file:

203.0.113.10   example.com www.example.com

Now your machine resolves the domain to the new server while everyone else still sees the old one. This is the single most useful trick in a migration: you can test the real domain, with real URLs, in place.

Work through the site properly at this stage — front page, a post, an archive, search, the admin, and any form or checkout. Finding a broken PHP extension now is a minor annoyance. Finding it after the switch is an outage.

Move the database without a search-and-replace disaster

If the domain isn't changing, the database moves as-is. If it is, URLs inside the database have to change too — and a plain SQL find-and-replace will corrupt serialised data, which is how sites lose widget and plugin settings.

Use a tool that understands serialisation:

wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables --dry-run

Run the dry run first, read what it reports, then run it for real. Take a database export immediately beforehand.

Sync again, immediately before the switch

This is what protects the content written while you were working.

Do a second, final sync right before you change DNS — the database, plus anything added to wp-content/uploads. For a busy site, put it in maintenance mode for the few minutes this takes, so nothing is written mid-copy.

For the uploads directory, rsync only moves what changed, so the second pass is fast:

rsync -avz --delete wp-content/uploads/ user@newhost:/path/wp-content/uploads/

Then switch DNS

Point the A record (or CNAME) at the new server. With a 300-second TTL, most visitors follow within minutes.

Leave the old server running for at least 48 hours. It costs one more month at worst, and it means anyone still resolving to the old address sees a working site rather than an error. Do not cancel the old hosting the same day, however tempting.

After the move

• Install the SSL certificate on the new host and confirm HTTPS works on both example.com and www.example.com.
• Check the redirect between www and non-www still behaves.
• Confirm email still sends. Site email often breaks in a migration because it silently depended on the old server's mail configuration.
• Put your DNS TTL back to something sensible.
• Watch the error log for a day.

Have a rollback plan

Before you change DNS, write down exactly how to undo it: the old IP address, where the pre-migration database export is, and who needs telling. A migration you can reverse in five minutes is a different kind of risk from one you cannot.

If the new site throws a database error on first load, that is usually credentials rather than anything you broke in the move — see error establishing a database connection.