Blog/ Switching and migration

Do IMAP Folders Move When You Switch Email Clients?

Nafiul HasanNafiul Hasan· 14 min read
AI Emaily blog cover for do IMAP folders transfer when you switch email clients, showing a nested folder tree on a mail server rendered inside two different client apps

The short answer

Yes — IMAP folders live on the mail server, not inside the client, so a new client signs into the same account and re-renders the same tree. The three cases where folders appear to "go missing" are POP accounts, local-only folders that were never on the server, and Gmail labels rendered under a client's own naming rules.

Do IMAP folders transfer when you switch email clients? Yes — folders live on the server, so a new client subscribes and re-renders the same tree.

On this page
  1. 01What actually moves — and what doesn't
  2. 02Pre-migration checklist
  3. 03The switch, step by step
  4. 04What survives an IMAP client switch — and what doesn't
  5. 05The rollback plan, if the new client does not stick
  6. 06Doing the switch without any downtime
  7. 07Where AI Emaily fits in this switch

The short answer is yes. IMAP folders are server-side objects — the mail account owns them, not the app. When you install a new client and sign in, it subscribes to the same folder list your old client saw, and the same tree re-renders within a few minutes. Nothing has to be moved, migrated or re-uploaded.

What does not survive is anything the old client kept to itself: a folder that only ever lived on your disk, an account whose protocol was POP rather than IMAP, or a client-proprietary storage format like an Outlook PST or an eM Client database. This post walks through what moves automatically, what does not, the ten-minute checklist that keeps the exceptions from biting, the switch step by step, and how to roll back if the new client is not for you.

What actually moves — and what doesn't#

The IMAP protocol (specified in RFC 9051) treats a mailbox as a shared server resource. The client authenticates, asks the server to LIST mailboxes, subscribes to the ones it wants to display, and downloads message metadata on demand. Folders, folder hierarchy, message flags (read, replied, flagged, deleted), and the messages themselves are all stored on the server. The client is a viewer, not a container.

That is why running two clients against the same IMAP account is expected behaviour rather than a bug — both are looking at the same mailbox through different windows. Create a folder in one client, and the other sees it appear on its next sync. Mark a message read in one, and the other loses the bold within seconds. Nothing is duplicated, because there is nothing to duplicate; there is one mailbox on one server and every client is a view of it.

The corollary is that installing a new client cannot cost you folders that were on the server, because it never touches them. It reads them. Uninstalling the old client removes that client's local cache, and the cache was a copy of what is still sitting on Gmail's, Fastmail's, iCloud's or your provider's storage anyway.

Diagram of an IMAP mail account on a server with a folder tree — Inbox, Sent, Archive, and custom nested folders — being rendered simultaneously by two different email client apps
The folder tree lives on the server. Any number of clients render the same tree; none of them own it.

There are three genuine exceptions where a folder can appear to "go missing" after a client switch. Each is worth naming clearly, because none of them is IMAP's fault and each has a specific fix:

  • The account is POP, not IMAP. POP was designed to download messages and (by default) delete them from the server. Any folders in a POP setup are strictly local — the new client will not see them because they were never anywhere else.
  • The folder was local-only in the old client. Apple Mail "On My Mac," Thunderbird "Local Folders," an Outlook PST file, and any folder created inside a client-only store never traversed IMAP. They live inside that client's data files.
  • The client uses a proprietary storage format. eM Client's database, older Postbox stores, and Outlook's PST/OST files are client-native containers. Even for an IMAP account, any folder that the client filed to its own store instead of to the server is not on the server.

There is also a fourth case that is not really a missing folder but reads like one — a Gmail account. Gmail exposes labels through IMAP as folders, but its "All Mail" and system labels (Important, Starred, Chats) are rendered differently by different clients. If a nested label like Work/2026/Q3 shows up under a slightly different hierarchy in the new client, or if "All Mail" is hidden, the folder has not moved; the client is showing the same server-side object with its own naming rules. The Gmail help page for third-party clients spells out how each label maps.

How to tell whether your account is IMAP or POP

Open the old client's account settings and look at the incoming-server section. It will say IMAP, POP (or POP3), or (for a Microsoft 365 account) Exchange, EWS or Graph. If it says POP, do the export step in the checklist below before you install anything new. If it says IMAP, Exchange or Graph, your folders are on the server and the switch is safe.

