Define the cutover and rollback conditions
Assign an owner for the site copy, database synchronization, DNS change and business checks. List the flows that must keep working, including checkout, account access, forms and scheduled integrations. Record where DNS, email and certificates are managed so a website move does not accidentally change unrelated services.
Agree on what stops the cutover. A failed checkout, missing upload or certificate error needs a clear response. Before new writes reach the destination, rollback can be comparatively straightforward. Afterward, reverting traffic also requires preserving those writes. Keep that distinction in the runbook.
Lower DNS TTL before the migration window
TTL tells DNS resolvers how long they can cache a record. Lower the relevant web records to a short value supported by your DNS service, then wait for the previous TTL to expire before cutover. Lowering it at the moment of the switch cannot shorten records already cached elsewhere.
Review the apex domain, the preferred web hostname and any IPv6 records. Record their current values for recovery. Change only the records needed for the site move. Mail records and unrelated subdomains should follow their own requirements rather than being copied blindly.
Keep the old origin running throughout propagation. DNS changes do not move every visitor together, and a successful lookup from your laptop does not establish what every resolver returns.
Back up files and the database together
Create a full backup covering the WordPress database, uploads, themes, plugins and configuration needed to reconstruct the site. Store a recoverable copy outside the source hosting account. Check that the archive opens and that the database export is usable before proceeding.
For a busy site, make the export consistent with ongoing writes. Use an appropriate database snapshot or a coordinated copy process rather than assuming unrelated file and database exports represent the same state. Capture changes that happen after this baseline in the final synchronization.
Inventory runtime versions, extensions, rewrite rules, scheduled tasks and integrations. Include outgoing mail behavior and file permissions. The destination needs compatible application behavior, not simply the same visible pages.
Copy files and import the database
Provision the destination with compatible PHP and database settings, then copy the site files and import the database. Set the destination's connection details and required application configuration. Keep access limited while the copy is under review.
Prevent the test copy from sending live order emails, triggering payment callbacks or running duplicate scheduled work. Some external integrations need a testing mode or explicit suppression. Check which background jobs must remain active on the source until handover.
Verify uploads and less obvious dependencies such as redirect rules, custom file paths and scheduled imports. Compare database tables with the source inventory. A working homepage alone cannot establish that a site copy is complete.
Change stored URLs only when they actually change
If the public domain stays the same, the migration usually does not need a broad URL replacement. Testing through a hosts file can preserve the production hostname while directing your browser to the destination. This avoids introducing temporary addresses into stored content.
When URLs genuinely change, use a WordPress-aware search-replace tool that preserves serialized data. WP-CLI supports a dry run so you can inspect affected values before writing changes. Limit the operation to the intended tables and values, and retain the backup.
Avoid direct text replacement in a database export. Serialized values can break when string lengths change. Treat GUID values, redirect destinations and URLs used by external integrations deliberately rather than replacing every matching string without review.
Use a temporary URL or a hosts file
A temporary URL helps inspect the copy, but domain-sensitive plugins, cookies and redirects may behave differently there. A hosts-file override lets a tester use the real hostname against the new origin. It affects that tester's machine and does not switch public visitors.
HTTPS still needs a certificate valid for the hostname being tested. A hosts-file override does not bypass certificate verification. Arrange certificate validation before the public change where possible, then verify the full certificate chain and redirect behavior.
Check the site as a visitor and as an authorized operator. Protect the test environment from indexing and unauthorized access without blocking required verification. Record the outcome of each critical flow.
| Area | What to verify |
|---|---|
| Public pages | What to verifyNavigation, images, redirects and important content |
| Forms | What to verifyValidation, delivery and stored submissions |
| Accounts | What to verifyLogin, logout, password recovery and permissions |
| Store | What to verifyCart, checkout, order state and stock changes |
| Operations | What to verifyScheduled tasks, integrations and outgoing messages |
| Delivery | What to verifyHTTPS, canonical hostname, cache behavior and compression |
Freeze content edits or transfer the final changes
A quiet information site can freeze editorial changes while the final database and uploads copy completes. Keep the public site available, and tell editors when they can resume. Remember that forms, account activity and integrations may still write data even when nobody edits a page.
For an active site, identify every writer and synchronize the changes since the baseline. That can require another controlled copy, an application-aware delta process or database replication managed by a qualified operator. Do not merge databases by guessing which rows look newer.
Recheck files added after the initial copy. Uploads and database references need to agree. Confirm the destination contains the accepted final state before allowing it to receive new business data.
Keep one authoritative order system
WooCommerce orders, stock, payment callbacks and background tasks can change during the move. Exporting products is not enough. The migration process must preserve the complete relevant database state, including the site's order-storage configuration and integration records.
Avoid independent writes to both copies during DNS propagation. For uninterrupted ordering, use a tested handover that synchronizes accepted transactions and directs remaining old-origin write traffic to the authoritative destination. A correctly configured reverse proxy is one possible approach, but it requires testing of sessions, TLS, callbacks and cache behavior.
If the team cannot maintain a single writer with a verified synchronization method, the site is not ready for a continuous-checkout cutover. Resolve that constraint before switching DNS. A promise about page availability cannot substitute for preserving paid orders.
Ensure background jobs and outgoing order messages run from the intended environment after handover. The WooCommerce hosting page explains the NowHosted recovery features relevant to stores.
Switch only after the destination passes checks
Update the required web records to the destination. Check both the apex and preferred hostname, including any IPv6 route. Keep email and unrelated DNS records intact. Confirm resolution from independent locations rather than relying only on a local cached result.
Verify HTTPS immediately on the public hostname. Check certificate validity, redirect loops, canonical URLs and mixed content. If certificate issuance depends on public DNS, coordinate validation with the cutover instead of assuming it happens without a plan.
Confirm that private routes bypass public caching. Test login and checkout through the public path, then inspect order and form data on the authoritative environment. Keep source access available for investigation.
Watch behavior and keep the old host for 7 days
Monitor uptime, response errors, application logs and the business flows in the runbook. Check that forms arrive, orders appear once and scheduled integrations continue. Review the old environment for unexpected writes or traffic that still needs routing.
Keep the old host for 7 days after cutover, with its data and access preserved. Prevent obsolete jobs or independent writes from creating a competing source of truth. Before canceling, confirm the destination's backups work and remove temporary access used for the move.
If a problem requires rollback after new data arrives, reconcile that data before redirecting visitors back. A DNS reversal alone cannot move orders or submissions. Keep the migration record until the handover is accepted.