Moving a website is more than copying a folder and changing an address. The files may move successfully while email, scheduled tasks or recent customer orders remain behind. A safer move treats the website, its changing data and its connected services as separate items to verify.
This guide assumes you are keeping the same domain and public page addresses. A domain change needs additional redirect and search-migration planning. No checklist can guarantee zero downtime, but preparation can reduce avoidable disruption.
1. Make an inventory before changing anything
List the services connected to the old account: website files, databases, uploads, email mailboxes, scheduled tasks, subdomains, SSL certificates, redirects and external integrations. Record who controls the domain registration and DNS.
Confirm that the new host supports the required software versions, database, storage and background tasks. Ask what a migration service includes. Website transfer does not necessarily include mailboxes, DNS, paid software licences or troubleshooting custom code.
Choose a quieter period and decide who will handle the move, who can approve reopening the site and how support can be reached. Keep access to both hosts.
2. Take a complete backup and keep the original service
Make a fresh copy of the files, database and required configuration, then store it securely outside the old hosting account. Confirm that you can read and restore it. For WordPress, use a process that covers the installation's files and database. [1]
Do not cancel the old hosting yet. You may need it to serve visitors with cached DNS, retrieve missed data or recover from a problem. Agree an overlap period based on observed traffic and successful checks rather than assuming a fixed number of hours will always be enough.
3. Build and test the new copy privately
Use the host's preview method or an appropriately protected staging site. Test important pages, images, downloads, logins, forms and redirects. Keep the public domain and URL structure consistent with the existing site. Google recommends testing the replacement infrastructure before changing DNS. [2]
Stop the test copy from sending customer emails, processing real payments or running duplicate background jobs. Check that any temporary preview URL has not been written into production settings. For WordPress URL changes, follow its migration guidance rather than performing an indiscriminate database text replacement. [1]
Arrange a valid HTTPS certificate for the real domain. If it cannot be issued before the switch, agree a specific certificate plan with the new host. Do not ask visitors to ignore browser warnings.
4. Protect email before touching DNS
Export or record the existing DNS zone. A and AAAA records address IPv4 and IPv6 destinations; CNAME records create aliases. MX records direct incoming email, while TXT records often contain verification and email authentication information. [3]
If email stays with the same provider, preserve its MX, SPF, DKIM and DMARC configuration. Also inspect dependencies: an MX record may point to a mail hostname whose address is on the old server. Keeping the MX text unchanged is not enough if the destination it relies on changes or disappears.
If mailboxes are moving too, plan that as a separate transfer. Recreate accounts and aliases, copy existing mail using the providers' supported process, and arrange a final synchronisation if required. [7] DNS changes route new messages; they do not copy old messages.
Changing nameservers can replace the whole active DNS zone. Recreate all required records before that change. If DNSSEC is enabled, coordinate the signing and registrar DS-record transition with the DNS provider so validation continues to work. [6]
5. Plan the final data synchronisation
The first copy becomes outdated while visitors continue using the old site. A shop can receive orders, a forum can gain posts and a booking site can accept appointments during the move.
Choose a method that prevents conflicting updates: a short, controlled maintenance period, or a migration process designed to synchronise live data. Pause the relevant writes and scheduled jobs, take the final copy, restore it on the new host and confirm the latest records. Account for delayed payment notifications and other incoming integrations.
Avoid letting two independent copies accept orders at the same time. If uninterrupted transactions are essential, ask an experienced administrator to design the migration. A routine file-copy service may not meet that requirement.
6. Change only the DNS records required
Have the new provider confirm the exact records and values. Check both the root domain and www, plus any relevant IPv6 or subdomain records. An old AAAA record can send some visitors to the wrong destination even when the A record is correct.
TTL controls how long DNS answers are cached. Lowering a configurable TTL in advance can shorten the transition, but it does not erase copies already cached under the previous value. Allow the previous TTL to expire before relying on the lower setting, and remember that caches can behave differently. [4]
A host change usually does not require transferring the domain registration. Avoid combining extra account moves, a redesign and a host migration unless you have a reason and a recovery plan.
7. Verify the result and keep a rollback plan
Check the site from more than one network, and use the new host's logs or diagnostic tools to confirm which server is answering. Test incoming and outgoing email separately, along with contact forms, purchases, bookings and scheduled jobs. Compare recent records and uploaded files.
Google advises monitoring traffic on both infrastructures and shutting down the old one only when it is no longer being used and the new one is serving correctly. Keep existing page addresses and check that production pages are not accidentally blocked from indexing. [2]
If something fails, changing DNS back is not an instant undo: caches still apply. If the new site has accepted orders or messages, preserve and reconcile that data before reverting. Document who decides whether to roll back and how new transactions will be retained.
Before cancelling the old host
- Website pages and HTTPS work on the intended addresses.
- The latest content, orders and uploads are present.
- Incoming mail, outgoing mail and form delivery work.
- Scheduled jobs run in the intended place only.
- New-host backups have been enabled and checked.
- Traffic has moved off the old infrastructure.
- Required data and a recovery copy are retained securely.
Frequently asked questions
Will my email move automatically?
No. Mail storage and DNS routing are separate. Confirm the mailbox-transfer scope even when both services appear in one hosting control panel.
Should I use Google's Change of Address tool?
Not for a hosting-only move that keeps the same public URLs. Google distinguishes this from a move to a different domain. [5]
Can I promise customers there will be no downtime?
Only if your actual architecture and migration process support that commitment. For a small business, an agreed maintenance window is often easier to manage than an unsupported promise.
Sources and further reading
[1] WordPress — Migrating WordPress: https://developer.wordpress.org/advanced-administration/upgrade/migrating/
[2] Google Search Central — Changing your hosting: https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes
[3] Cloudflare — DNS records: https://www.cloudflare.com/learning/dns/dns-records/
[4] Cloudflare — Time to Live: https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/
[5] Google Search Console — Change of Address tool: https://support.google.com/webmasters/answer/9370220
[6] Cloudflare — DNSSEC validation and keys: https://developers.cloudflare.com/dns/dnssec/validation-and-key-management/
[7] cPanel — Sync email after a transfer: https://support.cpanel.net/hc/en-us/articles/360050928373-How-do-I-Sync-Email-After-a-Transfer
Guidance checked: 9 November 2026. Exact migration steps depend on your website, DNS provider and email service.