“Will my site go down? Will I lose email?” If you’re switching web hosts, those are the two questions that keep you up at night — and they’re fair ones. A botched move can mean hours of a dead website or, worse, customer emails vanishing into a black hole. The good news: with the right order of operations, moving to a new host can be done with zero downtime and zero lost mail. The trick isn’t luck or timing the move for 2 a.m. — it’s setting everything up on the new host before you flip the switch. This guide walks through exactly how, in plain English.
A quick DNS primer (the 90-second version)
DNS — the Domain Name System — is the internet’s address book. When someone types your domain, DNS tells their browser which server to talk to. Moving hosts means changing those directions, and to do it safely you only need to understand a handful of record types.
| Record | What it controls |
|---|---|
| A | Points your domain to a server’s IP address (where your website lives) |
| CNAME | An alias that points one name to another (often used for www) |
| MX | Directs your email to the right mail server — mishandle this and mail breaks |
| TXT | Holds verification and email-authentication records like SPF, DKIM, and DMARC |
| NS | Nameservers — the authority that answers all DNS questions for your domain |
Here’s the one distinction that trips people up: nameservers versus individual records. You can either change your nameservers to point at the new host (which hands over everything — website, email, the lot — in one move), or you can leave nameservers where they are and update individual records like the A record and MX one at a time. Changing individual records gives you fine-grained control and is usually the safer, gentler path for a zero-downtime move. Changing nameservers is simpler but blunter — it switches your whole domain at once, which is exactly why it’s risky if the new host isn’t fully ready.
The golden rule: build and test first, switch second
If you remember nothing else, remember this: never change DNS until the new host is fully set up and tested. The reason downtime happens is almost always that someone points the domain at an empty or half-configured server. When you do it in the right order, both the old and new hosts are live and working at the same time, so visitors and email always land somewhere real.
Before you touch a single DNS record, get all three of these moved and working on the new host:
- Files — your website’s pages, images, themes, and code.
- Database — if you run WordPress or any CMS, the database holds your content, settings, and users. The site won’t work without it.
- Email mailboxes — the one everyone forgets. Recreate your mailboxes on the new host and copy the existing messages over before cutover, so nothing is lost in the gap.
The zero-downtime cutover, step by step
Here is the sequence that keeps you online the entire time. Follow it in order — the order is the whole point.
- Lower your DNS TTL a day ahead. TTL (“time to live”) tells the world how long to cache your DNS records. Drop it from the typical 3600+ seconds down to 300 seconds (5 minutes) at least 24 hours before the move. This way, when you do make the change, the internet picks it up in minutes instead of hours.
- Copy the site and email to the new host. Migrate your files, import your database, recreate your mailboxes, and sync your messages. Don’t change any DNS yet — this all happens behind the scenes while your live site keeps running on the old host.
- Test on the new server before anyone else sees it. Use a temporary URL from the new host, or edit your computer’s hosts file to point your domain at the new server’s IP for your machine only. This lets you browse the real domain on the new box while the rest of the world still sees the old one. Click through pages, submit a form, log in — confirm everything works.
- Update your A record (or nameservers). Once you’ve verified the new site, change the A record to the new server’s IP. Because you lowered the TTL, this starts taking effect within minutes.
- Keep the old host active for about 72 hours. Don’t cancel anything yet. While DNS propagates, some visitors and in-flight email will still resolve to the old server. Leaving it running means both boxes answer correctly during the overlap — that’s your safety net and the reason there’s no downtime.
- Verify mail flow on the new server. Send a test message in and out. Confirm new mail is arriving on the new host and that you can send without it bouncing or landing in spam.
- Cancel the old host only after propagation is complete. Give it a few days, confirm all traffic and mail are hitting the new server, and only then shut down the old account.
Email deserves extra care
Email is where most migrations go sideways, so it gets its own rules. Mail is less forgiving than a website — a missed message doesn’t refresh and try again, it’s just gone.
- Copy mailboxes with an IMAP sync. An IMAP transfer copies your existing folders and messages from the old server to the new one without deleting the originals. Run it before cutover, then run it once more right after, so any mail that arrived during the switch gets pulled over too.
- Change MX last and carefully. Your MX records steer incoming mail. Switch them only once mailboxes exist and are synced on the new host — otherwise incoming messages have nowhere to land.
- Mind your SPF, DKIM, and DMARC. These TXT records tell the world your mail is legitimate. If they don’t match the new sending server, your outgoing email can suddenly start going to spam. Update them to reflect the new host before you rely on it for sending.
What “propagation” really means
You’ve probably heard “DNS changes take 24 to 48 hours.” That’s a myth left over from the early internet. Propagation isn’t a fixed clock — it’s governed by your TTL. If you lowered your TTL to 5 minutes the day before, most of the world sees the change within minutes, and the stragglers catch up shortly after. The old “wait two days” advice exists because people forget to lower TTL ahead of time and get stuck with long cached records. Plan ahead and propagation is fast and predictable.
Common mistakes (and how to dodge them)
- Changing nameservers before the new site is ready. The classic downtime mistake — you point the whole domain at a blank server. Build and test first, always.
- Forgetting email entirely. People migrate the website, switch DNS, and only then realize mail stopped flowing. Treat mailboxes as a first-class part of the move.
- Forgetting SPF and DKIM. The site works, mail arrives — but your outgoing messages quietly start landing in spam because authentication records were never updated.
- Canceling the old host too soon. Pull the plug before propagation finishes and you cut off the visitors and email still pointed at the old box. Wait it out.
Let Radiant handle the move for you
If reading all that made you want to close the laptop, here’s the easy button: at Radiant Solutions, we do free managed migrations. Our team copies your files, database, and mailboxes, sets everything up and tests it on our cloud hosting, and handles the DNS cutover for you — TTL, A records, MX, SPF and DKIM, the whole sequence — so you stay online the entire time. We’ve been doing this for Southern California businesses since 1997, and we’ve made the move smooth and downtime-free more times than we can count.
You don’t have to white-knuckle your way through a host migration or risk a single lost email. Contact us or call 1-866-462-4009, and we’ll plan the cutover, do the heavy lifting, and keep your site and mail running without a hiccup.