Switching Email Clients With 100,000+ Emails in Your Inbox

A hundred thousand emails sounds like the kind of number that breaks a switch. In practice it does not, because almost none of that data actually moves. IMAP, Exchange and Microsoft Graph are protocols for viewing a server-owned mailbox — the new client authenticates, asks the server for a folder list, and downloads message metadata on demand. Nothing is copied out of Gmail or Microsoft 365 to make the new client work.

What does take real time is the back-fill: pulling headers, bodies and attachments for every one of those hundred thousand messages into the new client's local cache so browsing feels instant and offline search works. That is measured in hours, not seconds, and this post is about what to expect while it runs — what is usable right away, what trails behind, what the checklist should look like before you press connect, and how to switch without a working day of downtime.

What actually moves — and what doesn't — at 100,000+ emails#

The first thing to internalise is that the mail is already where it needs to be. On any IMAP, Exchange or Graph account, the authoritative store is the server, and every client is a window onto it. Adding a new client does not migrate mail; it opens another window. Your hundred thousand messages stay on Google's, Microsoft's, Fastmail's or your provider's storage exactly as they were.

What the new client does is build a local index and cache so it can render threads without a round-trip for every click. That is the work that takes time on a large account. RFC 9051 lets clients fetch only the message IDs and flags up front (cheap, seconds) and pull bodies lazily (expensive, paced by the provider). Every mainstream client uses that pattern; the difference between them is mostly how aggressively they back-fill and how much they keep offline.

Server-side features are unaffected by the volume. Gmail filters keep running. Outlook.com rules keep running. Vacation responders keep firing. Your folder tree — including deeply nested labels — appears in the new client as the server hands it over, usually within a minute or two. The parts that need patience are the ones that live locally.

Concretely, here is what you should expect to see when connecting a hundred-thousand-message account to a new client on a normal home or office connection:

• Folder tree, including nested labels: seconds to a couple of minutes. This is a single LIST call to the server.
• Last 30 to 90 days of mail, headers and bodies: minutes. Enough to start working immediately.
• The rest of the archive, headers only: an hour or so, sometimes less. Threads and dates render even before the body arrives.
• The rest of the archive, message bodies and attachments: several hours to a full day for around 100,000 messages, up to two days at 250,000+ or if your provider rate-limits aggressively.
• Client-side full-text search index: last to finish. Usually done overnight; on some clients it is a background job that keeps running for the first two or three days.

Pre-migration checklist for a large mailbox#

Ten minutes here save the entire switch. A hundred thousand messages is not the interesting number by itself — the interesting number is how much of it lives in places the new client will not automatically see, and how much bandwidth and time you are willing to spend on the back-fill.

• Confirm the account is IMAP, Exchange or Microsoft Graph. If it is POP, migrate to IMAP in your provider's settings first, or plan a full .mbox export before you touch anything. POP downloads and (by default) deletes mail from the server, so a POP-only archive of a hundred thousand messages lives entirely in the old client.
• Measure the mailbox. In Gmail, Settings shows storage used. In Outlook, right-click the account and pick Data File Properties → Folder Size. Note both the message count and the total gigabytes — a 100,000-message account can be 5 GB of text-heavy mail or 60 GB with attachments, and the back-fill scales with bytes, not messages.
• Check any local-only stores. Apple Mail's "On My Mac," Thunderbird's "Local Folders," any PST file, and any eM Client database is not on the server. Export those before you uninstall the old client; a hundred-thousand-message archive that is half local is easy to lose track of.
• Confirm every folder is subscribed. Some IMAP clients hide unsubscribed folders by default, which on a large account can look like half your tree is missing. If the new client's sidebar looks short, toggle "show all folders" or open subscription management before assuming a folder is gone.
• Ask the provider about limits, if you host your own IMAP. Cyrus, Dovecot and some hosted providers throttle simultaneous connections or bandwidth per account; a large back-fill can hit those limits and stall. Gmail and Microsoft 365 pace transparently and do not need any special handling.
• Pick a window with wall-clock time attached. A Friday afternoon connect leaves the whole weekend for the back-fill to finish; the archive is complete before Monday even if it takes 30 hours.
• Note anything the new client will not inherit. Signatures, snippets, client-side rules, Send Later queues, S/MIME private keys — none of these are folder data, but they are the small annoyances that make a switch feel bad when they are noticed for the first time on Tuesday morning.

The switch, step by step#

Once the checklist is done, the switch itself is fast to start. Order matters — the horror stories are almost always people who removed the old client's cache before the new one had finished pulling bodies, then panicked when a search returned less than they expected.

1. 1

   Install the new client. Leave the old one installed.

   Download from the vendor's site or an official store. Do not uninstall the old client for at least a week. Running two clients against the same account is exactly what IMAP, Exchange and Graph were built for — you are opening a second window onto the same mailbox, not making a second copy.

