When you migrate a website to a new host, copying the site is rarely the hard part. What goes wrong is something nobody wrote down: a DNS record that existed only at the old host, mailboxes bundled into the hosting plan, a contact form whose notifications land in spam from the day of the switch.
This runbook shows how to change web hosting provider with no outage and no lost email. It covers infrastructure only: the same domain and page addresses, on a new server. If your URLs are changing too, use the website migration SEO checklist alongside it.
The short answer
To move a website to a new host without downtime or lost email:
- Map where your domain, DNS, website and email each live.
- Export every DNS record, including MX, SPF, DKIM and DMARC.
- Decide what moves, and move one thing at a time.
- Copy and test the site on the new host, on your real domain, before changing DNS.
- Lower the TTL a few days ahead, then change only the website’s records.
- Verify the site, SSL, forms and email.
- Keep the old host running until its logs go quiet.
There is no downtime because both servers serve the same site while DNS caches expire, and email keeps working because its records keep pointing where they always did.
Step 1: map what lives where
A website depends on four services, often bought from one company. Find out who provides each; our plain-English guide to how websites are built explains the layers.
| Service | What it does | The usual trap |
|---|---|---|
| Domain registration | Makes you the owner of the name | Registered via the old host, at risk when that account closes |
| DNS hosting | Holds the records that point to everything else | Run by the old host, so closing the account deletes every record |
| Web hosting | Serves the website | The only part most people plan for |
| Email hosting | Stores mailboxes and receives mail | Mailboxes on the old hosting account vanish with it |
Check it yourself. An online DNS lookup, or dig NS example.com and dig MX example.com, shows your nameservers and mail servers. MX records naming Google or Microsoft mean your email lives there; if they point to your own domain, mail.example.com or the old host, it is probably part of the hosting plan.
Step 2: export every DNS record before you touch anything
You can’t reliably list a domain’s records from outside, so export them from the DNS provider’s control panel as a zone file or screenshots. Miss one and something breaks quietly, often email.
| Record | What it does |
|---|---|
| A and AAAA | Point a name at a server’s IPv4 or IPv6 address |
| CNAME | Points one name at another, often www |
| MX | Routes incoming email |
| SPF (TXT) | Lists the servers allowed to send your email |
| DKIM (TXT or CNAME) | Publishes the key that signs your outgoing email |
| DMARC (TXT) | Tells receivers what to do with mail that fails checks |
| Verification (TXT) | Proves ownership to Search Console and other tools |
| CAA | Limits which certificate authorities may issue your SSL certificates |
DKIM is easy to miss because it sits under a name you have to know, such as selector._domainkey.example.com. Find the selector in the full headers of an email your company sent: it is the s= value in each DKIM-Signature line. Newsletter tools and CRMs that send as you often have their own.
Check whether your email follows the website
On many shared hosts, especially cPanel ones, the MX record points at the domain itself or at mail.example.com, an alias (CNAME) of the domain. Change the domain’s A record and your email moves with the website.
If the mailboxes are staying put, give mail.example.com its own A record with the old server’s IP and point the MX at it, well before cutover.
Step 3: decide what moves, and move one thing at a time
Moving website, DNS and email in one evening turns three small problems into one confusing one.
Keep DNS where it is if you can
An A record change is quick and reversible. A nameserver change is slower: the registry behind your domain ending (.com, .org and so on) sets how long its nameserver records are cached, often a day or two, and you can’t shorten it. So if your DNS sits with your registrar or a dedicated DNS provider, leave it there. Behind a proxying CDN, you change only the origin address, which takes effect almost at once (see website caching and CDNs explained).
If DNS has to move, move it first
If the old host runs your DNS and you are leaving it completely, recreate every record at the new DNS provider, still pointing at the old server. Compare the zones line by line, switch the nameservers and wait a few days: nothing visible should change. Then move the website separately.
Check DNSSEC first. If it is on, remove the DS record at the registrar and wait a day or two before switching, or follow the new provider’s transfer steps; otherwise validating resolvers can treat the domain as broken.
If email lives on the old host, give it its own project
Choose an email-only plan with the old host, mailboxes on the new host, or a service such as Google Workspace or Microsoft 365. Create every mailbox at the destination, copy messages over IMAP (with the provider’s import tool or one such as imapsync), switch the MX records, then copy again to catch late arrivals. Update every phone and laptop, and keep all of this off the website’s cutover day.
Step 4: copy and test the site on the new host
Match the environment
Most “it worked on the old server” problems come from the server, not the site. (Still choosing a host? See how to choose web hosting for speed.) Before copying anything, compare:
- PHP version and extensions, database version, memory and upload limits
- Server rules: redirects in an Apache
.htaccessfile do nothing on Nginx and must be rewritten - Scheduled tasks (cron jobs) for backups, feeds or scheduled posts
- Outside services that only accept your server’s IP address, such as a payment gateway or CRM
Copy the files and the database
For WordPress, copy the wp-content folder, the database, the wp-config.php settings and extra root files such as .htaccess, using a migration plugin, the host’s migration service or a manual export.
Keep the domain the same. If URLs must change temporarily, don’t find-and-replace in the database file, which can corrupt the serialised data WordPress stores; WP-CLI’s search-replace command handles it safely.
Test on your real domain, before DNS changes
Temporary preview URLs often break WordPress, which expects its own domain. Instead, edit your computer’s hosts file, which overrides DNS for your machine only: with admin rights, add a line such as 203.0.113.10 example.com www.example.com (the new server’s IP) to /etc/hosts on macOS or Linux, or C:\Windows\System32\drivers\etc\hosts on Windows. You see the new server on the real domain; everyone else still sees the old one.
Confirm it with a small text file that exists only on the new server. Then test every page template, form, login and integration, and remove the hosts line afterwards.
Sort out SSL before the switch
The new server needs a valid certificate the moment traffic arrives. Some hosts can issue one before cutover through DNS validation (a TXT record proves control), or you can install a copy of an existing paid certificate. Others issue one only once DNS points at them, leaving a short window of browser warnings, so ask. Check, too, that any CAA record allows the new host’s certificate authority.
Step 5: lower the TTL, then cut over
Lower the TTL in advance
Every DNS record has a time to live (TTL): how many seconds resolvers may cache it. What people call DNS propagation is those caches expiring. With a TTL of 86400 (24 hours), some visitors could reach the old server for a day after you switch.
So lower the TTL on the records you will change to around 300 seconds, at least one old TTL before cutover; Google’s guidance on moving hosts suggests a week ahead. Some resolvers enforce a minimum, so expect the odd straggler.
Cutover, in order
- Pick a quiet time and freeze content edits.
- If content, form entries or orders changed since your test copy, copy the database again, pausing checkout or bookings meanwhile.
- Point the root domain’s A record at the new server, and
wwwtoo if it isn’t an alias of the root. - Update or remove any AAAA record: if the new server has no IPv6 address, an old one keeps IPv6 visitors on the old server.
- Leave MX, SPF, DKIM, DMARC, verification records and mail subdomains alone, once the mail fix from step 2 is in place.
- Check from outside: an online lookup, or
dig +short example.com A @1.1.1.1, then@8.8.8.8.
Write the rollback down first. Note every old value before you change it. With the old server untouched and a short TTL, going back takes minutes.
Step 6: verify the website and the email
A homepage that loads proves very little. Run these checks, then the full website launch checklist:
Unchanged URLs need no Change of Address in Search Console; that tool is for new domains. Just watch the Crawl stats and Page indexing reports for a few weeks.
Why form emails break after a host move
If your site sends email straight from the web server, your SPF record may authorise the old server by its IP address. If the new server isn’t covered, its messages fail SPF, and without a valid DKIM signature for your domain they fail DMARC too. Under a DMARC policy of quarantine or reject, receivers may send them to spam or refuse them.
The durable fix is authenticated SMTP through your email provider or a transactional email service that signs with DKIM. Add that service to your existing SPF record (two SPF records break the check), and stay within SPF’s limit of 10 DNS lookups.
One more trap: some control panels assume they handle your domain’s mail, so messages the site sends to your own addresses land in an empty local mailbox. If your email lives elsewhere, set cPanel’s Email Routing to Remote Mail Exchanger, or your panel’s equivalent.
Step 7: keep the old host running until it goes quiet
Cancelling on cutover day is the costliest shortcut in a hosting migration. Keep the old account for a week or two, and before closing it:
- Watch its access logs. When only the odd bot still arrives, caches have caught up.
- Collect stray data: form entries, orders or emails that reached the old server during the switch.
- Download a full backup of files, database and any mailboxes.
- Raise the TTL back to a normal value, such as 3600 seconds.
- Tidy up access. Remove migration plugins and temporary logins, and change passwords shared during the move; the WordPress security guide covers the rest.
- Check the domain. If it is registered through the old host, transfer it before the account closes.
Before you migrate your website to a new host
The switch takes minutes; the mapping, testing and patience around it keep the site up and the email flowing.
A new host fixes slow or unreliable hosting, not heavy pages, broken forms or a site that doesn’t turn visitors into enquiries. If the move is part of a bigger change, plan both as a website redesign: we launch without taking the site offline, and the domain, hosting and logins stay in your name. A website care plan then keeps updates, backups and uptime monitoring running.
Not sure the server is what’s slowing your site down? Start with a free website audit, or talk to us about what your website needs.