Fix "Too Many Simultaneous Connections" IMAP Error

You're moving a batch of mailboxes and the migration log lights up with Too many simultaneous connections from the source server. Some mailboxes keep going, others stall, and restarting the job makes it worse. This is the per-account IMAP connection limit firing on the source side — almost every IMAP provider enforces one — and the fix is to lower the connection count, not to retry harder. The procedure below clears the immediate error and prevents it returning when you resume.

Why "too many simultaneous connections" happens#

Every IMAP server enforces a connection ceiling, and the limit is almost always per-account or per-IP rather than per-client. The migration tool is sharing that budget with everything else signed into the same account. Three causes account for the bulk of cases.

Per-account ceiling on the source provider#

Gmail caps each account at roughly 15 simultaneous IMAP connections. Yahoo sits around 10. iCloud is the strictest at about 5. Custom hosting providers running cPanel often default to 20 per account but 40 per IP. These are not throttles — they are hard refusals at the connection layer, returned as the first response on the new socket. The migration tool gets NO Too many simultaneous connections and the SSL session terminates immediately. See the IMAP protocol glossary for the underlying RFC behaviour.

Too many parallel mailboxes plus per-mailbox folder concurrency#

Most migration tools open more than one connection per mailbox. A typical setup uses one connection per folder being read in parallel, so a single mailbox with 5-folder concurrency burns 5 connections. Multiply by 20 simultaneous mailboxes and you're asking for 100 sessions against a server that may cap the IP at 40. The migration starts fine, then mailbox by mailbox the failures stack up as each new account pushes the count higher. Our IMAP migration guide covers concurrency planning in more depth.

Leftover stale sessions from previous runs#

This is the failure mode that confuses people most. You ran a migration yesterday, killed it because it was slow, and restarted today. The new attempt fails on connection one. The reason is the server still has yesterday's sessions in a half-open state — they were never properly closed because the client died ungracefully, and the server keeps them in its connection table until an idle timeout fires, which is usually 30 minutes. From your end the tool is restarted; from the server's end you're already at the limit.

If the source is Office 365 or Exchange Online, you won't hit IMAP connection errors but you may hit the equivalent EWS limit — the Office 365 throttling fix is the page for that.

Fixing the connection error — step by step#

1. Stop the migration cleanly, not by killing the process

   In your migration tool, press Stop and wait for it to report all sessions drained. This sends IMAP LOGOUT commands to the server, which clears the connections immediately. Force-quitting the tool skips this step and leaves sessions stuck on the server for up to 30 minutes.

2. Wait 30 minutes for any stale sessions to time out

   If you killed the previous job ungracefully, the only way to clear those sessions is the server-side idle timeout. Half an hour is the safe window for most providers. Resist the urge to retry sooner — every retry while sessions are stale just delays the timeout.

3. Sign out every other IMAP client on the source account

   Quit Apple Mail, Outlook, Thunderbird, and any phone mail apps signed into the source account. Each of those is holding 2–4 IMAP connections of its own. If you're migrating 10 mailboxes and one user has Apple Mail open on their MacBook, that's 30+ connections gone before the migration even starts.

4. Reduce per-mailbox folder concurrency to 2 or 3

   In the migration tool's settings, find the folder-concurrency or per-mailbox parallel setting and lower it. The default is often 5 or 10 because that maximises throughput on a single mailbox, but it murders your connection budget on a multi-mailbox batch.

5. Stagger mailbox start times by 60 seconds

   Instead of starting 20 mailboxes simultaneously, configure the tool to add one new mailbox to the queue every 60 seconds. Mailbox Taxi exposes this as the "start delay" setting. Staggering gives the server time to settle each session before the next batch hits it.

6. Re-run and watch the per-account connection count

   If the migration tool exposes per-account connection metrics, watch them on resume. You want each account's open-connection count to stay below 80 percent of the provider's known limit (12 for Gmail, 8 for Yahoo, 4 for iCloud). If you see it creeping higher, stop and lower concurrency further.

Preventing connection errors on the next run#

Treat the per-account limit as a hard budget and plan inside it. Before queuing a batch, multiply mailbox count by folder concurrency and check the total against the source provider's ceiling. If you're moving 30 Gmail accounts with folder concurrency 5, that's 150 connections — well over Gmail's combined IP limit if all 30 are at the same source IP. You need to either split the batch across multiple migration runs or reduce concurrency to 2.

Coordinate with the user before the cutover. Asking them to sign out of Apple Mail and the phone Mail app for the migration window saves a handful of connections per user and removes a common cause of failures. If the user's phone re-syncs mid-migration, it can briefly push the account over the limit and stall the job.

FAQ#

For the wider catalogue of stalls and errors that show up mid-migration, the email migration troubleshooting hub is the index.