WordPress Website Migration Checklist for Safe Cutovers

Direct answer: a safe WordPress website migration moves the complete site to a validated target, controls new data created during the move, switches traffic through a planned DNS or URL cutover, and keeps a tested rollback path until the new origin is stable. Inventory the source, preserve a matched files-and-database backup, rehearse the transfer, verify the final hostname and critical journeys, then monitor both origins before retiring the old one.

First classify the move. A hosting change that keeps every public URL has different search requirements from a domain or path change. A redesign, platform rebuild or major runtime upgrade adds another risk layer. Google recommends changing one major thing at a time where practical, so separate unrelated changes instead of making one failure impossible to diagnose.

Choose the migration type before writing the runbook

Write the source, target, owner, cutover window, acceptable outage, final-sync method, rollback trigger and decision authority at the top of the runbook. Define which system is authoritative for orders, users, form submissions, comments and editorial changes at every stage. Two writable production databases can diverge even when both appear healthy.

Build a source and dependency inventory

Record WordPress core, PHP and database versions; active and must-use plugins; the active theme and child theme; custom code; upload and object-storage locations; web-server rules; filesystem permissions; object/page cache; CDN; cron; certificates; outbound email; payment, CRM and webhook integrations; analytics; monitoring; backup destinations and Search Console verification.

Use Tools > Site Health > Info to export environment details, then supplement it with DNS and integration records that WordPress cannot see. Build a URL baseline from sitemaps, analytics, server logs and a crawl. Save representative status codes, canonicals, robots directives, page titles, structured data and media URLs so post-cutover differences can be investigated rather than guessed.

For WooCommerce, confirm the authoritative order datastore and every custom table. High-Performance Order Storage uses dedicated order tables; a transfer or validation process limited to posts and post meta can miss current commerce data. Inventory extensions that write outside standard WordPress tables.

Treat backup and rehearsal as prerequisites

A typical WordPress site needs both database and files for complete restoration. Keep the final pair under one timestamp or release identifier and store it away from the origin being replaced. The WordPress backup and restore testing guide owns backup-set completeness, recovery objectives and restore evidence; this migration checklist assumes that prerequisite has already passed.

Rehearse the transfer in a protected non-production environment, but do not repeat the entire staging process here. Use the WordPress staging workflow for copied-data protection, side-effect suppression and release-candidate testing. A hosts-file override or a provider preview that preserves the final hostname and HTTPS is useful for migration validation because temporary hostnames can hide cookie, redirect, licence and mixed-content defects.

Prepare a compatible target

Provision HTTPS, database access, PHP extensions, rewrites, scheduled jobs, caching and storage before copying production. WordPress currently recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, plus HTTPS support. Those are platform recommendations, not permission to combine a host move with an untested major upgrade. Confirm theme and plugin compatibility and document every intentional source-target difference.

Keep a publicly reachable temporary target out of search with access restrictions or noindex, then explicitly remove launch-only blocks during cutover. Do not copy production secrets blindly. Create target-specific database, API and deployment credentials, confirm least privilege, and know which credentials must be rotated after the old host is retired.

Transfer files, database and new writes safely

Copy WordPress files, uploads, custom directories and all required database tables. Update wp-config.php only for the target’s database, salts, paths and environment-specific settings. WordPress Tools > Export produces a content interchange file; it is not a complete site migration because it does not carry the full database, plugin configuration or every file.

Decide how to handle changes made after the initial copy. A low-write brochure site may use a short editorial freeze. A busy store or membership site may need a final database sync, selective table transfer or an application-aware reconciliation. Record the last source transaction and compare recent orders, users, leads and content immediately before and after cutover. Never overwrite newer production records with an older target copy.

Change WordPress URLs without corrupting data

If the public domain or path changes, update home, siteurl and stored references with a WordPress-aware method. WP-CLI’s search-replace handles serialized PHP data and supports --dry-run; its official examples use stable positional arguments and can skip the guid column. Run a scoped dry run, review the affected tables and counts, then execute the approved replacement. Do not use blind SQL replacement on serialized values and do not change WordPress GUIDs.

The WordPress migration handbook documents RELOCATE as a temporary recovery mechanism and warns that leaving it enabled can be insecure in some configurations. Remove it immediately after correcting the site address. Multisite requires separate planning for network tables, mapped domains, subdomain/path mode and rewrite rules; a single-site checklist is not sufficient.

