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
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
Related guides
How to plan a website migration with rollback
Inventory dependencies, copy and test privately, control data changes, cut traffic deliberately, and preserve a proven rollback path.
How to plan a low-downtime DNS cutover
Prepare TTLs, test the new origin, control writes, change traffic, monitor both environments, and preserve rollback during a website move.
How to build a website backup and restore routine
Define backup scope, frequency, retention, isolation, encryption, monitoring, and restore tests around the website's recovery objectives.