Moving a website is a good opportunity to simplify its setup. It is also a moment when forgotten mailboxes, scheduled tasks and new orders can cause trouble. A useful migration plan covers the whole service, from the first backup to the moment you are comfortable closing the old account.
1. Make an inventory before copying anything
List the website files, databases, uploads, runtime versions and scheduled jobs. Include email accounts, aliases and DNS records. Note third-party dependencies such as payment notifications, transactional email and services that restrict access by IP address.
Record who can approve the move and who can change DNS. Make an independent backup before beginning work on the destination.
2. Check the destination against your application
A successful copy is not necessarily a working website. Confirm the required PHP version, extensions, database support and storage permissions. Applications with custom deployment processes need particular attention to file paths and environment configuration.
If a provider handles the website migration, agree on what is included. Website files, databases, mailboxes and final synchronisation may be separate tasks. A clear scope avoids discovering an omission on launch day.
3. Test a copy before changing public traffic
Use a staging address or an appropriate local hosts-file override to reach the destination. Check the site’s real workflows:
- Browse several page types, not only the homepage.
- Sign in and try the administration area.
- Submit a form and verify its delivery.
- Upload a file and confirm it is accessible.
- Test checkout using the payment provider’s supported test mode.
Prevent the test copy from sending real campaigns, processing live payments or being mistaken for the public site by search engines.
4. Decide how to handle changing data
A shop, forum or booking system continues receiving new information while the first copy is being made. Plan a final synchronisation or a short maintenance period so orders and posts do not end up split between two writable environments.
The same care applies when moving WordPress hosting: a database copied yesterday may not include today’s orders, edits or form submissions.
5. Switch, observe and retain a way back
Save the previous DNS values before changing the relevant records. Check the live site from outside your own network, verify email routing and watch application errors. Keep the old hosting available for an agreed period.
Define what would trigger a rollback. Changing DNS back is only part of recovery; you must also account for information created on the new site. Close the old account after the checks pass, backups work and the new setup is documented.