A WordPress migration is the controlled transfer of files, database, configuration and connected services to a new environment. A copy that loads on the new host is not necessarily complete: email, DNS, scheduled tasks, redirects, licences, payments and live data must also be protected.
Define the migration type
| Change | Additional risk |
|---|---|
| Host only, same URLs | Server stack, DNS, cache, email and scheduled jobs |
| Domain or protocol change | Redirects, canonicals, internal URLs and external services |
| Redesign with new URLs | Content mapping, SEO signals and acceptance scope |
| Live store/member site | Orders, accounts and data created during cutover |
| Multisite or structural change | Shared tables, domains, users and network configuration |
Inventory the source
- WordPress, PHP and database versions
- Files, database size and custom code
- Active/inactive themes and plugins
- DNS, certificates, CDN and email routes
- Cron/scheduled jobs and background queues
- API keys, webhooks, payment and CRM integrations
- Redirects, security rules, backups and licences
Build and test the destination privately
Create a complete copy and test it without sending public traffic. Use a hosts-file or protected preview method where suitable. Prevent real email, payments and indexing. Check server requirements, file permissions, cache exclusions and scheduled jobs before cutover.
Handle URLs safely
Use WordPress-aware tools for database URL changes because serialized data can be damaged by blanket text replacement. When URLs change, create a one-to-one redirect map and preserve important paths. A WordPress content XML export is useful for portability but does not reproduce the entire installation.
Control live-data cutover
For changing sites, define a freeze, final synchronisation or transaction-reconciliation method. A full database restore from the first test copy can overwrite new orders and edits. Record the exact cutover time and the source of truth for each changing dataset.
Switch DNS and verify
- Create final backups at both ends.
- Apply the final data synchronisation.
- Confirm the destination directly.
- Change DNS or routing through the owned account.
- Check certificate, redirects, email, forms and integrations.
- Monitor both environments and logs during propagation.
- Keep the old service available for the agreed rollback window.
Close the migration properly
Revoke temporary credentials, update backup jobs and monitoring, transfer licences, remove private test copies and document the new environment. Do not cancel the old host until recovery, email and real business journeys have been verified.
Migration acceptance checklist
- Old and new URLs, redirects and canonicals behave as planned.
- DNS, certificates and email routes are correct.
- Forms, payments, bookings, webhooks and scheduled jobs work.
- Users, media, custom fields and recent transactional data are present.
- Backups and monitoring now point to the new environment.
- The business owns accounts, licences and documentation.
Keep a signed-off list of exceptions. An unresolved issue should not disappear merely because traffic has already been switched.
Practical next step
Create a migration inventory and cutover checklist before copying files. Mark every changing data source and decide how it will be preserved during the switch.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, plugins, hosting platforms and commercial terms change, so confirm the current documentation and licence details before making a material change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.