Forum Discussion
Moving Office 365 Mailboxes to IMAP Servers - What’s the Best Approach
I’ve recently been looking into scenarios where organizations need to move mailboxes from Microsoft 365 to IMAP based email servers, and I noticed this is still a common requirement in many migrations.
In most cases, the challenge is not just moving emails, but making sure everything like folder structure, old emails, and user data stays intact without creating too much disruption for users.
From what I’ve seen, doing this manually can get very complex, especially when there are multiple mailboxes or large data volumes involved. That’s where migration tools usually come into the picture.
Most tools simplify things by handling:
1. Secure connection to Microsoft 365 accounts
2. Bulk mailbox migration
3. Preserving folder hierarchy
4. Reducing downtime during the move
5. Avoiding duplicate data issues
One thing I’ve noticed is that running a small pilot migration first always helps. It gives a clear idea of how the actual migration will behave before moving all users.
Has anyone here worked on Office 365 to IMAP migration at scale? Would be good to know what approaches or tools worked best in your case and what challenges you faced during the process.
2 Replies
Good follow-up question. From what I've seen on real projects, the friction in Office 365 → IMAP moves isn't really the volume of mail — it's everything IMAP doesn't carry that people assume it will.
A few things worth calling out for anyone planning this:
IMAP only moves mail and folders. No calendar, no contacts, no tasks. If the target IMAP system doesn't have its own calendar/contacts layer, that data needs a separate export path (PST, CSV, whatever the target supports) or it just gets left behind — and that's usually discovered after the fact, not before.
Throttling is the silent killer on larger projects. Microsoft's EWS/Graph throttling kicks in faster than most people expect once you're pulling several mailboxes in parallel. A tool that retries automatically beats one that just dies and needs a manual restart every time.
Folder structure breaks in small, annoying ways. Deeply nested folders, special characters, oddly-named system folders — these are the spots where a migration "completes successfully" but the structure on the target doesn't actually match. Spot-checking a few mailboxes after the fact catches this faster than trusting the summary report alone.
Pilot first, always. Seconding what's already been said here — running one or two real mailboxes through first tells you more about how your specific environment behaves than any documentation will.
On the tooling side — I've used EdbMails for this exact scenario (Office 365 to IMAP) and it covers most of the pain points above: direct migration without needing PST as a middle step, folder hierarchy preserved as-is, incremental/delta sync so re-running a batch doesn't duplicate anything, and batch scheduling so you're not hammering the tenant all at once. It also does a pre-migration scan so you can see mailbox/folder sizes before committing to the full run.
Worth taking a look at this, learn.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/optimizing-imap-migrations
