How to Migrate WordPress to a New Host Without Losing Data

The safest way to migrate WordPress to a new host without losing data is to prepare the destination first, take an initial copy, apply a durable barrier or synchronize writes, run a final delta, test the new server against the real hostname, and change DNS only when you have a proven rollback path. Keep the old host online and observe both servers after the cutover. This workflow adds controls for orders, form submissions, registrations, and editorial changes to the baseline process in the official WordPress migration documentation.

“Without downtime” is a goal, not a universal guarantee. A mostly static publishing site can get very close. WooCommerce, Easy Digital Downloads, membership sites, and active communities need a brief read-only window, application-aware synchronization, or infrastructure that can replicate writes. The honest target is minimal downtime with no unaccounted-for writes, not a promise of zero seconds.

Choose the migration method before copying data

Ways to move WordPress to a new host

Use the simplest route that still lets you control writes and return safely. A plugin does not solve data consistency: an order placed after the database was packaged will not appear on the destination by itself. Likewise, a successful panel restore does not prove that the application works.

If the destination is not ready, start with how to choose web hosting and how to install WordPress on hosting or a VPS. Verify that the plan supports the site's size, traffic pattern, and required versions.

Inventory the site and set go/no-go criteria

Begin with an operational snapshot. Give every check an owner, and do not approve cutover while a critical fact is missing:

• Application: WordPress, PHP, and database versions; plugins, theme, mu-plugins, multisite, domain mapping, persistent object cache, and custom code.
• Capacity: file and database size, inode usage, temporary and free space, upload limits, memory, and execution time.
• Server: document root, owner, permissions, PHP extensions, Apache/Nginx rules, system cron jobs, queues, and supporting processes.
• Integrations: SMTP, payment gateway, inbound and outbound webhooks, forms, CRM, external storage, search, IP- or domain-bound licenses, and API allowlists.
• Network and names: the full DNS zone, A, AAAA, CNAME, MX, TXT, nameservers, authoritative provider, TTL, CDN/proxy, certificate, and DNSSEC/DS state.
• Changing data: orders, downloads, users, comments, sessions, bookings, leads, uploads, and any external system that writes back to WordPress.

This read-only inventory provides a reproducible baseline for a WP-CLI migration. Run it as the site owner rather than root, and replace the reserved sample values:

Export or capture settings that live outside WordPress, but keep secrets out of the runbook. Multisite, domain mapping, clusters, external databases, and high-write workloads require a dedicated procedure; this general workflow is not sufficient on its own.

Write the go/no-go rules before the window: enough free space, a restorable backup, compatible versions, a durable barrier rehearsed with an operator bypass, external rejection tests, independent monitoring, valid TLS, approved checkout and form tests, no unexplained errors, a DNS owner present, and time left to reverse the change. Set a deadline too: if a critical test is not fixed by the agreed time, postpone the cutover.

Build a restorable backup, not just an archive

A complete WordPress recovery needs both files and the database. The official WordPress backup guide treats them as separate data sets. Store backups outside the document root and, where possible, off the source server. A panel snapshot may add protection, but it does not replace a portable export and a restore test.

Set one unique, immutable UTC MIGRATION_ID for the entire run and never reuse a partial path. Before each export or tar, test ! -e prevents overwriting the only known-good copy. Also, wp db export exports every table in DB_NAME when --tables is omitted. This example obtains a CSV list with wp db tables --all-tables-with-prefix, displays it for review, and passes it quoted to --tables without word splitting:

If the source shares DB_NAME, the explicit list avoids exporting unrelated tables by default, but you must identify plugin tables that do not follow the prefix. Multisite, shared or custom tables, and domain mapping require a dedicated runbook that enumerates every dependency; do not broaden scope blindly.

Record the checksums, MIGRATION_ID, prefix, approved list, date, versions, and scope. The meaningful test is to restore the artifacts into an isolated environment, open the application, and log the result and recovery time. A zero exit status alone does not prove that a backup can be restored.

Prepare the destination and make the initial copy

Set up the destination virtual host, PHP, a dedicated database and user, TLS, ownership, scheduled tasks, and capacity. Reconcile required wp-config.php constants without pasting credentials into tickets. If PHP, the database, or the web server changes, test compatibility before combining that change with cutover.

Verify the destination SSH fingerprint through an independent channel—such as the provider console, a signed inventory, or an authorized owner—before accepting the first connection. Do not trust a fingerprint obtained over the same path you are trying to authenticate. If source and destination use Redis, Memcached, or another persistent cache, give the clone isolated credentials or a separate namespace before testing. Never flush while both sites share a namespace.

Keep destination cron, workers, webhooks, and inbound/outbound mail disabled until coordinated activation. Payment and message tests must use a sandbox or controlled recipients so the clone cannot process duplicate jobs before live traffic arrives.

WP-CLI, a document-root rsync, and the WordPress database dump do not migrate mailboxes, aliases, forwarders, or message history. If mail lives on the old host, use a parallel runbook: inventory and provision mailboxes/aliases/forwarders, synchronize messages with a service-supported method, validate SMTP, IMAP, and real delivery, and reproduce SPF, DKIM, DMARC, PTR, and allowlists where applicable. Do not change MX or shut down the old mail service until those tests pass. Execution is service-specific; there is no safe universal command.

