How to Migrate Business Email Without Losing Mail
Moving business email is where teams lose invoices, vendor quotes, and customer threads — not because the new host is “broken,” but because MX flips before history is synced, or passwords change mid-migration. A zero-mail-loss cutover is a sequenced job: inventory → copy mail → dual-run → switch DNS → re-auth clients.
This guide is the playbook we use when SMBs move into MailShrine (or any IMAP-style host) without gambling on luck.
Real-life example: Mekan Parts
Tunde runs Mekan Parts, an auto-parts distributor in Aba with three mailboxes on aging cPanel webmail. A supplier wired payment instructions to orders@mekanparts.ng the same weekend he planned to “just change MX.” Half the weekend’s mail still landed on the old server; staff phones kept opening cached IMAP sessions to the dead host.
Tunde’s rule after that near-miss: new mailboxes first, history copy second, MX last.
What “no mail loss” actually means
| Layer | Risk if skipped | Safe approach |
|---|---|---|
| History | Old Sent/Inbox vanish from team view | IMAP sync or host export before kill old host |
| New inbound | Messages still hit old MX | Publish MailShrine MX only after new box receives tests |
| In flight | Rare dual-accept window gaps | Lower TTL days ahead; keep old host accepting until TTL×2 after MX change |
| Outbound | Spam / auth fails after move | Update SPF + DKIM with the new host |
| Clients | Phones still talking to old IMAP | Redeploy IMAP/SMTP using client settings |
Zero-loss sequence (high level)
- Inventory every address (mailboxes + aliases + forwarding).
- Create matching addresses on MailShrine (Free = 1 mailbox + 2 aliases; upgrade seats before cutover if you need more).
- Copy history via IMAP (or provider export) into the new host.
- Lower DNS TTL on MX (and related TXT) 24–72 hours early.
- Test send/receive on the new host using temporary paths or host tools.
- Cut over MX (and SPF/DKIM/DMARC) to MailShrine — see MX cutover timeline.
- Reconfigure phones/Outlook; leave old host online until you confirm nothing new arrives.
- Decommission old IMAP only after a quiet period (often 7–14 days).
Detailed IMAP checks: IMAP migration checklist.
Step 1: Freeze the address book
Export a spreadsheet:
| Address | Type | Owner | Approx size | Password known? |
|---|---|---|---|---|
tunde@ | mailbox | Founder | 4 GB | yes |
orders@ | mailbox | Ops | 9 GB | app password |
hello@ | alias → tunde | — | — | n/a |
Include catch-alls and auto-forwarders. Missing rows = silent loss.
Step 2: Build the destination first
On MailShrine: add the domain, create mailboxes with the same local parts, set strong passwords temporarily dedicated to migration, add aliases. Do not delete the old MX yet.
DNS still points at the old host while you sync — that is intentional.
Step 3: Sync history (IMAP-first)
Most cPanel / Google / Microsoft migrations end as IMAP → IMAP. Use a migrator that:
- Copies Inbox, Sent, Drafts, custom folders
- Retries timeouts
- Reports per-folder counts
| Source | Typical path |
|---|---|
| cPanel / webmail | cPanel migration guide |
| Google Workspace | Leave Google Workspace |
| Microsoft 365 | Leave Microsoft 365 email |
Spot-check: open a known thread from six months ago on the new webmail before any DNS change.
Step 4: Soft cutover weekend
- Announce a 2-hour “send cautiously” window.
- Publish MailShrine MX; remove legacy MX rows (avoid two production providers accidentally).
- Align SPF/DKIM so outbound matches the new host.
- Wait for DNS propagation; verify in MailShrine.
- External Gmail → each critical mailbox.
- Update IMAP profiles on every device the same day.
Mekan Parts checklist
- Address inventory completeCompleted
- Destination mailboxes + aliases createdCompleted
- History IMAP-synced and spot-checkedCompleted
- MX TTL lowered earlyCompleted
- MX / SPF / DKIM switchedCompleted
- Inbound tests greenCompleted
- Clients re-authedCompleted
- Old host powered down (after quiet week)Not completed
Common failure modes
- MX first, sync never — new mail works; years of Sent disappear from workflows.
- Password rotated mid-sync — migrator stalls; partial folders look “done.”
- Orange-cloud / proxied mail hostnames on Cloudflare — break MX targets. Keep mail DNS DNS only.
- Two MX providers left forever — split brain delivery.
- SPF left pointing only at Google/Microsoft — new outbound land in spam.
When full Workspace / M365 is still better
If the team lives inside Docs + Drive + Meet or Teams + SharePoint every hour, migrating only mail may not be worth the tooling loss. MailShrine wins when you need email-focused hosting and cost control — not a full productivity suite replacement.
Next steps
Citations & References
- Reference: RFC 5321 — Simple Mail Transfer Protocol
- Reference: Google: Migrate email with the data migration service
- Reference: Microsoft: IMAP migration to Microsoft 365
- Reference: Cloudflare: Manage DNS records
Written by Daniel K., Migration Architect. Daniel designs cutovers so history, inbound, and auth move on purpose — not by hope.
