How to Move WordPress Site to a New Host

The risky moment in “how to move WordPress site to a new host” is not usually copying files. It is switching public traffic before the database, email, redirects, SSL and recovery route have been checked on the destination.

For a UK website owner, continuity matters because the site must stay available, load quickly and remain straightforward to manage. Inventory clear pages, dependable forms, secure administration and recoverable content, then test WordPress against managed updates, page caching, staging, security monitoring and restores on the new host before changing public DNS. Keep an independent export and retain the previous account until website and mail checks pass.

Treat the move as a controlled release

A hosting move is safest when the old service remains live until the replacement has been tested. Begin with a full copy of site files, database, DNS records, SSL details and mailboxes. Record any scheduled jobs, redirects, third-party integrations and domain contacts that could be forgotten. Build or import the site on the new host, then inspect it through a temporary address or local hosts-file entry. For WordPress, test managed updates, page caching, staging, security monitoring and restores; also submit forms, log in, search the site and complete a low-risk transaction where relevant. Reduce DNS time-to-live before the change when possible, schedule the switch outside the busiest period and freeze content briefly if two databases could diverge. Keep the old account and independent backup until DNS has settled, email is flowing and analytics show normal behaviour. Only then cancel the previous package. A measured overlap costs less than trying to reconstruct a missing order, enquiry or mailbox.

How this requirement changes the shortlist

The named platform narrows compatibility requirements. WordPress creates themes, plugins, scheduled tasks and database-driven pages, so confirm managed updates, page caching, staging, security monitoring and restores. Also check supported versions and the process for logs, staging and rollback. A generic one-click installer is not the same as ongoing platform-aware support once themes, extensions or custom code are in use.

For a UK website owner, the decision should support one clear outcome: the site must stay available, load quickly and remain straightforward to manage. Use WordPress as the technical baseline, then compare the same term, backup standard and support scope across every candidate. A provider that cannot answer a specific compatibility question before purchase is unlikely to become clearer afterwards.

Restore-time test: Decide how long the site could be unavailable and how much new data could be lost. Those two limits determine whether daily backups and ordinary support are enough. Test this once during the initial refund window and record the result.

Six checks before switching traffic

A controlled four-step migration

1. 1

   Inventory everything

   List files, databases, mailboxes, DNS, redirects, cron jobs, certificates, integrations and domain contacts. Note which supplier currently controls each item.

2. 2

   Back up and build

   Create an independent export, then import WordPress to the destination. Keep the old site live and prevent search engines indexing a temporary copy.

3. 3

   Test before DNS

   Check clear pages, dependable forms, secure administration and recoverable content, forms, logins, email and analytics through a preview route. Compare important URLs and redirects so existing search visibility is not discarded.

4. 4

   Switch, observe, retain

   Change DNS during a quiet period, monitor both systems and keep the previous account through the propagation and verification window. Cancel only after recovery is proven.

What a safe migration setup looks like

Keep the domain under an account you control, lower DNS time-to-live in advance where practical and write the rollback values down. The old service is a recovery tool until external checks show the new one is complete.

Common mistakes to avoid

• Cancelling the old host as soon as files are copied, before DNS, email, forms, redirects and live transactions have been verified.
• Letting the hosting company or a web designer own the domain account, which can make a later move unnecessarily difficult.
• Treating a backup as proven recovery without downloading a copy or completing a test restore.
• Changing DNS, nameservers, plugins and server settings together, then being unable to identify which change caused the result.

Bottom line

Cancel only after every inventory item is marked copied, tested and owned by the correct account. Preserve the migration record because it becomes the starting point for future recovery or another move.

Plan information: Provider features mentioned on this page were checked against public provider information on 11 September 2026. Prices and inclusions change, so confirm the live checkout before buying. Read our editorial policy and affiliate disclosure.