How Do You Move a Website to a New Hosting Provider Without Downtime or Lost Email?
You move a website to a new hosting provider without downtime by building a complete working copy on the new host, testing it on a temporary address, and only then changing the DNS records that point your domain at it, while the old host keeps running for a week or two. Email survives if you change only the website's address records and leave the mail records (MX, SPF, DKIM) as they are, or copy every one of them to the new DNS provider before changing nameservers.
The work is mostly preparation; the switch itself takes minutes. Entrant Technologies builds and maintains websites and web applications as part of its web development services, and this guide explains the process so you can run it or supervise it.
What actually moves to the new host, and what stays where it is?
Five things move: the website files, the database, the scheduled tasks, the SSL certificate and the environment settings. The domain registration does not move, and in most cases your email should not move either.
What moves
Files include uploaded images and documents, not just code. The database holds your content, customers and orders. Scheduled tasks (cron jobs) send invoices, run backups or process queues, and they are the item most often forgotten because nothing looks broken until a report fails to arrive. Environment settings cover the PHP or Node.js version, database credentials, and API keys for payment and email services.
What stays put
Your domain stays with the registrar you bought it from; changing hosts does not require transferring it. Mailboxes with Google Workspace or Microsoft 365 are unaffected by where the website lives, provided the DNS records for mail stay intact. Mailboxes stored on the old host's server are a second migration that needs its own plan.
What is the safe order of work for moving a website?
The safe order is copy, test, lower the TTL, switch DNS, then keep the old host running.
- Take inventory. Export the full DNS zone, and list the cron jobs, software versions and third-party services on the old server.
- Copy files and database to the new host and match the environment settings.
- Test on a temporary address: the host's temporary URL, or a hosts file entry on your own computer so only you see the new server under the real domain.
- Lower the DNS TTL on the records you will change, at least one full old-TTL period before the switch.
- Prepare the SSL certificate so HTTPS works on the new server for the first visitor.
- Freeze changes, run a final database sync, and switch the DNS records.
- Keep the old host running for one to two weeks, then cancel after a final backup.
Step 6 is where "zero downtime" needs a caveat. A brochure site can switch with no interruption. A site that takes orders or sign-ups writes to its database constantly, and for a short period visitors may reach either server. The usual answer is a read-only or maintenance window of a few minutes on the old site during the final sync, so no order lands in a database that is about to be abandoned.
On certificates: Let's Encrypt's HTTP-01 validation needs the domain to already point at the server requesting the certificate, while DNS-01 validation uses a TXT record and works for servers that are not yet publicly reachable, according to the Let's Encrypt challenge types documentation (last updated February 12, 2026). So you either issue by DNS-01 in advance or copy the existing certificate across.
Why does email break when you change nameservers, and how do you avoid it?
Email breaks because changing nameservers replaces your entire DNS zone, and the new zone often lacks the MX and TXT records that say where your mail goes. Nameservers decide which company answers every DNS question about your domain, not just the website's address.
The simplest prevention is not to change nameservers at all. Keep DNS where it is and edit only the A record (and AAAA record, if present) so the website points to the new server's IP address. Mail records are never touched.
If the new host requires its own nameservers, copy every record first and compare the two zones line by line. Cloudflare's setup documentation gives the same instruction: review your records, including MX, SPF, DKIM and DMARC, before updating nameservers.
SPF needs a second look
SPF is a DNS TXT record listing the servers allowed to send email for your domain, defined in RFC 7208. If your website sends its own email, such as contact form notifications, order confirmations or password resets, the new server must be covered by that record or those messages may be treated as spam. A domain must have only one SPF record: RFC 7208 treats multiple records as a permanent error, and Microsoft's DNS guidance for Microsoft 365 says to merge values into a single SPF TXT record. Edit the existing record; do not add a second.
How long do DNS changes take to reach everyone?
A changed DNS record reaches everyone within roughly the TTL that was set on the old record, because TTL is how long other servers may keep a cached copy. RFC 1035, the DNS specification, defines TTL as the interval a record "may be cached before the source of the information should again be consulted".
That is why lowering the TTL in advance works. If the record's TTL is 86400 seconds (24 hours), lower it to 300 seconds at least 24 hours before the switch, so every cached copy of the long-lived record has expired by the time you change the address. Most visitors then reach the new server within about five minutes. Some devices hold on longer: Cloudflare's TTL documentation notes that local DNS caches can delay a change beyond five minutes.
Nameserver changes are slower and less predictable, because the registrar and domain registry are involved and you do not set the cache time on those records. Cloudflare's setup page says to allow up to 24 hours (checked October 6, 2026).
What should you check after the switch?
Check that the site works for visitors, that email flows in both directions, and that background jobs run on the new server only.
- The site loads over HTTPS with no certificate warning, with and without "www".
- A test form submission, login and checkout complete correctly.
- An email from an outside account arrives, and an email sent by the website reaches the inbox, not spam.
- Scheduled tasks ran on the new server and are disabled on the old one, so nothing is sent twice.
- The old server's access log goes quiet over the following days, confirming traffic has moved.
- Backups are configured on the new host and one has been test-restored.
When should you schedule a hosting migration?
Schedule the switch for your quietest period, at a time when the person doing it and someone who can test it are both available for several hours afterward. For many businesses that is early in the week, outside business hours in the main customer time zone. Avoid Fridays, sales campaigns, month-end invoicing and the last week of the old hosting contract; an expiry date that forces the schedule removes your ability to roll back.
What are the common mistakes when moving a website?
The most common mistake is canceling the old hosting account too early, which removes the fallback and, if mailboxes lived there, deletes the email. Others recur:
- Changing nameservers when one A record would have been enough.
- Lowering the TTL an hour before the switch when the old value was a full day.
- Forgetting cron jobs, or leaving them running on both servers.
- Testing only the home page on the temporary address, not forms, logins or payments.
- Running a different PHP or database version on the new host without testing against it.
- Transferring the domain registration in the same week as the hosting move.
What should you do next, and what should you ask the new host or your developer?
Start by finding out where your DNS is managed and where your mailboxes live, because those two answers decide how risky the move is. Then ask the new host or your developer: Does the migration include the database and cron jobs? Is there a temporary URL for testing? Can I keep my current DNS and change only the A record? What is the rollback plan? How will the SSL certificate be issued before the switch? Who checks email and scheduled tasks afterward?
If you are still deciding where to move, see our guide to choosing cloud hosting for business applications.
Quick answers
Will moving my website to a new host affect my email?
Not if the DNS records for mail (MX, SPF, DKIM, DMARC) stay unchanged. Email breaks when nameservers are switched to a provider whose DNS zone is missing those records, or when mailboxes stored on the old hosting server are deleted with the account.
How long does DNS propagation take after changing hosts?
Roughly as long as the TTL on the record you changed. With the TTL lowered to 300 seconds a day in advance, most visitors reach the new server within about five minutes; a nameserver change can take up to 24 hours.
Should I change nameservers or just the A record?
Change just the A record whenever the new host allows it. That moves only the website and leaves email records untouched, while changing nameservers moves every DNS record at once and is the usual cause of lost email.
Do I need to transfer my domain name to the new hosting company?
No. The domain can stay with its current registrar; you only change the DNS records that point it at the new server.
How long should I keep the old hosting account after the move?
Keep it running for one to two weeks after the DNS switch, as a fallback and to serve visitors with stale DNS caches. Take a final backup before canceling.
Conclusion
A hosting move goes well when the new server is proven before any visitor reaches it, the DNS change is as small as possible, and the old server stays available until you are sure. Most of the risk sits in the inventory: the cron job nobody remembered, the SPF record nobody copied, the mailbox nobody knew was on the old server.
If you want a second pair of eyes on a migration plan, or someone to carry it out, contact Entrant Technologies and we will take a look.