Do IMAP Folders Move When You Switch Email Clients?

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
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.

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
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
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
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
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
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
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
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
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
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.
| Item | Survives the switch? | Why / what to do |
|---|---|---|
| IMAP folders and nested folder hierarchy | Yes | Server-side objects listed via IMAP LIST. The new client subscribes and re-renders the tree. |
| Messages inside those folders | Yes | Downloaded on demand from the server. Full archive back-fills over hours to a day. |
| Read / unread, flagged, replied, deleted flags | Yes | IMAP flags live on the server per RFC 9051. Every client sees the same state. |
| Gmail labels (as IMAP folders) | Yes | Labels are exposed as folders; nested labels appear as nested folders. Naming may look slightly different per client. |
| Server-side rules and filters | Yes | Gmail filters and Outlook.com rules run on the server, not the client. Unaffected. |
| Auto-reply / vacation responder | Yes | Configured on the server for Gmail and Outlook.com. Keeps firing untouched. |
| Local-only folders (On My Mac, Local Folders, PST) | No | Never on the server. Export as .mbox or .pst before uninstalling and import into the new client. |
| Client-proprietary databases (eM Client, older Postbox) | No | Client-native storage. Export first, or run the vendor's own migration tool. |
| POP-only mail that was downloaded and deleted from the server | No | Exists 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) | No | Die with the old client. Recreate in the new client, or promote to server-side rules. |
| Signatures, snippets, canned responses | No | Stored per client. Copy the text out before you close the old client for good. |
| Snoozed messages | Sometimes | Gmail snooze is server-side and survives. Most client-specific snooze features do not. |
| Send Later / scheduled sends | Usually no | Client-side queues that only fire while the client is running. Reschedule pending items in the new client. |
| S/MIME and PGP encrypted mail | Partial | The 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
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
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul 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.