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.

A 10 GB Google Workspace mailbox taking nearly two weeks through IMAP is unusually slow, so I would first check the migration throttling and Google Workspace-side limits rather than assuming split routing is the cause.

Exchange Online does apply throttling to IMAP migrations, and Microsoft recommends testing different migration batch sizes and concurrent connections to find a suitable level. On the Google side, bandwidth limits can also affect large mailbox migrations, particularly when there are many messages and attachments.

Split routing/coexistence mainly affects mail flow. If mail flow is already working normally, I would compare migration performance across a few test mailboxes before changing the coexistence setup.

If the standard IMAP migration remains too slow, a direct IMAP to IMAP route is another option. WholeClear IMAP to IMAP Migration connects the source and destination IMAP accounts directly using their credentials. It supports Google Workspace and Office 365, lets you select folders or apply date filters, and transfers emails with attachments while providing a migration report.

This can be useful when the requirement is to move mailbox data directly between IMAP accounts without creating intermediate mailbox files. However, it will not bypass provider-side throttling, so I would test it with a small mailbox first and compare the actual transfer speed.

A 10-GB mailbox taking two weeks is not automatically expected, but it can happen with IMAP because the migration service, source server, internet path, and batch concurrency all constrain throughput. Split routing normally affects mail flow rather than the data copy itself, so first prove the source connection from outside the network. Run several small, comparable test batches and record elapsed time, source IMAP connections, firewall limits, and Google-side quota or throttling events. In Exchange admin center, review the IMAP migration endpoint’s concurrent-migration setting; Microsoft documents 20 as the default and permits adjustment, but raise it gradually only while the source remains healthy. Also compare a test mailbox download through a normal external IMAP client. That separates source or network limits from Exchange Online. IMAP moves mail only, so if you require richer mailbox data or substantially higher throughput, assess Microsoft’s supported Google Workspace migration approach before changing coexistence design