Images are AI-generated editorial illustrations, not documentary photographs or verified product screenshots.
Use a WordPress migration checklist before moving anything
A WordPress migration checklist should cover the whole working site, not just the visible pages. Inventory files, database content, media, plugins, licenses, scheduled tasks and external connections. Identify whether you are changing hosting, the domain name or both, because those changes have different consequences. Choose an approved maintenance window and keep a usable recovery copy independent of the destination host.
Inventory access and dependencies
Confirm who controls the domain registrar, DNS, hosting, certificates, email and third-party accounts. Record how forms, payment integrations, outbound email and automated jobs operate. Do not assume moving web hosting also moves email correctly. Keep credentials out of the checklist and use an approved secure access method. Confirm that the destination supports the relevant PHP, database and application requirements before copying production data.
Restore and test on the destination
Use an appropriate migration method and test the transferred site before sending visitors to it. WordPress provides guidance on changing hosting and domains; follow a method that handles database content correctly rather than applying an improvised blanket text replacement. Check media, links, navigation, permissions and representative pages. A successful file transfer is not proof that the database, integrations or scheduled tasks are working.
Plan writes and the actual cutover
Decide how new orders, form submissions and edits will be handled during the move. An old database copy can lose transactions created after the copy was made. Coordinate the final synchronization and DNS change with the host or developer, taking caching and propagation into account. Keep a rollback plan, but recognize that switching back also requires considering data written on the new site.
Verify the visitor-facing site and finish the handoff
Test the final domain and HTTPS behavior, then confirm the intended canonical URLs, redirects, email delivery and critical workflows. Review logs for migration-related failures and make sure backups now cover the destination. Keep the old environment only as long as the approved recovery plan requires. Document the final configuration and responsibilities so renewal, maintenance and recovery do not depend on a developer remembering every detail.
Common questions
Is a backup the same as a tested migration? No; verify restoration and the resulting workflows. Should a domain move be combined with a redesign? Combining changes can make failures harder to diagnose, so stage the work deliberately. Can the old hosting be canceled immediately? Confirm data, DNS, email and recovery needs before canceling anything.
Sources and further reading
learn.wordpress.org: migrating your wordpress website to a different host and domain
developer.wordpress.org: common errors
Related reading
How to Plan a Software Migration Without Losing Data
WordPress Backups: Files, Database and a Tested Restore Plan