How to Migrate WordPress with Zero Downtime

A zero-downtime WordPress migration means users can continue completing valid requests throughout the move without losing or duplicating committed data. It is not simply a fast file copy or a low DNS TTL. The database, uploads, sessions, cache, scheduled jobs, email, and external callbacks must all agree on which environment owns each write.

Quick answer: Keep one authoritative write path until the new environment is ready. Pre-copy files, continuously or repeatedly synchronize mutable data, test the target under production-like traffic, and define an atomic cutover boundary. Stop duplicate workers, let database replication catch up or perform a final write freeze, switch traffic, then verify transactions and background work. If you cannot guarantee data consistency, use a short maintenance window and call it minimal downtime—not zero downtime.

Define what zero downtime means for this site

A marketing site and a WooCommerce store do not have the same availability contract. Decide which operations must remain available: page views, login, checkout, uploads, comments, API writes, scheduled publishing, or administrator changes. Then define the maximum acceptable error rate and whether a brief read-only interval is allowed.

Without this definition, a migration may claim zero downtime because the homepage remained cached while checkout, forms, or webhooks silently failed.

Start with a single-writer model

The safest migration has one authoritative database writer at any instant. Both old and new web nodes may serve compatible reads, but directing independent writes to two databases creates conflicts that WordPress cannot merge automatically. Auto-increment IDs, order state, stock, user metadata, options, and scheduled actions can diverge.

Active/active database writes require conflict semantics designed and tested for the application. Standard source-to-replica MySQL replication is not a multi-writer merge system.

Map every mutable state

• MySQL or MariaDB tables
• wp-content/uploads and generated media
• filesystem sessions or temporary files
• object cache and transients
• page cache and CDN cache
• cron, Action Scheduler, and custom workers
• email, payment, search, storage, and webhook queues
• configuration and secrets outside WordPress

A migration design that covers only files and SQL can still duplicate an email, lose an upload, or run the same payment callback twice.

Choose a data synchronization strategy

For modest sites, an initial copy followed by a very short write freeze and final incremental synchronization is often the lowest-risk approach. For stricter availability, database replication can reduce the final cutover interval, but it introduces version, network, privilege, binary-log, lag, and promotion requirements.

MySQL documents traditional source-to-replica replication as asynchronous: the source commits independently and replicas apply transactions later. Therefore, “replication is running” does not prove that the target has applied the latest transaction. Monitor lag and establish a confirmed catch-up point before promotion. See the official MySQL replication overview.

Replication is not a backup or an automatic cutover

Replication quickly copies accidental deletes and bad writes. Keep separate backups and a tested restore path. Promotion also requires an explicit sequence: stop or redirect writes, confirm the replica position, prevent the old source from accepting new writes, promote the target, and update application connectivity.

Do not improvise replication commands during a production move. MySQL and MariaDB versions, GTID configuration, managed-provider rules, and topology materially change the correct procedure.

Synchronize uploads without deleting valid files

Pre-copy the media library, then repeat an incremental sync near cutover. If uploads must remain available throughout, both environments need a shared object store, a replicated filesystem with defined consistency, or routing that sends every upload to the authoritative origin.

A bidirectional file sync is not automatically safe. Concurrent edits and deletions need conflict rules. Avoid destructive delete flags during an unverified migration and compare counts, sizes, and representative media after each pass.

Make sessions and authentication portable

WordPress authentication cookies depend on shared application secrets and consistent URLs. Plugins may also store sessions in files, database tables, or Redis. When traffic can reach both environments, confirm that each node reads the same required state and uses compatible salts, cookie settings, HTTPS headers, and cache namespaces.

Logging users out can be acceptable for some migrations, but silently losing a cart or checkout session is a business error. State the expected behavior before cutover.

Prevent duplicate cron and background work

WordPress uses loopback requests to start WP-Cron, as described in the official loopback documentation. If both environments can spawn due events, scheduled posts, email, imports, cleanup, or plugin jobs may run twice.

Choose one scheduler owner during migration. Disable or isolate workers on the passive environment, then switch ownership deliberately. For queues and payment callbacks, use idempotency and reconciliation rather than assuming a retry can never occur.

