Migrating a single Accounts Payable mailbox from Google Workspace to Exchange Online should have been the easy part of a larger phased migration. It wasn’t. The mailbox was 100GB+ with 600,000+ items, which put it past Exchange Online’s standard migration path and into Large Archive Onboarding (LAO) territory. LAO is the only supported mechanism for migrating a mailbox this size from Gmail while splitting content between primary and archive by date or folder.
Nothing in Microsoft’s documentation or tooling points you to this. The migration failing due to size? Nope. The normal documentation mentioning it as a caveat? Think again.
The mechanics of LAO itself worked. What cost the time was everything Microsoft’s documentation doesn’t mention about running it.
How We Got Here
This mailbox went through the standard Gmail-to-Exchange-Online migration batch first, the same as every other account in the tenant. Single-user batch, provisioned as a licensed mailbox, sync kicked off, no reason to expect anything different from the dozens of accounts that had already migrated cleanly.
It synced. Then it stalled.
Get-MigrationUserStatistics showed a DataConsistencyScore of Investigate and a growing pile of MapiExceptionStorageShutoffQuotaExceeded failures. Nothing about that error name, or anything in the migration batch status, says “your mailbox is over the primary quota ceiling and content is being silently dropped.” It reads like a generic storage fault. The actual explanation took cross-referencing TotalItemSize against ProhibitSendReceiveQuota by hand to confirm what was happening.
Once the quota problem was identified, the obvious fix was to get old content out of the primary mailbox and into the archive before resyncing. That’s where the second round of undocumented friction started. Enabling the archive mailbox does nothing on its own — it just provisions an empty secondary mailbox. Getting content into it requires the Managed Folder Assistant to actually run and act on a retention policy tag, and Start-ManagedFolderAssistant doesn’t trigger immediate processing. It queues the mailbox for eventual processing on Microsoft’s own schedule, with a stated SLA of up to seven days. Not something you can rely on for an active blocker.
Forcing a -FullCrawl got further, but even that failed outright on the first attempt — a ResourceUnhealthyException tied to disk latency on the backend database, a fault entirely on Microsoft’s infrastructure side, with the retry lock left in a stuck state afterward. A second attempt eventually got real tagging progress, but tagging items and physically relocating them turned out to be two separate passes; thousands of tagged items sat with zero corresponding movement into the archive folder structure for hours.
In parallel, manual relocation was attempted directly by dragging content from primary to the in-place archive via Outlook. In the web client, this didn’t work at all. In the thick desktop client it did work, but at 600,000+ items and 100GB, the client’s memory footprint made it functionally unusable, locking up repeatedly with no way to scope what got cached locally due to Microsoft’s new online-only style of Outlook.
None of this — not the quota error name, not the archive/MFA behavior, not the thick-client limitations — ever pointed toward LAO as the actual answer. LAO surfaced only from directly searching Microsoft’s own documentation for large-mailbox migration guidance, independent of anything the failing migration batch, its error messages, or its status reporting had suggested. The tooling you’re actively using to run the migration gives you zero signal that a different, purpose-built tool exists for exactly this situation.
The Quota Wall
Exchange Online caps a primary mailbox at 100GB. Hard ceiling, not configurable, not raisable by admin action regardless of license tier. This is documented, if you go looking for it.
What isn’t documented anywhere in the LAO migration guide: what happens when your source mailbox is already larger than that ceiling and you’re mid-migration. The answer is MapiExceptionStorageShutoffQuotaExceeded — a MAPI-layer error that fires once TotalItemSize crosses ProhibitSendReceiveQuota, silently converting every subsequent write attempt into a skipped item until the batch either finishes what was already in flight or gets manually intervened on.
The LAO documentation’s own quickstart example splits content by date into Primary and up to three Auxiliary Archives, explicitly to solve the “too big for one mailbox” problem. But nowhere does it flag that the initial provisioning of the target mailbox, before your content filter mapping ever gets evaluated, can hit this same ceiling if your date cutoff isn’t aggressive enough. I found this out by watching a migration batch cycle between Synced and SyncedWithErrors with no useful message beyond a generic skipped-item count, then had to reconstruct the actual MAPI error from raw diagnostic logs pulled via Export-MailboxDiagnosticLogs, not from anything the migration batch status surfaced directly.
Get-MailboxStatistics -Identity "[email protected]" | Select-Object TotalItemSize
Get-Mailbox -Identity "[email protected]" | Select-Object ProhibitSendReceiveQuota
If those two numbers are close, LAO will eventually hit this regardless of how carefully your content filter XML is written, because the filter only controls where content ends up, not how much has to pass through the primary target’s write path before the split settles.
ELC Will Fight You, and the Prerequisite Is Buried
LAO’s documentation does mention this one, technically, in a single bullet:
Run the cmdlet to disable ELCProcessing before creating LAO migration batch. If it’s not disabled, the folders might be moved by ELC during LAO, and the LAO migration might be blocked.
That’s it. One line, easy to skip past on a first read, with no explanation of what “blocked” actually looks like in practice. In practice it looks like this:
Fatal error ELCProcessingNotDisabledPermanentException has occurred.
…printed once, mid-sync, with the batch simply stopping. No retry, no partial recovery message pointing you at the fix — just a dead sync and a generic status until you go digging into the raw request log.
The bigger gap: this isn’t a one-time setup step you do once per tenant. It’s per-mailbox, and it doesn’t survive a mailbox rebuild. If you ever have to delete and recreate the target mailbox mid-migration — which, more on that below, might happen — every setting you configured against the old mailbox’s GUID, including ELCProcessingDisabled, is gone. The new mailbox starts with ELC fully active and no warning that it’s about to collide with a migration batch that’s already running against it.
Content Filter Folder Naming Isn’t Documented at All
LAO’s XML content mapping lets you split a mailbox by date into Primary and Archive targets:
<Folder Name="/*">
<Mapping ContentFilter="Received -gt '2025/1/1'" Target="Primary" />
<Mapping ContentFilter="Received -le '2025/1/1'" Target="MainArchive" />
</Folder>
What the documentation does not say anywhere: when a folder gets split by date, LAO does not merge the older content into the archive’s equivalent well-known folder. It creates a new, separately-named folder — Sent Items_before 2025/01 — sitting alongside the archive’s own Sent Items.
This matters if you’re trying to verify migration completeness the way any reasonable admin would: comparing item counts folder-by-folder between source and target.
Get-MailboxFolderStatistics -Identity "[email protected]" -Archive -FolderScope SentItems |
Select-Object Name, ItemsInFolder
That command, scoped to the well-known SentItems folder type, will report 0 items even when hundreds of thousands of messages landed correctly — because they’re sitting in a folder that doesn’t match the scope filter at all. I spent time thinking 105GB of transferred data had vanished, before realizing the folder list itself held the answer: every folder that had a date split got a _before <date> suffix appended, silently, with no mention of this behavior in the LAO documentation.
Get-MailboxFolderStatistics -Identity "[email protected]" -Archive |
Select-Object Name, ItemsInFolder, FolderSize |
Sort-Object FolderSize -Descending
Run the full unscoped listing first. Every assumption about folder-scoped verification commands needs to be thrown out once a date-based content filter is in play.
The Skip/Failure Reporting Doesn’t Tell You What You Think It Does
Get-MigrationUserStatistics -IncludeSkippedItems -IncludeReport is the documented way to check on a migration’s health. It reports a SkippedItems collection and a Report.Failures collection, and the natural assumption is that between the two, you have full visibility into anything wrong with the migration.
You don’t. During active sync, I pulled the raw MRS request log directly and found nearly 35,000 discrete skip events on a single folder across a 90-minute window — the same batch of content getting reported as changed by the source, reattempted, and skipped, over and over, in a loop that never resolved cleanly within that log window. Get-MigrationUserStatistics reported SkippedCount: 0 the entire time. Whatever internal mechanism generates that skip loop at the MRS level doesn’t promote to a formal SkippedItem record with the metadata (Kind, Subject, Failure) that the reporting cmdlets expose.
The only way I found to confirm the data actually landed correctly despite this was to bypass Microsoft’s reporting entirely and do an independent count comparison against the source:
gam user [email protected] print messages query "in:sent after:2025/01/01" countsonly
Run against the corresponding Exchange folder count, on both sides of the date split. They matched exactly. But that’s not something Get-MigrationUserStatistics told me — it’s something I had to go verify manually, with a completely separate tool, because the migration’s own reporting layer wasn’t capturing the failure mode that was actually happening.
Practical Takeaways
1. Check quota headroom before trusting your content filter cutoff. Your date split has to leave real margin under 100GB on whatever’s routing to Primary, and LAO won’t warn you if it doesn’t — you’ll just start accumulating MapiExceptionStorageShutoffQuotaExceeded skips partway through.
2. ELCProcessingDisabled is per-mailbox-object, not per-tenant, and doesn’t survive a rebuild. If you delete and recreate the target mailbox for any reason mid-migration, re-set it before restarting the batch, or it’ll fail silently on the first ELC pass.
3. Never trust folder-scoped verification commands on a mailbox that went through date-based content filtering. Pull the full unscoped folder list first. The content is very possibly there, under a name you didn’t expect.
4. SkippedCount: 0 is not proof nothing went wrong. If a migration’s behavior in the batch status doesn’t match what you’d expect from the volume involved, pull the raw diagnostic logs via Export-MailboxDiagnosticLogs and read the actual MRS request/response cycle. The summary statistics are a starting point, not a source of truth.
5. Independently verify item counts against the source system when the stakes justify it. For a financial mailbox with legal/compliance weight behind its contents, “the migration tool says it’s fine” isn’t sufficient confirmation on its own.
Conclusion
LAO works. The mechanism for splitting a large mailbox across primary and archive targets by date is sound, and once everything is configured correctly, it moves real volume reliably. But “once everything is configured correctly” is doing a lot of work in that sentence, and Microsoft’s documentation gets you maybe sixty percent of the way there. The rest — the quota interaction, the ELC rebuild trap, the folder naming behavior, the gap between what the reporting cmdlets show and what’s actually happening at the replication service level — you find by hitting it, or you find by reading this post before you hit it.
If you’re planning an LAO migration for a mailbox anywhere near the 100GB primary ceiling, budget time for all four of these, not just the one the documentation happens to mention.