What "Without Downtime" Means When You Change Hosts
Changing DNS isn't instant. Resolvers that looked up your domain recently keep the old answer until that record's TTL (time to live) runs out. As Cloudflare's TTL documentation puts it, the TTL controls how long a record is cached, and so how long updates take to reach users.
So for a while, some visitors reach the new server and some the old one. A zero-downtime move plans for that overlap: both servers carry a working copy of the site, both can receive mail, and the old one stays on until its traffic dries up. Google's guide to changing your web hosting follows the same stages: prepare, update DNS, monitor both, and shut the old one down once nobody uses it.
First, Find Out Where Your DNS and Email Actually Live
Before you book a new plan, answer three questions.
- Who hosts your DNS? It could be your registrar, your current host (nameservers like ns1.yourhost.com), or a service such as Cloudflare. Running
dig NS example.com +shortornslookup -type=NS example.comtells you. - Where does your email live? Look at the MX records. If they point to your current hosting server, your mailboxes are moving too. If they point to Google or Microsoft, mail is separate from the website.
- What else is in the zone? Open cPanel's Zone Editor and save a copy of every record: A, CNAME, MX and all TXT records, including SPF, DKIM, DMARC and verification codes.
This decides the size of the job. If DNS lives at your registrar or Cloudflare, moving the website can mean changing just two A records, for the bare domain and www. If DNS lives at your current host and you switch nameservers, you are moving the whole zone, and every record must exist at the new host first.
A Timeline to Migrate a Website to a New Host Without Downtime
| When | What to do | Why |
|---|---|---|
| 1–2 weeks before | Record DNS, mailboxes, forwarders, cron jobs and PHP version. Take backups. | You can't rebuild what you didn't record |
| About 1 week before | Set up the new account, upload the site, create mailboxes | Gives you days, not hours, to test |
| At least 2 days before | Lower the TTL on the records you will change | The old TTL has to expire before the new one counts |
| 1–3 days before | Test through your hosts file. Sort out the certificate. | Problems surface while visitors still see the old site |
| Cutover, at a quiet hour | Freeze edits, do a final sync, change the records | Nothing new lands on the old server and gets lost |
| First 48 hours | Check public resolvers, both servers and the old mailboxes | Some visitors and mail still go to the old host |
| 1–2 weeks after | Raise the TTL again, take a fresh backup, then cancel the old plan | Only once the old server has gone quiet |
Step 1: Take the Right cPanel Backup
cPanel has two kinds of backup, restored in different ways. Its Backup documentation says you cannot automatically restore a full backup in cPanel, because that function is only available in WHM. Partial backups, on the other hand, "can be restored fully through cPanel."
| Backup | What it holds | Who restores it |
|---|---|---|
| Full account backup | The whole account in one .tar.gz file | The new host, in WHM. Send it to their migration team. |
| Home Directory | Your files, including public_html and the email stored for your domains | You, in cPanel's Backup or Backup Wizard |
| MySQL database | One database per file | You, in cPanel |
| Email forwarders and filters | Forwarders per domain, account-level filters | You, in cPanel |
Download both kinds to your own computer. If the new host offers free migration between cPanel servers, they may restore your full backup or use WHM's Transfer Tool, which needs root access, so it's their job rather than yours.
A static HTML site is simpler. This website is hand-coded HTML on shared cPanel hosting (see static HTML vs WordPress), so moving it mostly means uploading public_html. The catch is hidden files: turn on "Show Hidden Files" in File Manager's settings, or your .htaccess with its redirects stays behind.
Step 2: Lower the DNS TTL Before You Need It
Lowering the TTL only helps if you do it early. If your A record has a TTL of 86400 seconds (one day) and you lower it this morning, resolvers that cached it last night keep the old value until tomorrow. Change it at least one full old TTL before cutover, plus a margin.
Google's hosting guide suggests a conservative low value, for example a few hours, set at least a week before the move. Many small sites go lower; Cloudflare's Auto TTL is 300 seconds. Lower only the records you will change: the A records for the root domain and www, plus MX if email is moving. Raise them again afterwards.
Step 3: Test the New Host Through Your Hosts File
Your computer's hosts file overrides DNS for that one machine. Point your domain at the new server's IP and you can browse the real domain on the new host while customers still reach the old one.
# Windows: C:\Windows\System32\drivers\etc\hosts (Notepad as Administrator)
# macOS / Linux: /etc/hosts (sudo nano /etc/hosts)
# 203.0.113.25 is an example IP
203.0.113.25 example.com
203.0.113.25 www.example.com
# Then clear the local DNS cache
# Windows: ipconfig /flushdns
# macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderTo be sure which server you're seeing, upload a file such as new-host-check.txt to the new server only. If it opens, you're on the new host. If the browser ignores the hosts file, try a private window or turn off its secure DNS setting.
Then test every page template, images, downloads, redirects and, above all, the contact form, which now sends from a different server. On this site, contact-submit.php sends mail through PHP, so it would be the first thing we check. From a terminal, curl -I --resolve example.com:443:203.0.113.25 https://example.com/ does a similar check without editing files.
Step 4: Keep Email Working Through the Move
Everyone tests the website. Email breaks quietly, because nobody notices a missing message. What to do depends on where it lives:
| Email lives at | MX records | What to watch |
|---|---|---|
| Google Workspace or Microsoft 365 | Leave them alone | Keep their SPF include and DKIM records exactly as they are |
| Your old cPanel host | Change them only once the mailboxes exist on the new host | Copy old messages over, rebuild forwarders, keep checking the old mailboxes |
| Anywhere, with a nameserver switch | Recreate them in the new zone before switching | Compare the new zone with your saved copy, one record at a time |
SPF and DKIM need extra care. cPanel's Email Deliverability interface on the new host shows a suggested SPF record with the new server's IP, and a DKIM key generated on that server. If the new server sends any mail for your domain, even a contact form, it has to be authorised. Add its IP to your existing SPF record instead of creating a second one, which makes SPF checks fail:
v=spf1 +a +mx +ip4:203.0.113.25 include:_spf.google.com ~allThat example keeps Google Workspace and adds the new web server; yours will differ. If your mailboxes move to the new cPanel server, swap the old DKIM TXT record for the new server's at cutover.
Step 5: Plan the SSL Certificate Before the Switch
cPanel's AutoSSL, which uses Let's Encrypt by default on new cPanel installations, only includes domains that pass domain control validation, according to cPanel's Guide to SSL. The usual method is HTTP validation, and Let's Encrypt's challenge types page explains that it fetches a file from your domain over port 80. Until the domain points at the new server, that request lands on the old one, so the new host can't issue a certificate yet.
Two clean options:
- Copy the current certificate across. Copy the certificate and private key from the old cPanel's SSL/TLS area and install them on the new host under Manage SSL Sites, so HTTPS works from minute one. Once DNS settles, delete the copy and click Run AutoSSL in SSL/TLS Status, because AutoSSL won't replace a certificate it didn't issue.
- Cut over at a quiet hour and run AutoSSL straight away. With a short TTL the window for certificate warnings is short, but not zero.
If your zone has a CAA record, check that it allows the certificate authority the new host uses.
Cutover Day: Change the Records and Watch Both Servers
Stop editing the old site first, or this morning's blog post lives only on a server you're about to cancel. Sync anything that changed since your backup, remove any testing crawl blocks (Google's guide calls this out), then update the A records or nameservers.
# Second column = TTL in seconds
dig example.com A +noall +answer
dig www.example.com A +noall +answer
# Ask specific public resolvers
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
# Should match your saved copy
dig example.com MX +short
dig example.com TXT +short
# Windows equivalents
nslookup example.com 8.8.8.8
nslookup -type=MX example.comGoogle suggests watching the logs on both hosts: traffic on the old one falls as the new one rises. It also says a temporary dip in Googlebot's crawl rate after a hosting change is normal. The URL Inspection tool in Search Console confirms Google can reach the new server.
When It Is Safe to Cancel the Old Hosting
Google's answer: once traffic to it reaches zero. In practice, wait until the old access log is quiet, the old mailboxes have stopped receiving mail, and you've downloaded a final copy of the account. Allow a week or two. Another month of the old plan costs far less than lost email.
Common Website Migration Mistakes
- Switching nameservers before the new zone is complete. Missing MX, DKIM or verification records break email while the website looks fine.
- Two SPF records. RFC 7208 says a domain must not have more than one SPF record. Merge them into one.
- Forgetting DNSSEC. If DNSSEC is on, cPanel's Zone Editor documentation says to remove the DS records at your registrar before moving the account to another server, and to allow up to 72 hours for that change to propagate.
- Leaving root files behind. Copy your Search Console verification file, robots.txt and, for AdSense sites, ads.txt.
- Forgetting your own hosts file. Delete the test entries, or you'll keep seeing the new server and assume the switch is finished everywhere.
If the domain is changing too, you need URL redirects; our redesign SEO guide covers that. And open the new account in the business's name, as we suggest in how to write a website brief.
Frequently Asked Questions
How long does it take to move a website to a new host?
For a small site, copying and testing usually takes hours, longer with big databases or many mailboxes. Most visitors pick up the new DNS records once their cached copies expire, which is why the TTL you set beforehand matters. Keep the old hosting running for a week or two afterwards.
Will changing web hosts affect my Google rankings?
It shouldn't, as long as the URLs stay the same and the new server works properly. Google treats this as a hosting change and says a temporary dip in crawl rate is normal. Remove any testing crawl blocks and keep your Search Console verification in place.
Do I have to change nameservers to move hosts?
No. If your DNS is at your registrar or a service like Cloudflare, you can leave it there and change only the A records for the domain and www. Switching nameservers moves the whole DNS zone, so every record must be recreated first.
Will I lose emails when I switch hosting?
You shouldn't, as long as the mailboxes exist on the new host before the MX records change, and you keep checking the old mailboxes during the overlap. If your email is with Google Workspace or Microsoft 365, leave the MX records untouched.
Can I restore a cPanel full backup myself?
Not automatically. cPanel's documentation says full backups can only be restored automatically in WHM, so ask your new host to do it. You can restore partial backups, such as the home directory or a database, yourself in cPanel.