Migrating WordPress to new hosting with zero downtime

Moving a brochure site to a new host is a quiet afternoon. Moving a busy WooCommerce store or membership site that takes orders and sign-ups every minute is a different job. Done carelessly, it loses orders placed during the move, breaks payment webhooks, resets sessions, and occasionally leaves the site running on two servers with diverging databases. We move several high-traffic WordPress sites a month, and the process that makes them uneventful is mostly preparation.

Inventory before you move

Most migration problems come from something nobody knew the old server was doing. Before planning the move, we build an inventory:

• Server configuration: PHP version and extensions, memory limits, web server rewrite rules, redirects defined outside WordPress, and cron jobs at the system level.
• Integrations: payment gateway webhooks, ERP or CRM connections, IP allow-lists at third parties that include the old server's address, and outbound email configuration.
• DNS: every record on the domain, including email, verification records and subdomains that may point elsewhere.
• Scheduled work: WordPress cron events, background queues, import jobs and backups.
• Traffic patterns: the quietest hours for the site's audience, which determine the cutover window.

IP allow-lists catch teams out more than anything else. A payment provider or shipping integration that only accepts requests from the old server's address will fail silently after the move.

Rehearse on the new platform

We build the new environment from code where possible, then run a full rehearsal migration using a recent copy of production. The rehearsal is a real migration in every respect except DNS. We use it to:

1. Time each step, so the real cutover schedule is based on measurements rather than guesses.
2. Run automated checks against key pages, search, forms, login, cart and checkout using test payment modes.
3. Compare performance with the old host under simulated load.
4. Verify that scheduled tasks run once, not twice and not never.
5. Test backups and a restore on the new platform before relying on it.

We usually rehearse twice for commerce sites. The second rehearsal almost always finishes faster and surfaces one or two issues the first missed.

A migration you have rehearsed is an operation. A migration you have not rehearsed is an experiment on your customers.

Communication is part of the rehearsal too. We agree the cutover window with the client's customer service and marketing teams, pause scheduled email campaigns that would drive traffic during the move, and prepare a short status message in case anything takes longer than planned.

Keeping data in sync during cutover

The core challenge is that the old site keeps receiving orders, comments and sign-ups while you copy it. There are two practical approaches, and we choose based on the site:

• Short write freeze. For most sites, we put the old site into a brief maintenance mode for writes only, typically five to fifteen minutes during the quietest hour. Browsing continues, while checkout and forms show a short notice. We take a final database sync, switch traffic, and lift the freeze on the new host.
• Live replication. For sites where even a short freeze is unacceptable, we set up database replication from the old server to the new one, keep it running until cutover, then promote the new database and switch traffic in a single step.

Uploads are synced continuously in the days before the move, then a final incremental sync runs at cutover. Because only the changes since the last sync need copying, this takes seconds even on sites with hundreds of gigabytes of media.

DNS and the cutover itself

A few days before the move, we lower the TTL on the relevant DNS records to around five minutes, so the switch propagates quickly. Where the site sits behind a CDN or proxy, we switch the origin at the CDN instead, which is effectively instant and easy to reverse.

On the night, the runbook is a checklist with a named owner for each step:

1. Confirm the latest backup of the old site and verify it can be restored.
2. Start the write freeze or confirm replication lag is near zero.
3. Run the final database and file sync.
4. Switch the CDN origin or DNS records.
5. Update webhooks and IP allow-lists at third parties.
6. Run the automated check suite against the new host, including a real low-value test order where appropriate.
7. Lift the freeze and monitor error rates, response times and order volume.

The old server stays running, read-only, for at least a week. Rollback is a documented step, not an improvisation.

After the move

For the first 48 hours we watch closely: error logs, payment success rates, form submissions, email delivery, and search console crawl stats. We compare order volume with the same period in previous weeks to confirm nothing is silently failing. When the move includes a change of domain or URL structure, redirects and search engine signals need their own plan, which we treat as a separate SEO migration with its own checks.

A recent move of a WooCommerce store taking around 900 orders a day was completed with an eight-minute write freeze at 4 a.m. local time, no lost orders, and median server response 40% faster on the new platform.

Our WordPress migration team runs these moves end to end, alongside our broader server migrations practice. When URLs or domains change as part of the move, we add an SEO-safe migration plan to protect rankings.

Plan a move without surprises

Tell us where your site is hosted today, where you want it to go, and how much traffic and revenue flow through it. We will reply within 24 hours with a migration plan and a fixed price.