2. 2

   Add the account with OAuth or an app password.

   Gmail and Microsoft 365 use OAuth (three clicks, no password copied). iCloud, Fastmail and Yahoo need an app-specific password from account settings. Proton needs Proton Bridge running locally. The new client asks the server for the folder list within seconds of a successful sign-in.

3. 3

   Let the folder tree and recent mail appear — do not interrupt.

   System folders (Inbox, Sent, Drafts, Archive, Trash, Spam) show up in seconds. Custom folders and nested labels follow within a minute or two. Recent mail — usually the last month or three — renders within minutes and is fully usable. A folder that renders empty at this stage is not empty; the client has not asked for its bodies yet.

4. 4

   Start working. Let the archive back-fill in the background.

   There is no need to wait for the archive to finish before using the new client. Reply to new mail, triage, send. The client fetches older bodies in the background, paced by the provider. On a 100,000-message Gmail account, expect the last bodies to land somewhere between four hours and a day and a half after connect.

5. 5

   Configure sync-window settings if disk space is a concern.

   Most clients let you cap the local cache — "sync last 3 months / 1 year / all" or a size limit in gigabytes. On a laptop with tight disk, cap the local copy to a year and let older mail load on demand. Search on the server still finds it; only the offline copy is limited.

6. 6

   Import any local-only archives.

   If the checklist turned up "On My Mac" folders, a PST or an eM Client database, import them now. They become local folders in the new client too — still not on the server — but at least they live in the same app. On an old archive that is a big chunk of the perceived "hundred thousand," this is the difference between a complete archive and half of one.

7. 7

   Recreate signatures, snippets and client-only rules.

   Paste the signature text you saved. Recreate any rule that only lived in the old client, or promote it to a server-side rule (Gmail filter, Outlook.com rule) so the next switch inherits it automatically. Server-side rules keep firing across the change.

8. 8

   Run both clients in parallel for a week, then cut over.

   Both clients see the same server-side state; a folder rename, an archive or a reply in one shows up in the other within seconds. Once a week has passed with no missing folder and no search that came up empty, remove the old client. The mailbox on the server is untouched throughout.

What breaks — and what doesn't — at scale#

Volume by itself breaks very little. What breaks is scale meeting the exceptions from the previous section, and the honest inventory is worth having in front of you before you press connect.

Nothing in the table is unique to large mailboxes except the wall-clock time on the middle rows. A hundred thousand messages does not open a new category of failure; it just makes the back-fill row long enough to notice.

Rollback plan if the new client does not stick#

Because the old client stayed installed and the server was never touched, rolling back is a two-step operation. Open the old client — it re-syncs any changes the new one made during the parallel week — and remove the account from the new client. That is the whole rollback. No folders are destroyed, no messages are lost, no DNS record changes, no address moves. The mailbox on the server carried on being the mailbox on the server the entire time.

Any folder rename, archive or reply you did in the new client during the parallel week is already reflected on the server, so the old client picks up the same state on its next sync. That is the point of running two clients in parallel — different windows onto one mailbox, either window closes without consequence.

Doing the switch without downtime#

The lowest-stress version skips the concept of a cutover entirely. IMAP, Exchange and Microsoft Graph are all designed so multiple clients can share a mailbox in real time. Install the new client at lunch, do the ten-minute checklist, connect the account, and go back to work in the old client. When you next open the new one — an hour later, a day later — recent mail is already there, and the archive is quietly filling in.

In practice this means the wall-clock downtime for a switch on a hundred-thousand-message account is close to zero. The back-fill runs whether you are using the client or not. The parallel week is not a period of duplicated work; it is a period of two windows onto the same mailbox, where you drift into using the new one as it feels ready. If it never does, the old one is still there.

The one thing to plan for is bandwidth on metered connections. A 60 GB back-fill over a hotspot or a capped satellite link is not free, and no client tells you before it starts. On a laptop that lives on cellular, cap the sync window to the last six or twelve months at connect, then extend it later when the machine is on unmetered Wi-Fi.

Where AI Emaily fits when the mailbox is large#

We build AI Emaily, and it is worth naming here because a hundred-thousand-message account is exactly the setup that punishes clients built for the small case. Connect a Gmail, Outlook or plain IMAP account in the OAuth or app-password flow — a few minutes — and the folder tree renders as the server hands it over. Recent mail is usable inside the first minute; the back-fill runs in the background at the provider's pace, and search queries fall through to server-side search until the local index is ready, so the first day is not a blind window.

One honest limit: AI Emaily is a cross-platform Electron desktop app, not a native Swift binary. If your only account is Gmail and the top priority is the smallest possible memory footprint on macOS while the back-fill runs, Mimestream is the better fit and we would rather say so than pretend otherwise. AI Emaily does not have a permanent free tier — it is a seven-day free trial on Pro or Autopilot with the card taken and $0 charged if you cancel before day seven, so trying it against a live hundred-thousand-message mailbox costs nothing. See the current plans on the pricing page or start from the homepage.