Mailbox and Item Limits in Microsoft 365: What Migrates Cleanly and What Won't

Most migration planning conversations get to the same question within ten minutes: "will everything fit?" It is the right question, because Microsoft 365 enforces limits at several layers (the mailbox, the message, the individual item, the attachment) and a migration that ignores them finds out about each one the hard way, usually as a batch of skipped items discovered after cutover.

Here is how the limits actually stack up, what happens to data that exceeds them during a migration, and the planning moves that make the whole issue boring, which is what you want.

Mailbox quotas: the headline numbers

Mailbox storage in Microsoft 365 is set by license, and the standard published tiers look like this (always confirm against Microsoft's current service descriptions, since plans evolve):

Two practical notes hide in that table. First, shared mailboxes are free only up to a point: an unlicensed shared mailbox gets 50 GB, and the moment it needs more, or needs an archive, it needs a license. Companies migrating decades of "info@" and "orders@" history hit this more often than they expect. Second, the frontline plans are priced attractively but sized for light mail use; migrating a 30 GB mailbox onto one fails on quota, not on tooling.

Archives and retention: the pressure valve

The online archive is a second mailbox attached to the primary one, held server-side and visible in Outlook as its own folder tree. Combined with retention policies (for example, "move mail older than two years to the archive automatically"), it solves the problem that used to drive users to PST files: a primary mailbox filling up. During a migration it is also a routing tool. Old mail, imported PSTs, and departed-employee history can be landed directly in archives, keeping primary mailboxes fast and lean. If your environment is full of PSTs, our companion piece on finding, migrating, and retiring PST files covers that workstream end to end.

The gotcha: archives are not on every plan, and enabling expandable archiving where available is a policy decision with compliance implications, not a checkbox to flip casually. Decide the archive and retention design before the migration, because it changes where data should land.

Message and item limits: where migrations actually snag

Quotas rarely block a migration outright, because they are visible up front. The limits that bite mid-flight are the per-item ones:

• Maximum message size. Exchange Online defaults to a lower send/receive limit but can be configured up to 150 MB per message. Crucially, the receive limit also gates what a migration can inject into a mailbox: items larger than the configured maximum are skipped by migration tooling, not shrunk, not split, just skipped and logged.
• Attachment ceilings. Individual attachments face client-side and service-side caps below the message maximum, and old on-premises servers often allowed things Exchange Online will not.
• Folder and item-count limits. Exchange Online enforces generous but real limits on items per folder and folders per mailbox. A journaling mailbox or an ancient "Sent Items" with a million messages can degrade or hit limits.
• Deeply nested or malformed items. Calendar items with decades of recurrence exceptions, corrupted items from an aging on-premises database, and messages with malformed headers can all fail item-level validation and skip.

The single most important operational habit here: raise the target tenant's maximum message size to its ceiling before migrating, then review the skipped-item reports for every batch. Skipped items are recoverable while the source system still exists. After the old server is decommissioned, they are gone.

What migrates cleanly, and what will not

Planning moves that make limits a non-event

1. Measure before you license. Pull mailbox sizes and largest-item reports from the source system first. The license mix (who needs 100 GB-class plans, who is fine at 50 GB, which shared mailboxes need licensing) should be driven by data, not guessed.
2. Clean up where it is cheap. A mailbox at 62 GB often contains 15 GB of deleted items, calendar attachments from 2014, and duplicate PST imports. Sometimes an hour of cleanup beats a permanent license upgrade; sometimes it does not. Do the math per mailbox.
3. Set the tenant limits first. Message size to the maximum, archive policies designed, retention decided. Target configuration is a pre-migration task, not a post-migration one.
4. Treat skipped-item reports as a deliverable. Every batch produces one. Someone must own reading them and deciding, item by item or category by category, what gets manually recovered.
5. Keep the source alive until the reports are clear. Decommissioning the old server is the point of no return for anything that skipped.

Where a specialist changes the outcome

None of these limits is secret; they are all published. The difference a migration partner makes is sequencing and accountability: sizing the licenses from real data, configuring the tenant ceilings before the first batch runs, and owning the skipped-item reports so that "what didn't make it" is a short documented list handled before decommission, instead of a mystery discovered when someone searches for an old attachment next year. It is unglamorous work, which is exactly why it gets skipped when a migration is a side project. For us it is the job. And once the data is in, keeping quotas, archives, and retention healthy becomes an ongoing task; that is part of what managed Office 365 after the migration is for.