Map everything before copying
List the WordPress files, uploads, database, PHP extensions, scheduled jobs, cache, certificate and external integrations. Record the authoritative DNS provider and all existing records, especially MX, SPF, DKIM and DMARC. Moving web hosting does not automatically require moving email.
Take a verified backup and prepare a rollback plan that accounts for new orders, comments or other writes made after cutover. A simple DNS rollback may send visitors to an old database and lose those changes.
Prepare and test the destination
Copy files and database to an isolated destination. Use the supported site migration procedure for URLs and serialized data; a blind database string replacement can corrupt serialized values. Confirm file ownership, PHP compatibility, certificates, background jobs and the expected document root.
Test the destination using a controlled preview method that preserves the intended host and HTTPS behavior. Check uploaded images, login, forms, redirects, canonical URLs, cache behavior and any application integrations. Prevent test mail, payments and indexing on staging.
Cut over and validate
Agree a write freeze or synchronization plan, make the final data transfer and change only the intended DNS records. TTL changes are not instant for every resolver, and clients can reach old and new destinations during transition. Keep both environments secure while traffic drains.
Verify public DNS from multiple resolvers, HTTPS, a representative form and a controlled mail flow. Compare recent writes and logs, then release the freeze. Retain the old environment only for the agreed rollback period, with its scheduled jobs and outbound integrations prevented from duplicating production work.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.