Transfer Emails From Gmail: What to Preserve (Labels, Sent, Threads) and What You Can’t

 

Migrating from Google Workspace to a standard IMAP provider is not a file transfer; it is a translation between two fundamentally different architectures. Google uses a proprietary database structure that mimics email, while the rest of the world (including TrekMail) uses standard RFC-compliant IMAP.

If you treat this as a simple "copy and paste," you will corrupt your data. You will duplicate storage, break conversation threads, and lose metadata.

This guide is a forensic breakdown of the Gmail-to-IMAP translation matrix. It details exactly what moves, what breaks, and the specific operational protocols required to migrate without data loss.

The Core Conflict: Database Tags vs. Physical Folders

The primary cause of migration failure is the "Label" system.

In a standard email environment, a message exists in one physical location (e.g., /var/mail/domain/user/Inbox). If you move it to a folder, the file moves.

In Gmail, folders do not exist. There is only one massive object store called All Mail. When a user "moves" an email to a folder, Google simply applies a metadata tag (Label). Crucially, a single message can have multiple labels (e.g., Inbox, Project Alpha, and Urgent).

The Duplication Physics

When a migration tool connects to Gmail via IMAP, it interprets every Label as a distinct physical folder.

• The Scenario: You have a 10MB email labeled Inbox and Project Alpha.
• The Migration Action: The tool sees two folders. It downloads the 10MB email from Inbox. It downloads the same 10MB email from Project Alpha.
• The Result: Your 10MB of data becomes 20MB on the destination server.

If you migrate the [Gmail]/All Mail folder—which contains a copy of every message regardless of label—you guarantee 100% duplication of your entire mailbox. A 50GB Workspace account will explode into 100GB+ on the destination, likely hitting storage quotas and crashing the migration.

The Fix: You must strictly exclude [Gmail]/All Mail from your sync scope.

The Preservation Matrix: What Moves and What Breaks

We categorize data into three buckets: High Fidelity (moves perfectly), Degraded (moves with caveats), and Incompatible (must be abandoned or moved manually).

1. High Fidelity (The Safe List)

These elements transfer via standard IMAP without intervention.

• Message Bodies & Attachments: RFC 5322 content is preserved bit-for-bit.
• Read/Unread Status: Mapped via the \Seen system flag.
• Timestamps: Competent migration tools use the INTERNALDATE attribute, not the header date. This ensures emails appear in the mailbox based on when they were received, preserving historical order.
• Folder Structure: User-created labels (e.g., Work/Clients) are converted to physical folders.
• Note: Nested labels (Parent/Child) become nested folders. Ensure the total path length does not exceed 255 characters.

2. Degraded (Requires Operator Attention)

These elements move, but require specific mapping or user education.

• Sent Items (The "Split History" Risk):
• Source: Gmail stores sent mail in [Gmail]/Sent Mail.
• Destination: Standard servers use Sent or Sent Items.
• The Risk: If unmapped, you will end up with two folders: Sent Items (new mail) and Sent Mail (old history).
• The Fix: Your migration tool must explicitly map [Gmail]/Sent Mail -> Sent Items.
• Flags and Stars:
• Yellow Star: Maps to the standard IMAP \Flagged status (appears as a red flag in Outlook).
• Custom Stars (Blue, Green, etc.): Lost. These are proprietary to Google's UI. They usually degrade to a standard flag or are stripped.
• Threading:
• The Reality: "Threading" is a client-side visual feature, not server-side data.
• The Preservation: The Message-ID, In-Reply-To, and References headers are preserved. Modern clients (Outlook, Thunderbird, Apple Mail) use these to visually stitch conversations back together. You do not "lose" threads, but you rely on the client to display them.

3. Incompatible (The "Hard" List)

These features rely on Google's proprietary ecosystem and cannot be migrated via IMAP.

• Google Drive Links: These are not attachments; they are hyperlinks to Google's servers. If you cancel Workspace, these links break. You must export files via Google Takeout.
• Calendars & Contacts: IMAP is an email-only protocol. It does not sync calendars (CalDAV) or contacts (CardDAV).
• TrekMail Context: We are a pure email host. We do not provide calendar hosting. Users must export calendars to .ics files and import them locally or use a dedicated calendar service.
• Server-Side Rules: Gmail filters (e.g., "Skip Inbox if from @vendor.com") live in Google's cloud logic. They do not transfer. Users must recreate rules in their local client or on the new server.
• The \Recent Flag: This flag is session-specific and cannot be set on the destination. Users may not see migrated emails as "Recently Added" in some views.

