Switching from Apple Mail: What Actually Needs Migrating

Most guides on how to switch from Apple Mail to another email client miss the point. They walk you through installing the new app and forget that the interesting question is not "does mail arrive on the other end." It is what quietly gets left behind on your Mac when the account moves — the On My Mac folders that have no server copy, the rules that filed a decade of newsletters, the smart mailboxes that were really saved searches, the flag colors you used as a triage system. Those pieces are the migration.

This is a pre-switch inventory. It covers what transfers automatically because it was never really in Apple Mail (server-side messages and folders), what has to be exported or rebuilt (everything Apple Mail layered on top locally), and how to sequence the move so you have a working inbox on day one and no data loss on day thirty. Apple Mail remains a perfectly good client for light volume; if it is working for you, this post is not trying to talk you out of it. It is for the reader who has already decided to switch and wants to arrive without losing anything.

What actually moves — and what doesn't#

The single most useful mental model for this migration: sort every piece of your Apple Mail setup into "lives on the server" or "lives on this Mac." Server-side things follow the account automatically. Mac-side things stay put unless you export them.

Server-side is the big category and the easy one. If you use Gmail, Outlook / Microsoft 365, iCloud, Fastmail, Yahoo, Proton Bridge, or any IMAP or Exchange account, the messages themselves live in the provider's data center. Apple Mail was showing you a view of a mailbox someone else was storing. Point a new client at the same account with the correct credentials and the mail is already there — inbox, sent, drafts, every server-side folder, every label. iCloud in particular is documented for third-party IMAP: `imap.mail.me.com` on 993 with an app-specific password, `smtp.mail.me.com` on 587. No export step, no data movement, no risk of loss.

Mac-side is the surprise category. Anything under "On My Mac" in your sidebar is local storage — messages Apple Mail wrote to disk that were never uploaded anywhere. Rules from Mail > Settings > Rules are local. Smart mailboxes are saved searches defined in your local database. Signatures live in a local plist. Flag colors and To-Do links are proprietary Apple headers other clients ignore. Every one of these has to be handled deliberately or it disappears the day you delete the account.

Read state is the interesting edge case. It is stored in the message flags on the server for IMAP accounts, so it usually survives the switch. It is stored only locally for On My Mac and POP3 accounts, and it does not survive unless the new client happens to preserve the flag on mbox re-import — which most do not.

Pre-migration checklist#

Run this before you install a new client. The order matters — inventory first, export second, switch third.

• Inventory your accounts. Mail > Settings > Accounts. For each account, note the type (IMAP, Exchange, iCloud, POP3, On My Mac). Anything IMAP / Exchange / iCloud is server-side. POP3 and On My Mac are local-only and must be exported.
• Screenshot every rule. Mail > Settings > Rules. Rules cannot be exported to any other client — Apple's format is proprietary and undocumented. Take screenshots of the conditions and actions for each rule so you can rebuild them in the new client's rule engine.
• Screenshot every smart mailbox definition. Right-click a smart mailbox > Edit Smart Mailbox. Copy the criteria into a note. Smart mailboxes are saved searches; the new client's equivalent is a saved search or virtual folder, and you rebuild them from the criteria, not from an export file.
• Export every signature. Mail > Settings > Signatures. There is no export button — open each signature, copy the HTML or plain text into a note, save any inline images separately. Signatures with images are the most annoying thing to lose because they never look right when you paste them somewhere else.
• Export every On My Mac mailbox to .mbox. Select the folder, Mailbox > Export Mailbox, choose a destination outside ~/Library/Mail. Verify the .mbox opens in a second client (Thunderbird with ImportExportTools NG, or Mimestream's importer) before deleting anything.
• Note your flag-color conventions. If red meant "reply today" and orange meant "waiting on client," write that mapping down. Flag colors do not travel to other clients, so you will rebuild the convention using the new client's tagging or labeling.
• Confirm you have an app-specific password for iCloud. If iCloud is one of the accounts, generate one at appleid.apple.com > Sign-In and Security > App-Specific Passwords. Most non-Apple clients require it — regular iCloud passwords will not work on IMAP.

How to switch from Apple Mail to another email client — steps#

These steps assume you have completed the checklist above. They are ordered to give you a working new client before you touch anything on the old one, so you can back out at any point.

1. 1

   Install the new client and add one non-critical account first

   Start with the account you would miss least — a personal Gmail, a Yahoo, a secondary iCloud. Add it in the new client. Confirm the initial sync completes, folders match, and search works. This is the smoke test. If something is wrong with the client or your setup, you find out on an account whose loss you could recover from.

2. 2

   Add each remaining server-side account

   Repeat for Gmail, Outlook / Microsoft 365, Fastmail, Proton (via Bridge), and any IMAP account. For iCloud, use the app-specific password from the checklist. The new client will re-download the folder tree and index the mail; expect this to take minutes for a small account and hours for a multi-decade Gmail archive.

3. 3

   Import your On My Mac mailboxes from the .mbox exports

   Most clients have a File > Import or drag-and-drop path for mbox files. Thunderbird: install the ImportExportTools NG add-on, right-click the destination folder, ImportExportTools NG > Import mbox file. Mimestream: drag the .mbox package onto an account. Verify message count and open three messages at random to confirm attachments are intact.

4. 4

   Rebuild rules by hand in the new client

   Open your rule screenshots and recreate each rule in the new client's filter or rule engine. The conditions and actions rarely map one-to-one — Apple's "Any recipient contains" may need to become two filters in Gmail — but the logic transfers. Do not try to migrate rules by file; there is no path.

5. 5

   Rebuild smart mailboxes as saved searches

   Gmail calls them search operators; Outlook calls them Search Folders; Thunderbird calls them Saved Searches; most modern clients have an equivalent. Rebuild each smart mailbox definition using the new client's search syntax. This is faster than it sounds because the criteria are already written down from the checklist.

6. 6

   Paste your signatures in and re-add inline images

   Signatures with inline logos are the migration's paper cut — they never survive the copy-paste. Paste the text, then re-insert each image using the new client's signature editor. Send yourself a test message from each account to confirm the signature renders in a real recipient's client, not just the composer preview.

7. 7

   Leave Apple Mail installed for 30 days

   Do not remove the accounts from Apple Mail on day one. Leave both clients pointed at the same IMAP / Exchange / iCloud accounts while you work in the new one. If the new client turns out to be missing something, you have a working fallback. Only remove the accounts from Apple Mail after 30 days of running clean in the new client.

What breaks in the round trip#

The categories below are what actually survives the move on August 2026 across four common destinations: another Mac's Apple Mail (moving Macs), Mimestream (native Mac client that reads Apple Mail's on-disk store on import), Thunderbird (cross-platform), and a generic non-Apple IMAP client like Outlook.

