How to Move Your Website to a New Host With Zero Downtime and No Email Loss

You've decided to switch hosting providers: it's too expensive, too slow, or support simply stopped answering. Your real fear isn't the site itself — it's the day you move it, when suddenly customers can't reach the site and emails on your company address start vanishing. That fear is justified, because this is exactly where most botched migrations fall apart.

The good news: a zero-downtime migration isn't luck, it's order. If you follow the right sequence — build everything on the new server first, verify it, and only then switch DNS — visitors feel nothing and email keeps flowing. In this article I'll show you the exact steps, the real traps (especially around email), and what to ask any serious provider before you pull the trigger.

First rule: site and email are two separate things

The most common mistake is thinking "moving the site" automatically moves the email too. It doesn't. Your domain (e.g. company.com) has separate DNS records: one says where the site lives, another says where the email lives.

• A / CNAME record → points to the website server
• MX record → points to the email server
• SPF, DKIM, DMARC records → authenticate email so it doesn't land in spam

If you move hosting but leave email where it is, you simply must NOT touch the MX and authentication records. Trouble starts when the new provider "resets" all DNS to its own defaults and, without meaning to, rewrites your MX too. From that second, business email starts dropping. So first, identify what belongs to the site and what belongs to email, separately.

The correct order of steps (this is where the battle is won)

Downtime almost always happens when you switch DNS before the new server is ready. The correct sequence is the reverse:

1. Build or copy the full site onto the new host, but access it via a temporary address or your local hosts file.

2. Test everything: pages, forms, checkout, speed, SSL certificate.

3. Record ALL your current DNS records (screenshot or export). This is your safety net.

4. Lower the TTL a day ahead (e.g. to 300 seconds) so the change propagates fast.

5. Only now switch the A record to the new IP. Do NOT touch MX.

6. Keep the old server running for a few days until DNS fully propagates (this can take up to 24-48h).

That way, at any moment, anyone hitting the site sees either the old version or the new one — never a dead page.

How to keep email alive during the move

Email is the sensitive part, because a lost message is gone for good. Clear rules:

• If you are NOT changing email providers, don't touch the MX, SPF, DKIM or DMARC records at all. Leave them exactly as they are.
• If you are changing email too (e.g. moving to Google Workspace or Zoho), create the new mailboxes first, migrate old messages over IMAP, and only then switch the MX.
• Watch propagation: while DNS spreads, some emails may hit the old server and some the new one. That's why you keep both active for a few days.
• After the move, send a test email from outside (a different account) and confirm it arrives and doesn't go to spam. Check SPF and DKIM with a deliverability tool.

Golden rule: don't cancel the old email subscription on moving day. Wait until you've confirmed everything flows on the new server.

Traps that cause downtime even when you do everything "right"

A few things that catch people off guard:

• SSL certificate: if the new server has no valid certificate before the move, visitors get a "not secure" warning. Issue and verify it BEFORE the DNS change.
• Nameservers vs. individual records: changing nameservers wholesale resets ALL DNS at once, including MX. It's safer to edit only the A record, surgically.
• Database and files: on dynamic sites (WordPress, shops), if someone places an order on the old server after you've migrated the database, that order is lost. So move during low-traffic hours and ideally set the old site to "read-only" during the transition window.
• Redirects and hardcoded links: check that no old addresses (http, fixed IP) remain in the code or settings.

How we handle migrations at MPO Web Studio

At MPO Web Studio we do migrations remotely, for clients across the country, with no need for anyone to show up on site. Our approach is simple and stress-free for you:

• We build the full copy on the new host first and show it to you on a test address — you see with your own eyes that everything works before we touch anything on the domain.
• We map all current DNS and clearly separate site from email, so your company address doesn't even flicker.
• We make the switch during low-traffic hours and monitor propagation until it stabilizes.
• Transparent pricing, stated upfront, with no surprise costs once work has started.

If you have a site and a business email you're afraid to touch, message us on WhatsApp, we'll look at your situation together and tell you honestly whether it's worth moving and how. No pressure.