The initial sync runs while the source remains live. Run it as the site owner over verified SSH; it deliberately does not include --delete:

Review the output and reconcile custom constants. Omitting --delete protects destination files, but it also preserves files removed at the source. Before go-live, compare both trees and delete only an approved list. If the team chooses rsync --delete, it needs a destination backup, identical exclusions, a reviewed --dry-run --itemize-changes, and an explicit gate before execution; the generic block does not perform it.

The initial wp db import flow keeps the same MIGRATION_ID, exports only the reviewed table list, and transfers the dump, manifest, and prefix. Before import, it compares $table_prefix using wp config get table_prefix --type=variable, displays every existing destination table, and requires the database to be dedicated, empty, or explicitly approved:

--add-drop-table only adds DROP TABLE for tables included in the dump; wp db import does not remove extras. The destination therefore needs a dedicated empty/approved database or a separately inventoried cleanup with its own backup and gate. Post-import checks require exactly the expected prefixed tables and validate home/siteurl. If transfer, backup, prefix, scope, import, or verification fails, DNS does not change.

Run search-replace only when a URL changes

If the final domain and protocol stay the same, you normally do not need a URL replacement. If you used a temporary hostname, wp search-replace understands serialized data; a blanket SQL REPLACE() does not. Skip guid, review a --dry-run, and create a new non-overwriting backup before applying changes:

Review plugin tables outside the prefix before extending scope. Do not replace strings you do not understand or accidentally rewrite email domains, keys, and third-party data.

Test the new server before changing DNS

curl --resolve maps the real hostname to a chosen IP while public DNS stays unchanged. --fail-with-body requires curl 7.76 or newer; on an older release use --fail and retain every other control. Never add -k: a TLS error is a cutover blocker.

For browser testing, you can add a temporary entry to your workstation's hosts file, but document and remove it afterward. On the destination, test:

• Home, content pages, search, redirects, 404 handling, and the dashboard.
• Sign-in and sign-out, roles, a controlled content update, and a disposable image upload.
• Forms, cart, sandbox checkout, tax, download, membership, or booking flows as applicable.
• Actual email receipt—not merely an “email sent” notice—plus inbound/outbound webhooks, cron, queues, and payment callbacks.
• HTTPS, mixed content, headers, page/object caching, CDN behavior, and purge controls.
• Private PHP, web, and database logs plus CPU, memory, disk, and inode use.

Compare URLs, canonical tags, robots directives, sitemap, structured data, analytics, and HTTP status codes with the source. Do not combine a no-URL-change hosting migration with a redesign or information-architecture change.

Control writes and apply the final delta

The initial copy is stale as soon as another order or upload arrives. Identify visitors, editors, WP-Cron, system cron, workers, queues, webhooks, importers, and APIs. Pause each writer reversibly and record how you will prove that it stopped changing data.

The standard .maintenance mode is not a durable barrier. WordPress core's wp_is_maintenance_mode() reads its timestamp and stops treating the standard mode as active after roughly ten minutes. WP-CLI can manage it as maintenance UX, but it must not protect orders or forms during a long migration.

Before the window, choose and rehearse a non-expiring write barrier that remains until explicitly removed at the edge/CDN, web server, application, or provider control layer. It must cover source and destination; reject checkout, forms, registrations, comments, wp-admin writes, and mutating REST/API calls; and allow operator access through an authenticated bypass or controlled allowlist. There is no safe universal command.

From an external network without the bypass, run negative tests and confirm that no route creates a record. Keep an independent monitor running during delta, export, import, and DNS. If a write stops being rejected or monitoring loses signal, abort, restore the barrier, account for changes since the last checkpoint, and repeat delta/import.

This block requires the barrier and paused writers, explicitly reconciles deleted files, and exports exactly the reviewed table list. Its MIGRATION_ID must match the rest of the run:

Transfer the dump and manifests. Compare SHA-256 before any import gate; compare prefixes, inventory every destination table, and require approval. Cache flush is authorized only after confirming an isolated namespace:

--add-drop-table does not remove extra tables; it only replaces included ones. Do not change DNS if checksum, new backup, prefix, table inventory, URLs, isolated cache, deletion reconciliation, or barrier monitoring fails. Repeat critical tests through the controlled bypass; the durable barrier still covers both servers.

Reduce DNS cutover risk

Lower the TTL before migration, then wait at least the previous TTL before relying on the lower value. Cloudflare's DNS migration preparation guidance describes this timing. A shorter TTL affects future cache entries; it does not erase cached answers or guarantee a single global switch instant.

If the authoritative DNS provider remains the same, you usually need to change A and, if published, AAAA. A stale AAAA can keep sending IPv6 visitors to the old host after A changes. A nameserver change is broader: reproduce the full zone—including MX, TXT, and validation records—and coordinate DNSSEC. A DS record at the registrar that does not match the new zone's keys can cause SERVFAIL. Review how DNS records and TTL work before changing delegation.

