How to Move a WordPress Website to a New Host Without Losing Your Site

To move a WordPress website safely, create a verified backup, copy the files and database into the new environment, test the copy away from public traffic, plan the DNS change and keep a usable rollback route. Do not cancel the old hosting until the new site has been checked and DNS caches have had time to update.

No responsible process can promise that every migration has zero downtime. Good preparation can make disruption less likely and easier to recover from.

1. Inventory access and dependencies

Confirm access to the old hosting, WordPress administration, domain registrar and DNS service. Identify where email is hosted and list important forms, payment services, booking tools, analytics and integrations.

Check the site's WordPress, PHP, theme and plugin versions. An old site may fail on a newer server even when the copy itself succeeds.

2. Take a backup you can use

Save both website files and the database. Record relevant server settings, scheduled tasks, redirects and DNS records. If email is hosted in the same account, decide whether it is moving and back it up separately where appropriate.

Keep the backup somewhere other than the old server. A backup that can only be reached through the service you are leaving is a weak recovery plan.

3. Build and test the new copy

Import the files and database into the new environment. Update configuration values without overwriting working secrets unnecessarily. Use a temporary address, hosts-file entry or suitable staging method so the copy can be tested before public DNS changes.

Check:

representative pages and images;
navigation and important redirects;
contact, quote and booking forms;
login and administrative tasks;
payment journeys without placing a real order;
consent and analytics configuration;
browser console and server errors.

Avoid letting a temporary copy become indexed. Remove any temporary block when the live change is complete.

4. Plan DNS and email

DNS tells visitors where to find the site. Lowering the relevant record's TTL in advance may reduce how long some resolvers keep the old answer, but it does not control every cache.

Change only the records required. If you replace nameservers, recreate all necessary website, email and verification records. If you change a single web record, email may remain untouched, but still verify the zone first.

5. Prepare for the final change

Choose a quieter period if the website receives frequent updates or orders. Freeze content briefly, or plan how final changes will be synchronised. Take another database backup immediately before the cutover when recent data matters.

Point the domain to the new environment. Issue or verify the TLS certificate and test HTTPS, including redirects from the non-preferred hostname and HTTP.

6. Test from the outside

Test through normal public DNS, ideally from more than one network. Submit forms and verify that messages arrive. Check that email sending from the website is authenticated and that ordinary business mail still flows.

Review the most important pages on mobile and desktop. Look for mixed-content warnings, missing images, wrong canonical URLs and links that still use a temporary address.

7. Keep the rollback route

Do not delete the old account immediately. Keep it unchanged until the new environment has been stable for an agreed period. If the new site fails an essential acceptance test, a documented DNS rollback can return traffic while the cause is investigated.

After the move, update the asset inventory, store new recovery details securely and cancel the old service only when it is no longer needed. A good migration ends with clearer ownership than it started with.