Forum Discussion
Moving Office 365 Mailboxes to IMAP Servers - What’s the Best Approach
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.