Cutover is go only when backups and rollback are available; the durable barrier covers source and destination and its monitor is healthy; every writer is paused; checksum and import passed; destination, TLS, and critical integrations are approved; A and AAAA are accounted for; TTL was prepared; DNSSEC and mail are inventoried; and the required owners are present. Change only the planned records, save the previous values, and record the time.

Repeat checks from more than one resolver and network. Your workstation's answer does not represent every visitor. Keep the barrier on both hosts while caches return mixed answers; a request reaching the source must not create a divergent data branch.

Activate destination processes exactly once

When DNS and observed traffic point to the destination, keep public writes closed. Using the stack's rehearsed runbook, activate exactly one instance of cron, workers, queue consumers, webhooks, and inbound/outbound mail on the destination. Verify the scheduler heartbeat, lock owner, consumption of a test queue item, one idempotent webhook, and controlled mail delivery; at the same time, confirm that these processes remain stopped on the source.

Only after that verification should you remove the destination barrier through the approved control, keep the source barrier in place, and run a traceable transactional canary. This block coordinates gates; it does not claim to know your provider, supervisor, or application commands:

Monitor the move and verify SEO

During the observation window, compare traffic and logs on both hosts, 5xx rate, latency, PHP errors, database connections, queues, cron, webhooks, email, orders, and form submissions. Keep an unambiguous way to identify which server replied, such as internal logs or a non-cached diagnostic header that reveals no sensitive data.

Google's guidance for moving to new hosting without URL changes recommends preparing and testing the new infrastructure, updating DNS, and monitoring traffic. Confirm that URLs retain their status codes, canonical tags, robots directives, and sitemap; remove any staging noindex; and verify that CDN caches are not serving errors. Do not use a change-of-address tool when the domain stays the same.

Once stable, compare performance and capacity with your baseline. If the site regresses, use a controlled checklist such as these checks for speeding up a slow WordPress site. Avoid enabling several optimizations during cutover, because that obscures both the cause of a failure and the rollback path.

Design rollback around post-cutover writes

Trigger rollback against agreed thresholds: broken checkout/sign-in, sustained 5xx responses, database corruption or connection failure, invalid TLS, unavailable critical integrations, or a data discrepancy that cannot be corrected before the deadline.

Always, even if you believe the destination received no writes, first apply or confirm its durable barrier and pause every destination writer before evaluating logs, capturing a delta, or reverting DNS. Keep the destination closed for clients holding cached DNS. If it accepted orders, registrations, or forms, capture and reconcile that delta with a tested process before restoring DNS; pointing back without reconciliation would lose data.

Collect timestamped evidence of the destination barrier, stopped writers, reviewed ID/log range, reconciliation, and restored DNS. SOURCE_DATA_SAFE is valid only after those artifacts exist and are reviewed. With the source barrier still active, validate its database and application through the bypass; reactivate exactly one instance of cron, workers, queues, webhooks, and inbound/outbound mail on the source; prove zero remain on the destination; and only then open the source. Keep the destination blocked until the incident closes.

Record who approved the return, reconciled data, evidence, canaries, and clients that may have reached either host. Preserve backups, logs, and the failed destination for analysis rather than overwriting evidence.

Troubleshoot common WordPress migration failures

Safe first checks after moving WordPress

Keep the old host until the observation window closes

Do not delete the source after the first successful response from the destination. Wait through an observation period based on the previous TTL, business cycle, and delayed integrations. Confirm that the source no longer receives useful traffic or callbacks, destination backups succeed, a restore is scheduled or proven, and application and SEO metrics remain stable.

Then revoke temporary access, remove workstation hosts entries, update allowlists and documentation, resume cron and workers in exactly one place, and restore the intended operating TTL through a controlled, verified change. Retain backups under policy. Decommission the source only with approval and evidence that it does not hold the sole copy of recent data.

Frequently asked questions

How long does a WordPress hosting migration take?

It depends on site size, transfer speed, testing, and the write window. The initial copy can run while the site is live; the sensitive period is the final delta, validation, and cutover. Measure it with a rehearsal instead of relying on a generic estimate.

Does a migration plugin prevent lost orders?

Not by itself. A package represents one point in time. You must block or synchronize later orders, compare the latest record identifiers, and test payments, callbacks, and email before opening the destination.

Do I need to change nameservers?

No if you keep the current authoritative DNS provider; changing A/AAAA is usually enough. Nameserver changes add risk because the full zone, mail records, and DNSSEC must move correctly.

Can I migrate multisite with this procedure?

Use it only as a framework. Multisite, subdomains, domain mapping, large networks, and custom tables need tailored inventory, replacements, and tests. Build a dedicated runbook.

A safe migration ends after cutover, not at it

Migrating WordPress without losing data is about controlling state, not merely copying folders. Choose the method, inventory every writer, test a restore, prepare the destination, perform an initial copy and a controlled final delta, validate by hostname, cut DNS, and observe. Keep the old host until the application, integrations, backups, and SEO are demonstrably healthy on the new one.