Do Gmail Labels Transfer When You Switch Email Providers?

You have decided to move off Gmail, and now you are staring at a label tree that took years to build — Clients, Receipts, Legal, Newsletters, and forty more, some nested three deep. The question that stalls the migration is small and specific: do Gmail labels transfer to another provider, or do you rebuild the whole system by hand on the other side?

The honest answer is no, not natively. Labels are a Gmail concept. Every other major provider — Outlook, iCloud, Proton, Fastmail, and every generic IMAP host — stores mail in folders, which are not the same thing. A migration has to translate a labels model into a folders model, and every translation has losses. This post explains exactly what those losses are, what you can do to reduce them before you export, and what a rollback looks like if it goes wrong.

What actually moves and what doesn't#

Gmail does not use folders. It stores each message a single time in All Mail and attaches labels to it, like tags. A message can carry many labels at once — Client-Acme, Contracts, and Q3-Renewals on the same email. Over IMAP, Gmail exposes each label as if it were a folder, using the X-GM-LABELS extension to preserve the underlying tag information for clients that know how to read it. Most consumer clients and most migration tools do not.

So when you export or copy your mail to another provider, three things happen. The message bodies come across cleanly. The label names come across as folder names. And the many-to-many relationship between messages and labels — the whole point of the system — collapses. A message that carried three labels either lands in one folder chosen by the tool, or gets copied three times into three separate folders on the new side, depending on the migration path you pick.

Beyond labels, several other Gmail-specific pieces of metadata almost never survive a cross-provider move. Threads are reassembled by the new provider from the Message-ID and In-Reply-To headers, and the results rarely look identical to Gmail's conversation view. Stars, Important markers, snooze state, and Categories (Primary, Promotions, Social, Updates, Forums) are all Gmail-only concepts with no target field on the receiving side.

Pre-migration checklist#

The single biggest reason migrations produce messy inboxes on the other side is that people export the label tree they have, not the one they want. Every extra label, every misspelled variant, every leftover from a filter you wrote in 2019 becomes a folder on the new provider and stays there. Spend an hour tidying Gmail before you touch the export button.

• List every label. In Gmail, Settings → See all settings → Labels. Screenshot or export the list; you will use it as your target folder tree on the other side.
• Merge near-duplicates. Rename Clients-Acme, ClientsAcme, and Acme-Clients to a single label before you export — see /features/rules-brain for the pattern used to consolidate.
• Remove auto-labels you never browse. Any label a filter still writes to but you never open is 100 percent noise on the new provider.
• Flatten deep nests you don't need. Some providers cap folder depth at three or four; anything below that gets truncated or renamed with slashes in the name.
• Turn off Show in IMAP for junk labels. If a label is hidden from IMAP, most migration tools skip it, which is the cleanest way to drop cruft without deleting anything.
• Export your filter list. Settings → Filters and Blocked Addresses → Export. Filters won't import to another provider but the XML is a plain-English map of the rules to rebuild.
• Snapshot your contacts and calendar separately. contacts.google.com and calendar.google.com have their own export flows. Mail migration does not touch either one.

Steps: three realistic migration paths#

There are three ways mail actually moves from Gmail to another provider, and each preserves label structure to a different degree. Pick by destination and by how much label fidelity you need.

1. 1

   Google Takeout → MBOX → new provider

   Google Takeout exports your Gmail as one or more MBOX files. The X-GM-LABELS header is preserved inside the MBOX (Google documents this), so the label data is technically in the archive. Whether it survives the next step depends on the tool you use to import it. Most consumer clients (Apple Mail, Thunderbird) ignore X-GM-LABELS entirely on import and dump everything into one folder. This path is best for archival, not for reconstructing a label tree.

2. 2

   Direct IMAP-to-IMAP with imapsync

   imapsync connects to Gmail as an IMAP client, reads each label-folder, and copies its contents to a matching folder on the destination. Each label becomes a folder on the new provider. A message with three labels is copied three times — once into each destination folder. This is closer to "labels preserved" than Takeout, but at the cost of duplication. imapsync's Gmail FAQ documents both the mapping and the duplicate behaviour.

3. 3

   Google Workspace Data Migration Service (Google-to-Google only)

   If you are moving from consumer Gmail or another Workspace tenant into a Google Workspace destination, the Data Migration Service preserves label structure natively — including multi-label assignments — because both sides speak the same model. It does not help with a move to Outlook, iCloud, Proton, or Fastmail. Use it only when destination is Google.

4. 4

   Provider-native importers

   Fastmail, Proton, and Outlook.com each ship a Gmail import tool. All of them convert labels to folders and none of them promise multi-label preservation. Read the provider's own documentation before you commit — the behaviour changes between versions.

What breaks — and what to do about each thing#

The failure modes are predictable. Match the symptom to the cause before you conclude the tool is broken.

The picture below is the shape of the whole thing: one message with several labels on the Gmail side, and its arrival on the destination as either three folder entries or one flattened entry, depending on which of the paths above you took.

Rollback plan#

Migrations go wrong. Threads split badly, folder trees look nothing like the label tree you sketched, or the new provider reveals a quota problem two hours into a copy. A rollback is not "reverse the migration" — it is "return to a known-good state." Plan it before you start.

1. 1

   Do not delete anything in Gmail until the destination is verified

   The whole point of Gmail's labels-as-tags model is that a copy operation to another provider does not remove anything from your original account. Leave Gmail untouched — Inbox, All Mail, and every label — for at least 30 days after you cut over. If the migration is bad, you have not lost the source.

2. 2

   Keep the Takeout MBOX archive somewhere off the destination

   Store the Takeout export on an external drive or a bucket that is not tied to either provider. This is your cold backup: even if both accounts vanished, the MBOX is a plain-text archive any IMAP-speaking tool can re-import.

3. 3

   Stage the migration with a subset first

   Before you migrate 15 years of mail, migrate one label. Pick something small and self-contained — Receipts-2024, say — and run the full pipeline. Verify the count matches, that duplicates behave the way you expected, and that threading looks acceptable. If it does not, you have wasted an hour rather than a weekend.

4. 4

   Reverse-forward before you cut MX

   Set up forwarding from the new provider back to Gmail during the transition, not the other way around. That way if the destination has an outage or you want to abandon the move, Gmail keeps receiving mail throughout and nothing is stranded on the new side.

5. 5

   Give yourself a defined bail-out window

   Write down the date at which you will either commit to the destination (and start updating logins that point at your Gmail address) or roll back. A migration that stays half-done for six months is worse than either finishing or aborting.

Doing it without downtime — and where a client-side layer fits#

There is a third option most migration guides skip: you do not have to pick one provider at all. Every serious cross-provider question in this post — labels flattening into folders, threads splitting, filters not migrating — assumes you are cutting Gmail out. If your reason for switching is "one inbox that behaves the way I want," a client-side triage layer over Gmail and the new provider does the job without the migration losses.

AI Emaily reads Gmail through the same X-GM-LABELS data described above, keeps labels as labels on the Gmail side, and presents one unified inbox across Gmail, Outlook, iCloud, Proton, Fastmail, and generic IMAP. You do not lose the label tree because you do not export it — the labels stay in Gmail; the client just projects them alongside your other accounts and adds rules plus a Personal Context brain you set directly, with approve-before-send and a full audit log on every action. That does not solve every reason to leave Gmail — if the reason is privacy from Google specifically, a client cannot help. But if the reason is inbox chaos across several accounts, it removes the migration from the critical path. We build AI Emaily; there is a 7-day free trial on Pro at /pricing, and the homepage at / walks through how the client-side layer works.