The Physics of Throttling: Why "Big Bang" Migrations Fail

Google enforces strict bandwidth limits to prevent data extraction. Ignoring these limits leads to "HTTP 429" errors and account lockouts.

The Limits

• IMAP Download Limit: ~2,500 MB (2.5 GB) per day, per account.
• IMAP Upload Limit: ~500 MB per day (relevant if pushing data to Gmail, less relevant for extraction).
• Concurrent Connections: Max 15 connections per account.

The Math

If you have a CEO with a 45GB mailbox:
45GB / 2.5GB per day = 18 Days

You cannot migrate this user over a single weekend. If you attempt to force it by increasing thread counts, Google will trigger a "Penalty Box" lockout. The account will become inaccessible via IMAP for 24 hours, often requiring a manual "Display Unlock Captcha" reset via the web interface.

The Strategy: Pre-Stage & Cutover

To bypass the physics of throttling, you must use a phased approach.

1. Phase 1: The Pre-Stage (T-Minus 20 Days)
• Migrate all email older than 30 days.
• This moves 90% of the data while the user is still working in Gmail.
• If the tool hits the 2.5GB limit, it pauses and resumes the next day.
2. Phase 2: The Cutover (T-Zero)
• Lower DNS TTL to 300 seconds.
• Switch MX records to TrekMail.
3. Phase 3: The Delta (Post-Cutover)
• Run a final "Delta" pass to copy the remaining 30 days of mail and update Read/Unread statuses.
• Since this is a small dataset, it finishes quickly, well under the daily bandwidth cap.

Pre-Migration Cleanup Checklist

A "dirty" migration is slow and prone to errors. Run this cleanup 48 hours before the move.

1. Purge the Trash: Gmail keeps deleted items for 30 days. Excluding [Gmail]/Trash saves bandwidth.
2. Empty Spam: [Gmail]/Spam often contains thousands of messages. Do not migrate them.
3. Flatten "Whale" Labels: Deeply nested labels (e.g., Clients/2020/ProjectA/Invoices/Paid/January) can exceed the 255-character path limit of standard file systems. Flatten these to Clients-2020-ProjectA where possible.
4. Resolve "System Label" Conflicts: Ensure no user has created a custom label named Sent or Trash that conflicts with reserved system names on the destination.

Verification: The Forensic Standard

Do not trust "Total Size" as your success metric.

• Why: Gmail compression, deduplication, and metadata overhead mean a 10GB Gmail account might occupy 12GB or 8GB on a standard server.
• The Fix: Validate by Item Count.

The Verification Protocol:

1. Log into Gmail. Go to All Mail. Note the total count (minus Chat history).
2. Log into the destination (TrekMail). Sum the counts of all folders.
3. Acceptable Variance: <1%.
• Common Causes for Variance: Corrupt calendar invites, zero-byte "ghost" messages, or chat logs that look like emails but aren't.

How TrekMail Simplifies the Physics

You can perform this migration manually using tools like imapsync, but you will need to script the regex for folder mapping, handle the OAuth2 token generation for Google, and write your own backoff logic to avoid the 2.5GB daily lockout.

TrekMail automates the forensic requirements of a Gmail migration:

• Automated Folder Mapping: We automatically map [Gmail]/Sent Mail to Sent and exclude [Gmail]/All Mail to prevent duplication.
• Smart Throttling: Our migration engine detects Google's rate limits. When we hit the 2.5GB cap, we pause the job for that specific user and auto-resume after the cooldown, without operator intervention.
• Bulk Operations for Agencies: If you are moving 50 domains, you don't need to configure 500 individual jobs. Our bulk tools allow you to apply this template across your entire fleet.

For a detailed technical breakdown of the migration protocol, read our pillar guide: Gmail Migration: How to Move from Gmail/Workspace to a New Provider Without Losing Mail.

If you are ready to stop renting your email infrastructure and start owning it, try TrekMail for free. We handle the physics so you can focus on the business.