WordPress Operations

WordPress Migration Checklist: Move Hosts or Domains Without Guessing

Move a WordPress site as an application with data, URLs, DNS, certificates, jobs, mail, storage, integrations, monitoring, and rollback—not just files.

What this guide helps you do

Plan and verify a WordPress host or domain migration with controlled cutover and recovery.

A WordPress migration moves an interconnected service: database, files, URLs, DNS, TLS, mail, scheduled jobs, cache, storage, redirects, integrations, monitoring, and operational access. Build a cutover that can be verified and reversed before changing public traffic.

Inventory everything that makes the site work

Map domain and DNS control, hosting, database, uploads, custom files, configuration outside WordPress, certificates, email delivery, cron, object or CDN cache, external storage, search, payment, webhooks, analytics consent, backups, logs, and administrator access. Identify which values contain the old URL.

Prepare source and destination

  • Verified full backup plus an independent export
  • Compatible PHP, database, web server, limits, and extensions
  • Destination secrets, permissions, storage, mail, cron, and cache
  • Safe serialized-data-aware URL replacement method when needed
  • Lowered DNS TTL in advance when appropriate
  • Cutover owner, freeze window, rollback threshold, and communication plan

Choose the cutover pattern

PatternUseful whenMain concern
Clone then switch DNSHosts change, domain staysData written after clone
Domain changeURLs and identity changeRedirects, search, mail, integrations
In-place moveInfrastructure changes behind routingHidden configuration and rollback

Execute and verify the cutover

  1. Freeze or reconcile new writes.
  2. Copy and verify database and files.
  3. Apply configuration and URL changes safely.
  4. Test destination through controlled routing.
  5. Switch traffic and monitor DNS and certificates.
  6. Validate transactions, then retire source only after the rollback window.

Watch the edges of the migration

  • Forms or orders writing to both sites
  • Serialized data corrupted by naive replacement
  • Mail, cron, webhook, or payment callbacks still using old endpoints
  • Old site deleted before backups and DNS rollback are proven

Use a migration acceptance sheet

Check canonical URLs, redirects, assets, media, login, roles, search, forms, mail, transactions, scheduled jobs, webhooks, certificates, security headers, analytics or consent, logs, backups, and monitoring. Record the first successful real transaction and the date source cleanup becomes safe.

Continue with the next decision

Build a recoverable migration backup. A copy is not a recovery point until it can be restored.

Test the destination privately. Controlled routing reveals environment differences before public cutover.

Sources and further reading

Primary and contextual sources used to verify definitions or give readers a relevant next resource.

IE

Prepared and reviewed by

Infortified Editorial Team

Research-led guides with explicit scope, source checks where facts require them, and an independence review before publication.

Search Infortified

Find a practical answer

Start typing to search all guides.

Open full search