Fixing IMAP Throttling Errors During Migration

You started an IMAP migration at full speed, watched a few thousand messages move cleanly, and then everything slowed to a crawl. The log shows scattered reconnects, the throughput graph drops to a flat line, and somewhere in the output you spot the phrase Too many simultaneous connections. In other cases there is no error at all, just silent backoff while the provider quietly stops responding. This post walks you through diagnosing IMAP throttling and getting the transfer moving again without losing your checkpoint.

NO [LIMIT] Too many simultaneous connections. (Failure)

Why this happens#

Three root causes account for almost every IMAP throttling incident during a migration.

Concurrent connection limits per account. Every major provider applies a hard ceiling on simultaneous IMAP sessions for a single mailbox. Gmail sits around 15, Office 365 around 10 (often lower for new tenants), Yahoo around 5, and iCloud is stricter still. Migration tools that open one connection per folder hit this limit fast on a mailbox with 40 labels.

Aggressive default settings in your tool. Out of the box, many migration utilities default to 16 or 32 worker threads because that maximises throughput on a private mail server. Pointed at a public provider, the same defaults trigger throttling within minutes. The tool then either reconnects in a loop (making it worse) or sits idle waiting for responses that never come.

Shared IP reputation. If the source or destination provider sees a large number of IMAP requests coming from a known shared host (a VPS provider, a corporate NAT gateway, a residential ISP that another customer abused last week), it can throttle pre-emptively. The connection limit drops below the documented number and you hit the ceiling earlier than expected.

Fix it now#

1. Confirm the throttling signal

   Open your migration log and search for Too many simultaneous connections, LIMIT, BYE, or repeated CONNECT / LOGIN cycles within seconds of each other. If you do not see an explicit error but throughput has flatlined, that is silent backoff and counts as throttling. Note the timestamp of the first slowdown so you can resume from the right checkpoint later.

2. Lower concurrent connections to 4

   In your migration tool's settings, find the worker or thread count (sometimes labelled "Concurrent connections per mailbox" or "Parallel folder fetches") and drop it to 4. This is the number that almost always works across Gmail, Office 365, Yahoo, iCloud, and Zoho without further tuning. You can raise it later once the run is stable.

3. Enable exponential backoff

   Turn on adaptive or exponential backoff so that, after a throttling response, the tool waits 30 seconds, then 60, then 120, rather than retrying immediately. Mailbox Taxi uses exponential backoff by default for any NO LIMIT or BYE response. If your current tool retries in a tight loop, you are reinforcing the throttle every time you try to reconnect.

4. Stagger mailbox starts

   If you are running more than one mailbox concurrently, do not start them all at the same second. Stagger them by 60 to 120 seconds. Most providers apply tenant-wide limits in addition to per-account ones, so 30 mailboxes opening 4 connections each at the same instant still looks like a denial-of-service attempt from the provider's point of view.

5. Switch to OAuth2 or an app password

   Several providers apply different quotas depending on the authentication method. Gmail and Office 365 in particular are noticeably more tolerant of OAuth2 sessions than of legacy password auth. If you are still using a regular password, switch to OAuth2 if your tool supports it, or generate an app-specific password and use that instead. For more on the protocol mechanics, see the IMAP protocol glossary.

6. Resume from the last completed UID

   When you restart, do not re-scan the whole mailbox. A good migration tool stores a per-folder checkpoint of the last completed UID. Resume from that checkpoint so the source server only has to enumerate new messages, which uses fewer connections and a lot less time. If your tool does not store UID checkpoints, that is the bigger problem to fix and is covered in the email migration troubleshooting hub.

7. Re-test on a small mailbox first

   Before kicking the full batch off again, pick one of the smaller mailboxes (under 2GB) and run it end to end at the new settings. If it completes without a single LIMIT line in the log, your numbers are safe and you can scale back up. If it still throttles, drop concurrent connections to 2 and add 90 seconds of stagger between mailboxes.

How to prevent it next time#

Plan migrations around the provider's published or community-known limits before you touch a setting. For Office 365, see the linked Office 365 throttling fix for tenant-specific guidance. For Gmail and Google Workspace, the safest defaults are 4 to 8 connections per mailbox and a 60-second stagger.

Run migrations off-peak. Provider rate limits are often softer at 2am local time than at 10am, and your own users are less likely to be active on the source mailbox, which means fewer competing connections.

Keep the migration tool on a dedicated machine or VM. Shared workstations that also run Outlook, sync clients, and browser tabs can themselves hold IMAP connections open, eating into the quota before the migration even starts.

Finally, follow a documented runbook. The IMAP migration guide and duplicate emails fix cover the surrounding work that makes a throttle recovery clean rather than chaotic.