Where the losses actually hurt#

Two rows on that table cause almost every "we should have kept X" complaint after a switch, and both are worth planning for before you move rather than mourning after.

Flag colors are the first. If you built a triage system out of red for reply-today, orange for waiting-on-client, purple for reference-later, that mapping is a workflow, not decoration. It does not travel to any non-Apple client because Apple's colored flags are written as a proprietary header that other clients drop. Before the switch, decide what the new client's equivalent will be — Gmail labels, Outlook categories, Thunderbird tags, or a set of folders — and be ready to reflag as messages arrive. Do not try to bulk-migrate the colors themselves.

Rules are the second, and they are worse because you often do not remember them all until they stop firing. Rules built up over years in Apple Mail — the recruiter blocklist, the newsletter filer, the client-project auto-star — are invisible until a rule you had forgotten stops filtering something and it lands in your inbox. Screenshotting the rule list before the switch is the only defense; there is no export path Apple ships, and every third-party "Apple Mail rules exporter" we tested writes to formats no other client reads.

Rollback plan if the new client is wrong#

The most common reason people reverse a migration is not a bug — it is that the new client turns out to be missing one thing they used every day. Apple Mail is unusually easy to roll back to, because the pre-migration checklist above never modified the source data on this Mac or on the server.

For server-side accounts, the rollback is trivial. Apple Mail was still connected the whole time (you left it installed per step seven), so no action is required — reopen it and the account is already synced. If you also created new mail in the other client, it will be in the account when Apple Mail catches up, because sent mail goes into the server's Sent folder either way.

For On My Mac mailboxes, use Mailbox > Import Mailboxes > Files in mbox format and point at the .mbox archive you exported in the checklist. Apple Mail rebuilds the folder from the archive. If you also edited those messages in the other client — moved them, deleted them, added new ones — the truth of the folder now lives in the other client, and you re-export from there before importing into Apple Mail.

For rules and smart mailboxes, no rollback is needed because you never touched the originals — they were rebuilt from screenshots in the new client, not migrated out of Apple Mail.

Doing it without downtime — and where AI Emaily fits#

The clean version of this migration is: install the new client, connect the accounts alongside Apple Mail, run both for a few weeks, then remove Apple Mail once you trust the new one. That takes an evening of setup and about a month of low-attention verification. No mailbox goes dark; nothing you cannot un-do.

If the reason you are switching is that Apple Mail's native filters and smart mailboxes are not keeping up with the volume — you have a rule list that has grown into unmaintainable brittleness, and manual triage is eating an hour a day — we build AI Emaily, an AI-native email client that connects Gmail, Outlook, iCloud, and IMAP through server-side sync and runs triage, drafts, and follow-ups as an agent you supervise. AI Emaily is not a like-for-like Apple Mail replacement: it is an Electron desktop app plus web, not a native Swift / AppKit client, and if what you want is the closest thing to Apple Mail's feel on Apple Silicon — Cmd-key shortcuts, deep macOS integration, a fully local archive — Mimestream is the honest recommendation and we are not that. What AI Emaily is instead is an agent layer on the account that used to be in Apple Mail: unified inbox across every provider, AI triage keeping the important thread visible, drafts written from a Personal Context brain you set. There is a 7-day free trial on Pro (card required, $0 if cancelled before day seven) — see aiemaily.com/pricing. We build AI Emaily.