Why Gmail and Microsoft 365 slow down migrations, and how to finish sooner

A migration that copied the first thousand messages in a minute and then crawls is not broken. Big providers protect their servers by limiting how fast one mailbox can send and receive mail over IMAP. Knowing the limits helps you plan.

What the limits look like

Google (Gmail and Workspace)

• Uploading: roughly 500 MB of IMAP uploads per account per day. A 10 GB mailbox can therefore take many days to fill over IMAP.
• Downloading: about 2,500 MB per account per day. Very large source mailboxes pause until the next day and continue.
• Signs of the limit: replies such as "[LIMIT]" or "Too many simultaneous connections".

Microsoft 365

• Throttling is per mailbox and per tenant; many parallel connections are answered with "try again later".
• The default message size limit is 35 MB (admins can raise it up to 150 MB). Larger messages are refused.
• Password sign-in for IMAP is switched off; connect with Microsoft sign-in.

What helps

1. Start early. The simplest fix for daily limits is time. Copy the history in the week before the switch and use an ongoing sync until then.
2. Keep parallelism moderate. More connections do not beat a rate limit; they just collect more refusals. The console caps parallel accounts and folders for each provider automatically and waits when a provider asks it to slow down.
3. Use the provider's API where possible. For Gmail targets connected with Google sign-in, messages are imported with the Gmail API instead of IMAP, which is considerably faster and keeps the original date.
4. Check large messages before you start. The size check lists messages above the new server's limit. Download those with an MBOX export instead of watching them fail.
5. Do not restart from scratch. Progress is saved per message; a restart continues where it stopped and skips what is already on the target.

Reading the estimate

The time estimate in the console assumes the server keeps up. When a provider starts limiting, the status page marks it "slowed by provider limits". The run keeps going on its own; it just finishes later than the first estimate.