Migration runbook

WordPress migration checklist

Move WordPress files and database, handle URLs safely, test the destination, plan the final sync, and verify the site after DNS cutover.

Format
Migrate · Intermediate
Published
Published
Updated
Updated
Reading time
3 min read
Guide Website Migration Migrate Intermediate WordPress migrationsweb-hostingdomains

Key takeaways

  • Back up files and database before changing either environment.
  • Use WordPress-aware tools for URL replacement so serialized data remains valid.
  • Plan what happens to new orders, uploads, and edits during cutover.

Before you begin

  • Administrative access to both WordPress environments
  • Database, file, and DNS access

WordPress keeps its life in two places at once — files on disk and rows in the database — and a migration only counts when both arrive intact. That includes uploads, plugins, themes, users, configuration, URLs, and the orders and comments that keep arriving while you’re mid-move.

Inventory the current site

Record WordPress, PHP, database, theme, and plugin versions. List must-use plugins, custom code, cron jobs, mail routing, caches, redirects, CDN, object storage, payment webhooks, and security controls.

Check disk use, database size, upload growth, and whether the site is a multisite installation. Multisite and domain-changing migrations require additional planning.

Create and verify a backup

Back up the database and full WordPress directory, especially wp-content and wp-config.php. Export server and redirect configuration. Keep the backup outside both hosts and confirm it can be opened or restored into an isolated environment.

Prepare the destination

Install compatible PHP and database versions and required extensions. Create the database and user with least required privileges. Configure storage, mail, cron, and HTTPS.

Do not expose the incomplete destination to search engines or customers.

Copy files and database

Transfer files while preserving ownership and permissions. Import the database and update database connection values in wp-config.php when needed.

If the public URL stays identical, leave the database URLs alone. If the domain or path changes, use WP-CLI or another WordPress-aware tool — WordPress stores some settings as serialized PHP, and a raw find-and-replace in SQL corrupts them silently, sometimes in ways that only surface weeks later:

wp search-replace 'https://old.example' 'https://new.example' --all-tables --dry-run

Review the dry run before executing. Keep an untouched database export.

Test privately

Use a hosts-file override or secure preview to test the real hostname against the new server. Check front-end pages, admin, login, permalinks, media, forms, search, email, payments, users, scheduled tasks, and plugin integrations.

Purge destination caches after changes. Confirm that test orders or notifications cannot affect real customers.

Plan final writes and cutover

Decide how to handle new orders, comments, registrations, uploads, and edits. For many sites, a short maintenance window plus final database and upload sync is safer than trying to merge two active sites.

Lower web-record TTLs ahead of time. At cutover, pause writes if required, perform the final sync, verify the destination, and change the traffic target.

Verify and retain rollback

Check DNS, certificate coverage, canonical URLs, redirects, admin access, transactions, email, cron, logs, and new database writes. Keep the old host intact and prevent accidental changes there.

Raise TTLs after stability, update monitoring and backups, and retire the old host only after the observation period.

Sources and further reading

Was this guide helpful?