Fixing Mailbox Quota Exceeded Errors During Migration

A 38GB Gmail mailbox finishes copying to a Microsoft 365 destination at 52GB and bounces with Quota exceeded halfway through the import of the user's "All Mail" folder. The math seems wrong — the source fit, why doesn't the destination? The answer is almost always one of three things: the destination cap is smaller than you assumed, Gmail's labels are inflating the move, or nobody applied the archive policy before kicking the migration off. Here's how to figure out which one is biting and how to clear it without restarting the whole transfer.

Why destination quota fills up faster than source#

The fundamental problem: Gmail and Outlook treat the same message storage very differently.

• Gmail uses labels. A message tagged with three labels is stored once but appears in three views. The raw RFC822 size on disk is one copy.
• Outlook uses folders. When that message lands at the destination, the migration tool has to put it somewhere. The standard approach: copy the message into each folder that corresponds to a source label. One message becomes three copies, each counted against the destination quota.

A 30GB Gmail mailbox with heavy label use (a power user with 8–10 labels per message average) can easily become a 60–80GB Outlook mailbox. That blows past the 50GB cap of a Microsoft 365 Business Basic or Standard license. Even an E3 user at 100GB can hit the wall if the source had aggressive labeling.

Other quota inflators:

• Sent Items duplication. Gmail's "All Mail" includes sent messages, and the migration tool may copy them to both Sent Items and All Mail/Archive, doubling counts.
• Deleted Items retention. Outlook keeps deleted items for 30 days by default. Anything you delete during cleanup still counts against quota for a month unless you purge.
• Online Archive not enabled. The Microsoft 365 archive adds 50–100GB of overflow capacity, but it has to be turned on per mailbox before migration starts.

For context on what to expect on Gmail-to-Outlook moves specifically, see the migrate Gmail to Outlook guide.

Diagnose first#

Before resizing licenses or buying storage, run a quick audit:

# Microsoft 365 destination
Get-MailboxStatistics user@destination.com | Select TotalItemSize, ProhibitSendReceiveQuota

# Gmail source
gam user user@source.com print mailboxsize

Compare the source raw size to the destination cap. If the source is more than 60–70 percent of the destination cap, you're at risk. If it's already over 90 percent on the destination mid-migration, stop and fix before continuing.

Step-by-step fix#

1. Stop the failed migration cleanly

   Don't kill the process — let it finish writing its in-flight batch and then pause. A clean pause means the resume picks up at the right point. A hard kill leaves orphaned messages that may duplicate on the next run.

2. Identify what's taking the space

   On Outlook destinations, Get-MailboxFolderStatistics user@destination.com | Sort FolderSize -Descending shows the biggest folders. Look for label-derived folders that duplicate content from All Mail or Inbox. On Gmail destinations, the Mail storage breakdown in the admin console shows the largest folders.

3. Enable Online Archive at the destination

   For Microsoft 365: Enable-Mailbox -Identity user@destination.com -Archive. Then set the archive policy to move items older than 1–2 years to the archive. The primary mailbox shrinks and the archive absorbs the old content. Auto-expanding archive can extend the archive to 1.5TB if the user qualifies.

4. Purge or relabel before resuming

   If the issue is Gmail label duplication, decide ahead of time which labels become folders and which become categories. Categories don't duplicate content; folders do. Mailbox Taxi lets you map labels to categories for non-primary labels, which keeps the destination size close to source.

5. Resume the migration with incremental sync

   Once destination space is freed, restart the migration. Incremental sync skips messages already at the destination using message-ID matching and resumes from where it stopped. This is much faster than starting over and avoids creating duplicates.

Special cases#

A few patterns where quota issues need a different approach:

• Shared mailboxes that crossed the 50GB cap. Microsoft 365 shared mailboxes get 50GB free, but if a help-desk shared mailbox is 80GB, you need to assign an Exchange Online license to it (which makes it count as a paid user) or split content into multiple shared mailboxes.
• Per-user retention disagreements. If the source had a 7-year retention policy and the destination has a 1-year archive policy, applying the destination policy mid-migration will purge content as it lands. Match retention policies before migration starts, not after.
• Auto-expanding archive activation lag. Enabling auto-expanding archive can take up to 30 days to provision the additional storage. If you need it for cutover next week, you need to enable it now.

For other space-related migration issues, the message too large fix covers individual oversized message failures, which present similarly but have a different root cause.

When you need to upgrade licenses#

If the math just doesn't work — your source is 90GB and the destination license tops out at 50GB even with archive — you have two real options:

1. Upgrade affected users to an E3 or E5 SKU for the migration window, then optionally downgrade once archive policy has moved old content out.
2. Use the migration as a forcing function for cleanup. Have users prune their own mailbox before cutover; most knowledge workers can drop 30 percent of their mailbox by deleting old newsletters and large attachments they no longer need.

The Office 365 migration guide covers license sizing in more detail, and the complete email migration guide explains how to fit quota checks into the broader pre-flight checklist. For the wider landscape of cutover failures, the email migration troubleshooting hub collects related issues.