Move a WordPress website with a controlled cutover
A website move involves preparing the new environment, copying the site, testing it and switching traffic. Keep the old environment available until the new one is verified and the transition has been checked.
Careful planning can reduce interruption, but a no-downtime guarantee is not realistic for every site. A shop or booking system needs particular attention to new orders and other changes made during the move.
Gather access and define the scope
Identify who controls hosting, the domain and DNS. Prepare a current backup of the files and database, plus an inventory of important integrations and licences. Transfer credentials through an agreed secure route.
Decide whether email is moving. A website transfer does not automatically require a mailbox migration. If the existing email service stays, preserve its relevant DNS records. Use the email setup guide if mailboxes are part of the project.
Before selecting a destination, compare maintenance responsibilities as well as server capacity.
Build and test the destination
Copy the required files and database into a compatible environment. Use a protected preview or suitable hostname-testing method. Check configuration and URLs carefully, especially where a temporary address differs from the final domain.
The official WordPress migration documentation describes the moving process and the need to back up both files and database.
Test forms, login, media, scheduled tasks and external connections. For a shop, verify the purchase journey safely and avoid triggering real payments or duplicate notifications during testing. Prepare valid HTTPS for the final hostname.
Plan the final synchronisation
A copy made yesterday may be missing today's orders, comments or uploads. Decide how changes will be captured before the switch. Depending on the application, that can require a final synchronisation or a short agreed period in which writes are paused.
Record the rollback approach. A rollback after new orders reach the destination is more complex than simply pointing DNS back, because data may now exist in two places.
Change DNS deliberately
Review which records need changing and keep unrelated email and verification records intact. Lowering TTL in advance can help reduce caching delay once the previous TTL expires, but it cannot guarantee an instantaneous switch everywhere.
Keep both environments available while checking the transition. Our DNS guide explains why different clients can temporarily reach different addresses.
Do not close the old service solely because the homepage opens on your own laptop. Confirm where traffic and new data are arriving and agree when the old environment can be retired.
Verify after the move
Check HTTPS, important pages, forms and any ordering workflow on the live hostname. Confirm email delivery, backups, monitoring and scheduled jobs. Inspect redirects and indexing settings, especially any restrictions copied from staging.
Keep the original backup until the move has been accepted and the retention plan is clear. Remove unnecessary temporary access and update the operational documentation.
ResaHost website migration typically takes 1–3 working days, depending on access and scope. Agree the specific cutover and verification plan for your site.
After migration, keep WordPress maintenance active. A successful move should end with a clear update owner, tested recovery arrangements and one known route for support.