Validate the target before traffic moves

Test with the final hostname wherever possible. Confirm that the target can serve uncached requests, WordPress REST endpoints, media variants and large downloads. Compare the target crawl with the source baseline, but do not treat matching counts alone as proof—sample recent and high-value records with content owners.

Plan DNS, CDN, TLS and dependent records

Inventory the registrar, authoritative DNS provider, CDN and current zone before changing anything. Preserve web records as well as MX, SPF, DKIM, DMARC, CAA, verification and service records that support email and third-party systems. If the plan benefits from faster rollback, lower the relevant TTL far enough in advance for existing caches to expire. Google’s hosting-move guidance gives a conservative example of lowering TTL about a week before the move; the correct value depends on the existing TTL, DNS provider and risk.

Issue and test certificates for every canonical and redirecting hostname. Confirm CDN origin, proxy mode, firewall rules and cache behaviour. DNS answers may remain cached, so a rollback is not instantaneous. Keep the old origin able to serve or redirect during the observation window, but prevent both origins from accepting independent writes.

Map URL changes and preserve search signals

For same-URL hosting moves, public paths, canonicals and sitemaps should normally remain unchanged. For domain, protocol, host or path changes, create an explicit old-to-new map from the source inventory. Use direct server-side permanent redirects to equivalent destinations, avoid chains and do not send unrelated missing pages to the homepage. Return a real 404 or 410 when no relevant replacement exists.

Update internal links, self-canonicals, hreflang, structured data and sitemaps to the new canonical URLs. Remove pre-launch noindex rules. The canonical, redirect and noindex guide retains the detailed control-selection intent, while the WordPress SEO launch checklist covers broader production indexability QA. If a redesign is part of the project, use the website redesign SEO checklist for content and URL-preservation decisions.

For a qualifying domain or subdomain move, verify old and new Search Console properties and use Google’s Change of Address tool. Google says the tool is not required for HTTP-to-HTTPS, same-domain www changes or path-only moves. Submit the new sitemap and expect processing time to vary; do not promise instant indexing or fixed ranking behaviour. Keep permanent redirects for at least one year, and longer where they still help users.

Execute a controlled cutover

1. Freeze conflicting deployments and, where required, source writes.
2. Create the final identified files-and-database backup and complete the approved delta sync.
3. Verify recent records and the target’s critical journeys privately.
4. Activate the redirect map when URLs change, then switch DNS, CDN origin or routing.
5. Check authoritative and multiple recursive DNS answers, TLS and a critical asset.
6. Run smoke tests as a logged-out visitor and an authorised administrator.
7. Inspect application, web-server, email, payment and integration logs.
8. Roll back if a predefined blocker is reached before the decision window closes.

A rollback plan must say what changes back, who decides and how writes created after cutover will be preserved. Rolling DNS back without reconciling new orders or leads can restore the old host while losing valid transactions.

Monitor both origins before retirement

Watch user and crawler traffic, error rates, form delivery, payment/webhook outcomes, cron, cache, media errors and search reporting. Google recommends monitoring both old and new hosting and retiring the old infrastructure only when users and Googlebot are consistently reaching the new one. Review old-origin logs for stragglers instead of assuming a DNS change reached everyone immediately.

When the observation and rollback period passes, revoke temporary credentials, update backup and monitoring ownership, restore an appropriate TTL, remove temporary access routes and archive the runbook evidence. For a URL-changing move, keep the redirecting old domain and certificates under active ownership. Retire the old origin through the provider’s approved process only after its remaining purpose is understood.

For implementation help, see PAKWM’s WordPress development service. To scope a host, server, domain or path move, request a quote with the source and target platforms, live-write volume, integrations and acceptable cutover window.

Sources

• WordPress Advanced Administration Handbook: Migrating WordPress
• WP-CLI Command Reference: wp search-replace
• WordPress Advanced Administration Handbook: Backups
• WordPress: Requirements
• WordPress Documentation: Site Health Screen
• WooCommerce Developer Documentation: High-Performance Order Storage
• Google Search Central: Changing Your Hosting
• Google Search Central: Site Moves with URL Changes
• Google Search Central: Redirects and Google Search
• Google Search Central: Canonical URL Guidance
• Cloudflare DNS Documentation: Time to Live