"Migrating" by forwarding
Setting the old platform to forward to the new one moves future mail only — years of history, folders, and sent items stay behind on a server someone is about to cancel.
ranjan@ranjan.info:~$ man services/email-migration
Email Migration & Recovery
Move mail without losing a message — or a day of business
Email is the migration people fear most, because half-lost mailboxes are discovered one missing thread at a time. I migrate mail with continuous IMAP syncing and per-mailbox verification, then finish the job most migrations skip: SPF, DKIM, and DMARC done right, so the mail you send actually lands in inboxes.
What is email migration?
Email migration is the transfer of mailboxes — messages, folders, aliases, forwarders — from one mail platform to another with nothing lost in transit. Done properly it uses continuous IMAP syncing while the old server stays live, a planned MX cutover, a final delta sync for anything that arrived mid-switch, and per-mailbox verification. The step most migrations skip — SPF, DKIM and DMARC on the new platform — is what decides whether your sent mail lands in inboxes afterwards.
Written by Ranjan Chatterjee, Infrastructure Consultant · Linux Server Specialist · 15+ years in production Linux · Last reviewed
ranjan@ranjan.info:~$ dmesg | tail
Signs you need this now
Email problems are quiet until they're catastrophic. These are the signals a move — or a fix — is due.
- Your sent mail keeps landing in recipients' spam folders
- Mailboxes are full and the current platform's next tier makes no sense
- Mail still runs on the same server as the website — one failure takes both
- You're paying per-user prices for features nobody uses
- The provider is sunsetting the plan, or support has evaporated
- A domain or IP blacklisting keeps recurring
- You're consolidating companies, domains, or teams onto one platform
- Nobody is sure where all the aliases and forwarders actually point
ranjan@ranjan.info:~$ cat scope.txt
What this covers
- Google Workspace migrations — in or out
- Microsoft 365 migrations — in or out
- cPanel and DirectAdmin mail server moves
- Bulk IMAP migration with per-mailbox verification
- SMTP and deliverability troubleshooting
- Corrupted or deleted mailbox recovery
- SPF, DKIM, and DMARC configuration and enforcement
- MX cutover planning with zero mail loss in transit
ranjan@ranjan.info:~$ man first-aid
Before you move a single mailbox
Five preparation steps that decide whether an email migration is smooth or a week of "where did my folders go".
-
1
Inventory more than the mailboxes
Aliases, forwarders, distribution lists, autoresponders, and the printers and applications that send mail through your server — the migration plan is only as complete as this list.
-
2
Check sizes against the destination's limits
A 40 GB mailbox doesn't fit a 30 GB quota, and some platforms cap folder counts or single-message sizes. Finding this out mid-sync is the classic avoidable failure.
-
3
Lower the MX record's TTL early
Like any cutover, dropping TTL to minutes a day ahead turns the switch into a fast, reversible event instead of a day of split delivery.
-
4
Plan the authentication records
SPF, DKIM, and DMARC must be ready for the new platform at cutover — not discovered a week later when customers mention your quotes are in their spam folder.
-
5
Tell users what actually changes for them
Usually just a password and maybe a webmail URL. Saying so in advance prevents the flood of "is email broken?" tickets that makes every migration look worse than it went.
ranjan@ranjan.info:~$ grep -i "oops" ~/incidents.log
Mistakes that lose mail
Every one of these comes from a real engagement — usually from before I was called.
Cutting MX before the sync finishes
Mail starts arriving on a platform that doesn't have the history yet, and users see empty mailboxes. Sync first, verify counts, then move MX — the order is the whole method.
Forgetting aliases and distribution lists
The mailboxes move, but info@, sales@, and the list that reaches the whole company silently stop delivering. These rarely appear in mailbox exports — they have to be inventoried deliberately.
Skipping DKIM on the new platform
Mail flows, so everyone declares success — then deliverability decays for weeks as unsigned mail accumulates spam-folder reputation. Authentication is part of the migration, not an optimization after it.
Deleting the old mailboxes at cutover
The old platform is your verification reference and your recovery source. Keep it read-only for a couple of weeks; storage is cheap, lost mail is not.
ranjan@ranjan.info:~$ diff --options
DIY, provider support, or a specialist?
An honest comparison — each option is right in some situations, including the free ones.
| Option | The right choice when… | Limits & risks |
|---|---|---|
| Platform import tools | Google Workspace and Microsoft 365 both import from IMAP/competitors — decent for a handful of straightforward mailboxes moving into them. | Slow on large mailboxes, silent about partial failures, blind to aliases/forwarders, and no help with MX planning or DKIM. Verification is entirely on you. |
| DIY with imapsync | A technical admin, a manageable mailbox count, and time to run and verify syncs — the tool itself is excellent and it's what professionals use. | The tool is the easy 20%: quota math, cutover sequencing, delta syncs, authentication records, and per-mailbox verification are where DIY migrations lose mail — usually discovered one missing thread at a time. |
| Independent specialist | Business mail where losing threads is unacceptable, dozens-to-hundreds of mailboxes, cross-platform moves (cPanel ⇄ Workspace ⇄ M365), or a deliverability problem tangled into the move. | Per-mailbox pricing has a project minimum, and you'll need to provide admin access to both platforms. Genuinely tiny, simple moves may not justify it — the import tool verdict is free if you ask. |
What you get
- Every mailbox moved and verified by count and spot-check — with a per-mailbox report
- Authentication records (SPF/DKIM/DMARC) configured and passing
- A cutover with mail continuously syncing, so nothing in transit is lost
Why work with me on this
- 15+ years inside production Linux — this exact work, done at fleet scale
- Founder-operator of two hosting platforms: I've owned the uptime, not just the ticket
- Every change documented and reversible — you keep a written trail, not a mystery
- Plain-language updates and honest timelines you can plan a business around
ranjan@ranjan.info:~$ ./engage --how
How it runs
The same disciplined path on every engagement — scoped, planned, executed with checkpoints, handed off clean.
-
01
Scope
A short brief or call to understand your stack, the real problem, and what a good outcome looks like.
-
02
Plan
A clear architecture plan — steps, risks, rollback and timeline — agreed before anything touches production.
-
03
Execute
Hands-on work with checkpoints. You see progress; nothing changes on your servers silently.
-
04
Handoff
Documentation, access cleanup and a clear path for what comes next. No lock-in, no mystery.
ranjan@ranjan.info:~$ faq --service email-migration
Common questions
Will we lose access to email during the migration?
No. Old mailboxes stay live while everything syncs in the background; after MX cutover a final delta sync catches anything that arrived mid-switch. Users mostly notice nothing beyond a password update.
How long does an email migration take?
Small domains — a dozen mailboxes — typically complete in a day. Hundreds of mailboxes run about a week, dominated by initial sync time on large mailboxes. The cutover itself is minutes; the calendar time is careful syncing and verification while everyone keeps working normally.
How is it priced?
Per mailbox with a project minimum, quoted up front from the mailbox count and sizes. Deliverability fixes (SPF/DKIM/DMARC, blacklist recovery) are included in a migration; as a standalone diagnosis they're quoted separately.
Can you migrate to or from Google Workspace and Microsoft 365?
Yes, in every direction — cPanel/DirectAdmin to Workspace or M365, between the two suites, or back to self-hosted mail where that's the right call. Each platform has its own quirks (API limits, folder mapping, archive handling) and the plan accounts for them per destination.
What happens to shared and functional mailboxes like info@ and sales@?
They're inventoried and mapped deliberately — sometimes as real mailboxes, sometimes as aliases or shared mailboxes depending on what the destination platform does best (and cheapest). This mapping step is exactly what platform import tools skip.
Our email keeps landing in spam — can you fix that?
Usually, yes. It's almost always missing or misconfigured SPF/DKIM/DMARC, a blacklisted IP, or a shared pool with a bad neighbor. Deliverability diagnosis is available standalone, not just with migrations.
Can you recover mail that was deleted or corrupted?
Often — from Maildir remnants, server backups, or the provider's retention window if we move quickly. Speed matters; the sooner recovery starts, the more comes back.
What about really large mailboxes — 50 GB and up?
They move, they just move differently: multi-pass syncing over days in the background, folder-level verification, and quota planning at the destination. The user keeps working the whole time; only the final delta and password switch involve them at all.
Do you handle old archives and PST files?
Yes. Local archives — PSTs from Outlook, mbox exports, ancient webmail downloads — can be imported into the new platform as part of the project, so history that never lived on the old server still ends up searchable in the new one.
Do you update our DNS, or do we?
Either. With access to your DNS (or Cloudflare), I stage TTLs and execute the MX cutover at the agreed hour as part of the job. If DNS must stay in your hands, you get an exact, timestamped runbook of records and values — nothing left to interpretation.
ranjan@ranjan.info:~$ man glossary
Terms you'll hear during an email migration
Plain-language definitions — so the report reads like information, not incantation.
- MX record
- The DNS record that tells the world which server receives your mail. Moving it is the cutover.
- IMAP
- The protocol that exposes mailboxes and folders — and the universal bridge mail migrates across, whatever the platforms.
- SPF
- A DNS record listing servers allowed to send mail for your domain. Wrong after a migration, your mail fails authentication.
- DKIM
- A cryptographic signature on outgoing mail proving it's really from your domain — the backbone of modern deliverability.
- DMARC
- The policy that tells receivers what to do with mail failing SPF/DKIM, and sends you reports about who's sending as your domain.
- Delta sync
- The final quick pass copying only messages that arrived since the last sync — how cutover happens without a mail gap.
- Alias / forwarder
- Addresses that deliver into other mailboxes. Invisible in mailbox exports, essential to inventory, first thing to break silently.
- Deliverability
- Whether your sent mail reaches inboxes or spam folders — a function of authentication, IP reputation, and sending behavior.
ranjan@ranjan.info:~$ ls ../related
Related services
Engagements that commonly pair with this one.
Zero Downtime Website Migration
Sites, mail, databases, DNS — migrated in a planned cutover, not a leap of faith.
View serviceManaged Server Administration
24×7 monitoring, patching, backups, and incident response on a flat monthly retainer.
View serviceInfrastructure Audit
Security, performance, cost, and disaster recovery — one honest report.
View serviceranjan@ranjan.info:~$ ssh [email protected]
Ready when you are
One paragraph is enough: your stack, the symptom, and when you need it solved. Emergencies are answered first.