Free planning tool

MOVE HOSTS WITHOUT BREAKING THE SITE.

The HostList migration planner turns your current host, destination, site type, email setup, and domain arrangement into a cutover checklist. It checks 11 current free-migration policies verified against provider documentation, then flags the work a website-only transfer often leaves behind.

Latest policy verification: 8 August 2026

Your move

Your cutover plan appears here

The planner separates website, DNS, email, and registrar work so one move does not accidentally break another service.

Host-only migration

Same URLs. Different infrastructure.

Changing hosting is not the same as changing domains or rebuilding the site. If the visible URLs stay the same, the work is copying, testing, DNS cutover, and monitoring rather than redirecting every page.

Google recommends testing the new infrastructure, confirming crawler access, lowering DNS TTL before the move, monitoring both servers, and keeping the old host online until it stops receiving traffic. Read Google Search Central's hosting-change guide.

  1. 01Inventory websites, databases, runtime versions, storage, cron jobs, DNS, email, SSL, CDN, redirects, and third-party integrations.
  2. 02Lower DNS TTL before the move, then capture a full off-site backup and an export of every DNS record.
  3. 03Build the destination copy behind a temporary hostname or hosts-file override and prevent temporary URLs from being indexed.
  4. 04Test important URLs, forms, search, login, scheduled tasks, webhooks, images, downloads, redirects, SSL, and caching.
  5. 05For ecommerce or memberships, freeze writes briefly or run a final delta sync immediately before DNS cutover.
  6. 06Change DNS, monitor both servers, restore the normal TTL, and cancel the old account only after its traffic reaches zero.
What usually gets missed

A site copy is only part of the move.

Email and DNS

Changing nameservers can disconnect external email, verification records, and subdomains if the destination zone does not contain the same records.

Changing databases

Stores, memberships, forums, and active forms need a content freeze or final delta sync after the first copy.

Server behaviour

PHP versions, rewrite rules, cron jobs, cache exclusions, plugin restrictions, file permissions, and environment variables may differ.

Need a destination?

Compare only hosts whose free migration policy has been verified against published evidence.

View verified hosts โ†’

Need the move handled?

Get a fixed quote for WordPress, WooCommerce, email-aware DNS cutover, final database sync, and post-launch monitoring.

Managed WordPress migration โ†’

Web host migration FAQ

How do I move a website to a new host without downtime?

Copy and test the site at the destination before changing DNS. Lower DNS TTL ahead of the move, run a final database sync for a changing site, point DNS to the new server, and keep the old account live while caches expire. Verify pages, forms, SSL, cron jobs, email, and checkout before cancelling the source.

Does changing web hosts affect SEO?

A host-only move that keeps the same URLs should not need URL redirects. Search can still be affected by server errors, crawler blocks, changed canonical tags, missing assets, or slower responses. Test the destination, preserve Search Console verification, and monitor crawl and server logs after cutover.

Will my email move with my website?

Usually not unless the migration policy explicitly includes it. Website files and databases are separate from mailboxes and DNS records. Export mail, copy mailbox contents, and preserve MX, SPF, DKIM, and DMARC records before changing nameservers.

Should I transfer my domain when changing hosts?

Not during the same cutover. A domain can remain at its registrar while DNS points to any host. Keeping registration separate makes rollback safer. Transfer the domain later, after the website and email are stable, if there is a good reason to consolidate.

How long should I keep the old hosting account?

Keep it until DNS has propagated and the old server logs show that requests have stopped. For a straightforward site this is often several days, but busy sites, long DNS TTLs, mailboxes, and scheduled jobs justify a longer rollback window.