How to move hosts without downtime or losing email
Migration is mostly a sequencing problem. Do the steps in the right order and downtime is zero; get one step wrong and you lose a day of email you never find out about.
Key takeaways
- Migration is a sequencing problem. Done in the right order, downtime is zero.
- Lower your DNS TTL several days before you move — this is the step people skip and regret.
- Never cancel the old host until the new one has been serving live traffic for a week.
- Email is the part that goes wrong. It migrates separately from the website and fails silently.
- Most hosts will migrate you free as an acquisition incentive. Ask before doing it yourself.
Moving hosts sounds risky and mostly is not. The website portion is well-understood and reversible. The genuinely dangerous part is email, because it fails quietly — messages bounce or vanish into an old mailbox and nobody tells you.
Here is the order that produces no downtime.
First: ask the new host to do it
Most hosts offer free migration for at least one site, because acquiring you is worth far more than the labour. Managed WordPress hosts in particular have this down to a routine.
Take it. Their team has done it hundreds of times, they know their own platform and they will fix what breaks. Ask specifically:
- Is it free, and for how many sites?
- Does it include email, or website only? (Very often website only.)
- How long, and will there be downtime?
- Do they handle the DNS cutover or is that yours?
Even with the host doing the work, read on — the DNS and email steps usually remain yours, and they are where the risk sits.
Step 1: lower your DNS TTL (several days ahead)
The step people skip, and the one that determines whether the cutover is seamless.
TTL ("time to live") tells resolvers worldwide how long to cache your DNS records. A typical default is 14400 seconds — four hours. When you change where your domain points, resolvers holding a cached record keep sending visitors to the old server until it expires.
So: several days before migrating, log into wherever your DNS is managed and lower the TTL on your A and CNAME records to 300 seconds. Wait for the old TTL to elapse so caches worldwide pick up the new short value. Then, when you switch, propagation takes about five minutes instead of four hours.
Raise it back to a normal value a few days after the move.
Step 2: set the site up on the new host
Do everything before changing any DNS. The old site keeps serving throughout; nobody notices.
- Create the account and add the domain.
- Copy all files — usually SFTP or a host migration tool.
- Export the database from the old host, import to the new one.
- Update configuration with the new database credentials (for WordPress,
wp-config.php). - Recreate anything not in the file system: cron jobs, redirects, PHP version, environment variables.
Step 3: test before switching
Do not switch DNS and hope. Test the new server while the old one is still live.
Most hosts provide a temporary URL or preview domain. Where they do not, edit
your local hosts file to point the domain at the new server's IP for
your machine only — your computer sees the new site, everyone else sees the
old one. This is the closest thing to a dress rehearsal available.
Check: the home page, several inner pages, a form submission, the admin login, image loading, and anything involving payment. Look for hardcoded old-server paths in the database, which is the most common WordPress migration defect.
Step 4: freeze content, do a final sync
Between copying the database and switching DNS, any new content or orders on the old site are lost.
For a low-traffic site, migrate at a quiet hour and accept the small window. For a store, put the site in maintenance mode briefly or do a final database export immediately before the switch. Never leave days between the copy and the cutover on a site that receives orders.
Step 5: switch DNS
Update the A record (and AAAA if you use IPv6) to the new server's IP. With TTL at 300 seconds, most of the world follows within minutes.
Both servers are now serving the same site to different visitors, which is exactly why this works — there is no moment where nothing responds.
Watch traffic on both. When the old server goes quiet, propagation is complete.
Step 6: email — the part that goes wrong
Email is separate from web hosting even when the same company provides both, and it is governed by different DNS records: MX, plus SPF, DKIM and DMARC.
The failure: you move the A record, MX records follow the domain to the new host, and mail starts being delivered to empty mailboxes on the new server. Senders get no bounce. You get no error. Mail simply arrives somewhere you are not looking, and you find out days later.
To avoid it:
- Create the mailboxes on the new host first, with the same addresses and passwords, before touching MX records.
- Copy existing mail across. If you use IMAP, adding both accounts to a mail client and dragging folders works. Better hosts provide an IMAP sync tool.
- Change MX records only after mailboxes exist.
- Update SPF and DKIM to authorise the new mail servers, or your outgoing mail starts landing in spam — another silent failure.
- Keep the old mailboxes for at least two weeks and check them. Stragglers will arrive.
Genuinely worth considering: use a dedicated email provider rather than your web host. Then email is independent of hosting, MX records never change when you move, and this entire step disappears from every future migration.
Step 7: SSL
Certificates are tied to the server, not the domain, so the new host needs its own. Most issue a free certificate automatically once DNS points at them — which means there may be a brief window after the cutover before HTTPS works.
Check that it has issued, that HTTP redirects to HTTPS, and that there is no mixed-content warning. Some hosts can pre-issue via DNS validation before the switch; ask if downtime on HTTPS is unacceptable.
Step 8: wait before cancelling
Keep the old hosting for at least a week after everything looks fine, and ideally a month.
It is cheap insurance. If something is missing you can retrieve it. If the new host turns out to be worse, reverting is a DNS change. Cancel immediately and you have thrown away the only rollback you had.
Take a full backup — files and database — and store it somewhere that is not either host before cancelling.
Post-migration checks
- Send and receive test email in both directions, including to an external address.
- Submit every form on the site.
- Test checkout end to end if you sell anything.
- Check redirects still work, particularly old-URL redirects.
- Confirm scheduled tasks are running — scheduled posts, backups, reports.
- Check search console for a crawl-error spike over the following week.
- Confirm backups are configured on the new host and test a restore.
That last one matters. People migrate, assume backups carried over, and discover months later that nothing was ever configured.
If you are moving because of a renewal price increase, it is worth asking the current host for a retention discount first — see the renewal guide. If you are moving anyway, the finder will suggest where to go.
Further reading
- The renewal price trap — the usual reason for moving.
- Choosing a hosting type — worth reconsidering the category while you are moving.
- Uptime SLAs — the other usual reason for moving.