Pre-migration checklist#

Spend ten minutes on this before you press install. Each item on the list is a self-inflicted problem to prevent rather than a limit of the protocol — the switch itself is short, but the exceptions above have a way of arriving in the middle of it.

  • Confirm the account type is IMAP, Exchange or Graph. If it is POP, either migrate the account to IMAP (Gmail, Outlook.com, Fastmail, iCloud and Yahoo all offer this in account settings) or plan a full local-mail export before you touch the old client.
  • Screenshot the sidebar. If you rely on a deep nested folder tree — Clients/Acme/2026, for example — capture it as a reference so you can spot the moment when the new client has finished subscribing.
  • Note the mailbox size. In Gmail, Settings shows storage; in Outlook, right-click the account and pick Data File Properties → Folder Size. Under 5 GB is small; 50 GB or 100,000+ messages is large and will take real time to back-fill.
  • Look inside "Local Folders," "On My Mac," and any PST or eM Client database. Those folders are not on the server. Export anything you want to keep as .mbox or .pst before the old client comes off the machine.
  • Confirm your folders are subscribed. Some clients show only subscribed IMAP folders by default; if the new client's sidebar looks short, the folders are probably there and hidden rather than missing.
  • Note client-only conveniences that will not travel — signatures, snippets, client-side rules, Send Later queues, S/MIME and PGP private keys. None of these are folder data, but each is easy to forget until it is gone.
  • Pick a low-stakes window. A Friday afternoon or Saturday morning lets the initial sync finish overnight so the archive is fully back-filled before Monday.

The switch, step by step#

Once the checklist is done, the switch itself is short. The order matters — the "my folders disappeared" stories are almost always people who removed the old client's data before the new one had finished subscribing.

  1. 1

    Install the new client. Leave the old one installed.

    Download from the vendor's site or an official store. Do not uninstall or reset the old client — for the next week it is your safety net, and running two clients against the same IMAP account is exactly what the protocol was built for.

  2. 2

    Add the account (three to ten minutes).

    Sign in with OAuth for Gmail or Microsoft 365, or paste an app-specific password for iCloud, Fastmail, Yahoo or Proton Bridge. The new client asks the server for the folder list and starts subscribing.

  3. 3

    Watch the folder tree appear — do not interrupt.

    System folders (Inbox, Sent, Drafts, Archive, Trash, Spam) appear in seconds. Custom folders follow within a minute or two. If the tree looks incomplete after ten minutes, check the client's IMAP settings for "Show only subscribed folders" and toggle it off.

  4. 4

    Let messages back-fill in the background.

    Recent mail (usually the last 30 to 90 days) appears within minutes. Bodies and attachments for the full archive pull over hours or up to two days on a large Gmail account. A folder that renders empty at first is not empty — the client has not asked for its messages yet.

  5. 5

    Import any local-only archives.

    If the checklist turned up "On My Mac" folders, a PST, or an eM Client database, import them into the new client. They become local folders there too — still not on the server — but at least they are in one place.

  6. 6

    Recreate signatures 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 so future switches inherit it. Server rules (Gmail filters, Outlook.com rules) keep running untouched.

  7. 7

    Run both clients side by side for a week.

    Both see the same server-side mailbox; a folder rename, an archive, or a reply in one shows up in the other within seconds. This is the ground-truth check that nothing is missing before you commit.

  8. 8

    Cut over on day 7 to 14, then uninstall the old client.

    Once a week has passed with no missing folder, no failed rule, and no shortcut you cannot live without, remove the old client. Nothing on the server was touched; the account is untouched.

What survives an IMAP client switch — and what doesn't#

The list of things that survive is much longer than the list of things that break, but the exceptions cause almost all of the frustration. This is the honest inventory.

