IMAP Mail Migration

Two weeks for a 10 GB mailbox is slow enough to investigate, but first distinguish an initial copy that hasn’t finished from a mailbox that has finished and is simply continuing incremental synchronisation. An IMAP batch can remain active during coexistence without still copying the original 10 GB.

Start with the per-mailbox migration report, not just the batch status. In Exchange Online PowerShell:

Get-MigrationUserStatistics -Identity email address removed for privacy reasons -IncludeReport | Format-List Status,StatusDetail,SyncedItemCount,SkippedItemCount,Error,Report

Compare the results at two different times. Check whether the item count is increasing and whether the report shows throttling, repeated disconnects, authentication failures, or the same folders being retried.

For your questions:

1. Size alone doesn’t predict migration time. Message count and folder count matter considerably. Gmail labels exposed as IMAP folders can also make the workload larger than the mailbox’s reported storage size suggests.
2. Both services can limit throughput. Exchange Online applies migration throttling and resource controls. Google applies IMAP bandwidth and connection limits. Don’t assume Exchange PowerShell throttling settings control migration throughput, or that adding concurrency will bypass a limit.
3. Split routing isn’t normally a direct IMAP bottleneck. Mail delivery and mailbox copying are separate operations. However, continued activity in Gmail adds incremental work, and routing loops or duplicate delivery can increase what needs copying. Keep coexistence in place if required; disabling it isn’t a necessary first troubleshooting step.
4. There’s no universal optimal batch size. Batch size and active connection concurrency are different. Check the endpoint settings:

   Get-MigrationEndpoint |        
          Format-List Identity,EndpointType,MaxConcurrentMigrations,MaxConcurrentIncrementalSyncs

   Test a small group first, then increase concurrency gradually while monitoring completed items and errors. If throughput doesn’t improve or throttling increases, back it down. A single slow mailbox won’t necessarily benefit from more mailbox concurrency.
5. On Google’s side, review IMAP bandwidth usage, simultaneous connections, and other clients accessing the same mailboxes. Gmail API quotas aren’t the primary limit for a genuinely IMAP-based job; they matter when using an API-based migration method. Also review how labels and All Mail are exposed to IMAP before deciding which folders to migrate.
6. Consider Microsoft’s dedicated Google Workspace migration workflow. It supports mail, calendar, and contact migration, whereas generic IMAP migration covers email only. It’s worth evaluating for this project, but it isn’t a guaranteed speed increase. Plan a pilot and the handling of already-migrated data before switching methods.

Microsoft’s documented Google Workspace migration workflow includes coexistence routing prerequisites, so continued coexistence does not by itself require you to stay with generic IMAP.

Useful starting points are Microsoft Learn’s https://learn.microsoft.com/en-us/exchange/mailbox-migration/perform-g-suite-migration and Google’s https://support.google.com/a/answer/1071518.

If the initial copy really is making negligible progress, open a Microsoft support case with the mailbox migration report, endpoint settings, timestamps, and item-count changes. That gives support evidence to distinguish Exchange-side delays from source throttling or repeated retries, rather than treating the two-week duration as a diagnosis.