Exchange Online Migration: What the Documentation Won't Tell You

Microsoft's documentation for Exchange Online migration is thorough. It walks you through hybrid configuration, endpoint setup, migration batches, and cutover. What it doesn't cover: the three things that actually cause problems.

Public folders

Public folders are the Exchange feature that everyone uses and nobody admits to using. They've been "deprecated" since about 2008 and yet every migration I've done has uncovered at least one business-critical process that depends on them.

The migration tooling for public folders works. The problem is discovery: nobody knows what's in their public folders. Before migrating, I export the entire public folder hierarchy to CSV and send it to department heads with one question: "does your team use any of these?" Half of them don't respond. Of those who do, half say "I think so." The other half say "what's a public folder?"

Migrate them anyway. If you don't, you'll discover which ones were critical when someone files a ticket Tuesday morning.

Mailbox size limits

Exchange Online mailboxes have limits: 50GB for most plans, 100GB for E3/E5 with archiving. On-prem Exchange had no practical limits because storage was "free" (already paid for).

Every migration has users with mailboxes over 50GB. Usually executives. They've been cc'd on everything since 2009 and their Sent Items folder alone is 30GB. Telling them they need to delete email is a political problem, not a technical one. I bring it up early, with data, and let management decide. I don't make the policy. I enforce it.

Auto-mapping and shared mailboxes

Shared mailboxes that auto-map to users via group membership: this works differently in Exchange Online than on-prem. The migration documentation says it's handled automatically. It's not. Group-based auto-mapping has specific prerequisites that on-prem environments often don't meet.

I test this with a pilot group before the full migration. Every time, there's at least one shared mailbox that doesn't auto-map correctly. Every time, the fix is a PowerShell script that re-maps the permissions. Budget time for this. The documentation won't mention it.

The one thing that always works

The actual mailbox migration — bytes from point A to point B — works reliably. Microsoft has been doing this for years and the infrastructure is solid. The problems are always in the periphery: the features that straddled the line between Exchange and AD, the configurations that accumulated over a decade of on-prem management, the user expectations that don't match how the cloud works.

Migrate the mailboxes first. Solve the edge cases second. And don't trust anyone who says "oh, we don't use public folders." They do. They just don't know it.