ItemSurvives the switch?Why / what to do
IMAP folders and nested folder hierarchyYesServer-side objects listed via IMAP LIST. The new client subscribes and re-renders the tree.
Messages inside those foldersYesDownloaded on demand from the server. Full archive back-fills over hours to a day.
Read / unread, flagged, replied, deleted flagsYesIMAP flags live on the server per RFC 9051. Every client sees the same state.
Gmail labels (as IMAP folders)YesLabels are exposed as folders; nested labels appear as nested folders. Naming may look slightly different per client.
Server-side rules and filtersYesGmail filters and Outlook.com rules run on the server, not the client. Unaffected.
Auto-reply / vacation responderYesConfigured on the server for Gmail and Outlook.com. Keeps firing untouched.
Local-only folders (On My Mac, Local Folders, PST)NoNever on the server. Export as .mbox or .pst before uninstalling and import into the new client.
Client-proprietary databases (eM Client, older Postbox)NoClient-native storage. Export first, or run the vendor's own migration tool.
POP-only mail that was downloaded and deleted from the serverNoExists only in the old client. Export as .mbox before removing the old install.
Client-only rules (rules stored inside the client, not on the server)NoDie with the old client. Recreate in the new client, or promote to server-side rules.
Signatures, snippets, canned responsesNoStored per client. Copy the text out before you close the old client for good.
Snoozed messagesSometimesGmail snooze is server-side and survives. Most client-specific snooze features do not.
Send Later / scheduled sendsUsually noClient-side queues that only fire while the client is running. Reschedule pending items in the new client.
S/MIME and PGP encrypted mailPartialThe encrypted messages sync via IMAP; readability depends on carrying the private key across.

Everything in the "Yes" rows requires no action beyond patience while the initial sync completes. Everything in the "No" and "Sometimes" rows is why the checklist exists — each has a five-minute fix in isolation, but skipping them compounds into what looks like folder loss and is really just data left behind on the machine the new client cannot see.

The rollback plan, if the new client does not stick#

Because you kept the old client for a week and nothing on the server was touched, rolling back is a two-step operation: open the old client (it re-syncs any changes the new one made) and remove the account from the new client. That is the whole rollback. No folders are destroyed, no messages are lost, no DNS record is touched, no address is changed. The mailbox on the server carried on being the mailbox on the server throughout.

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 — they are just different windows onto one mailbox, and either window can close without consequence.

Do not delete the old client's local cache in a panic

If the new client seems to be missing folders during the first sync, wait. Do not go into the old client and export-then-delete the local store to "start fresh" before the back-fill finishes. On a large Gmail account it can take a full day before every archived message reappears in the new client. That is expected; the messages and folders are on the server, and the pull is paced by the provider on purpose.

Doing the switch without any downtime#

The lowest-stress version of the switch 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, connect the account, and leave the old one running. Both apps talk to the same server; a folder created in one appears in the other on the next sync; a read in one is a read in the other within seconds.

In practice this means the total downtime for a client switch can be zero. Do the ten-minute setup on the new client at lunch, use it for real work in the afternoon, and switch back to the old client the moment anything is missing or feels wrong. After a few days of running side by side you know which one you actually want, and the transition is done without a dedicated hour of "switching."

Where AI Emaily fits in this switch#

We build AI Emaily, and the reason to mention it in a post about IMAP folders is narrow: it is built for exactly this kind of low-friction, reversible switch. Connecting a Gmail, Outlook or plain IMAP account is an OAuth flow or an app-password paste — usually three minutes — and folders re-render as the server-side tree, nested labels and all. Nothing is copied out of your provider; the archive back-fills in the background; uninstalling later is as fast as connecting.

One honest limit: AI Emaily is a cross-platform Electron desktop app rather than a native Swift binary. If your only account is Gmail and you need the smallest possible memory footprint on macOS, 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 a real evaluation with your live mailbox costs nothing.

Frequently asked

Nafiul Hasan

Written by

Nafiul Hasan

Nafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.

EntrepreneurAI Automation System BuilderAI EnthusiastBuilds AI Enterprise Solutions10+ years experience
More from Nafiul
Ready when you are

Switch email clients and keep every folder exactly where it was.

AI Emaily connects to Gmail, Outlook or any IMAP account in about three minutes, re-renders your existing folder tree from the server, and leaves the server untouched — so trying it is fully reversible. Seven-day free trial on Pro or Autopilot, card taken and $0 charged if you cancel before day seven.

  • 7-day free trial
  • Cancel anytime
  • Every provider