Warm cache without serving stale private state

Warm public pages and critical application paths on the destination, but do not copy opaque cache directories blindly. Cache keys may include hostnames, paths, salts, versions, or serialized objects. Object-cache namespaces must prevent the preview environment from contaminating production.

Checkout, account, admin, and API write routes should remain outside full-page cache. Verify cache exclusions after the traffic switch, not only before it.

Test with the final hostname and realistic dependencies

Use controlled host mapping, a load-balancer backend test, or a restricted preview that preserves the final hostname. Validate TLS, proxy headers, cookies, redirects, CORS, REST API, loopbacks, email, storage, and external APIs. Raw-IP testing misses several of these behaviors.

Replay only sanitized or synthetic traffic. A test must not create live orders, notify customers, or invoke production payment captures.

Use a traffic layer that supports controlled switching

A reverse proxy, CDN origin change, or load balancer usually provides a more controlled cutover than waiting only for recursive DNS caches. Health checks should measure a meaningful application response, and connection draining should allow in-flight requests to finish before removing the old backend.

DNS still matters for direct-origin architectures. The general WordPress hosting migration checklist covers TTL, IPv6, CDN origins, and observation of both servers.

Write a cutover runbook with explicit gates

1. Confirm backup, restore path, target health, and monitoring.
2. Verify file synchronization and replication health or final-copy readiness.
3. Stop administrative changes and isolate duplicate schedulers.
4. Establish the final write boundary.
5. Confirm database catch-up and final uploads.
6. Switch the application database endpoint and traffic layer.
7. Run synthetic and business acceptance checks.
8. Observe errors, lag, queues, orders, and both origins.

Each gate needs an owner, evidence, timeout, and rollback condition. “Looks fine” is not an acceptance criterion.

Verify business consistency after cutover

Check more than HTTP status. Reconcile order and payment counts around the cutover boundary, inspect failed and pending queues, verify the newest upload and account change, and compare the last source transaction with the target. For content sites, confirm scheduled posts and form submissions.

The server monitoring guide explains infrastructure and user-facing signals, but business counters remain application-specific.

Design rollback before accepting new writes

Before cutover, rollback may mean returning traffic to the old environment. After the target accepts writes, that action can discard or duplicate new data. Define a point after which fix-forward is safer, or maintain a tested reverse data path if the business truly requires rollback with no loss.

Do not promote the old source casually after the new source has diverged. Split-brain recovery is a data operation, not a DNS operation.

When a short maintenance window is the better design

Choose controlled maintenance when replication cannot be configured safely, uploads cannot be shared, third-party callbacks cannot be isolated, or the team cannot observe and reconcile the cutover. A planned five-minute write pause can be more reliable than an untested “zero-downtime” topology.

For a VPS-specific staged move, use the WordPress-to-VPS migration guide.

Common zero-downtime migration failures

• Equating a cached homepage with application availability
• Allowing both databases to accept independent writes
• Promoting a replica without proving it has caught up
• Running cron and workers in both environments
• Forgetting uploads, sessions, or external queues
• Using DNS TTL as the entire cutover strategy
• Planning server rollback without data reconciliation
• Skipping business-level verification

When should specialists design the migration?

A busy WooCommerce store, membership platform, large media library, multisite network, or strict availability objective requires coordinated application and data operations. The WordPress migration service can cover topology review, staged synchronization, controlled cutover, and verification.

Frequently asked questions

Does a low DNS TTL guarantee zero downtime?

No. It may shorten DNS caching, but it does not synchronize databases, uploads, sessions, or workers.

Can both WordPress sites write to the same database?

Only if network security, latency, compatibility, and failure behavior are deliberately designed and tested. It is not a universal migration shortcut.

Is MySQL replication synchronous?

Traditional source-to-replica replication is asynchronous by default. The target can lag, so catch-up must be measured before promotion.

Can WooCommerce be moved without maintenance mode?

Yes with an architecture that preserves orders, stock, sessions, uploads, and callbacks, but a short controlled write pause is often safer when those guarantees are unavailable.