You can migrate email from gmail safely. The mess starts when people treat Gmail like a normal IMAP server. It isn’t. Gmail uses labels, not real folders, and that one detail is why migrations bloat, stall, or dump sent mail into the wrong place. If you’re moving off Workspace because the per-user bill keeps climbing, start with the right model and skip the cleanup project later.
If you want the bigger cost and platform picture, read business email. This guide is the execution layer: how to migrate messages, avoid duplicates, switch DNS, and verify you didn’t lose mail.
The short version is simple. Sync old mail first. Cut MX when you’re ready. Run one last catch-up sync. Verify by message count, not mailbox size. That’s the cleanest way to migrate email from gmail to a standard IMAP host like TrekMail.
Why Gmail breaks normal IMAP migrations
When you migrate email from gmail, the main risk is duplication. Gmail exposes labels through IMAP, so one message can appear in multiple places. If your migration tool copies every visible folder, the same message can be imported more than once and your destination mailbox can inflate fast.
In a normal IMAP mailbox, one message lives in one folder. In Gmail, one message usually lives in All Mail and gets labels layered on top. Through IMAP, those labels can look like separate folders.
That’s the trap.
If a message has Inbox, Project A, and Urgent, a basic migration tool may try to copy it three times. Microsoft documents this exact duplication problem in Gmail-to-IMAP migrations when labels are involved and the [Gmail] folder isn’t excluded. IMAP itself is just the transport layer, as defined in RFC 3501. The weird part is Gmail’s folder presentation, not the protocol.
If you only remember one rule from this article, remember this one: when you migrate email from gmail, exclude [Gmail]/All Mail unless you have a very specific reason not to. That single choice prevents most storage blowups and “why is everything duplicated?” tickets.
For a TrekMail-specific walkthrough, see the Gmail migration doc. If you want the broader mechanics, the IMAP migration overview explains the server-side import model.
What moves when you migrate email from gmail
If you migrate email from gmail with IMAP, you’re moving mail data only: message bodies, attachments, folder placement, and read state when supported. You are not moving your whole Google account. Calendars, contacts, and Google Drive files need separate exports.
This is where people overestimate what an email migration does. IMAP moves email. That’s it.
Here’s the clean breakdown:
| Data type | Moves via IMAP? | Notes |
|---|---|---|
| Email messages | Yes | Bodies, attachments, dates, folders, and often read/unread state |
| Labels | Partly | They usually become folders, which is why Gmail can duplicate mail |
| Contacts | No | Export separately as CSV or VCF from Google Contacts |
| Calendars | No | Export separately as ICS from Google Calendar |
| Google Docs | No | Those are Drive items, not mailbox content |
Authentication matters too. If you want to migrate email from gmail with a third-party tool, you often need an app password. Google says app passwords are 16-digit passcodes and only work when 2-Step Verification is enabled. They also may not be available on some work or school accounts, which is a real constraint in Google Workspace environments. Check Google’s help doc on app passwords before you schedule a cutover.
That nuance matters because a lot of migration guides skip it. They say “generate an app password” as if every account can do that. Some can’t. If your admin has restricted the option, use an OAuth-capable migration path instead of wasting an afternoon on bad credentials.
The safest way to migrate email from gmail
The safest way to migrate email from gmail is a staged IMAP cutover: pre-sync old mail, switch MX, then run a final delta sync. That avoids a weekend panic, reduces user disruption, and works with Google’s throttling limits instead of pretending those limits don’t exist.
Don’t do a Friday-night big bang. Pre-stage most of the mailbox while users still work in Gmail, then cut over only the recent delta. That’s the operator approach.
- Inventory the mailbox. Check mailbox size, weird labels, and whether app passwords or OAuth are available. Confirm you actually need every folder. Garbage mail is still mail, and moving junk you plan to delete later only slows the job.
- Run a pilot first. Pick one low-risk mailbox. Use it to confirm folder mapping, sent mail placement, and whether your tool is handling Gmail’s special folders correctly. If the pilot is messy, a 50-user migration will be worse.
- Pre-sync old mail. Move mail older than 30 days first. This is where most of the volume sits. Users keep working in Gmail while the bulk transfer happens in the background.
- Cut over DNS. Lower TTL ahead of time, then switch MX to the new provider when the destination mailboxes are ready. On TrekMail, you can add the domain, publish the required records, and verify status from the dashboard. The docs for required DNS records cover the exact record set.
- Run the delta sync. After mail starts landing on the new server, sync the recent window one more time. That catches last-minute arrivals and read-state changes.
If you’re moving multiple brands or client domains at once, this is where flat-rate infrastructure starts making more sense than per-user suites. TrekMail’s model is built for that. For the broader economics, see multi domain email hosting.
Manual command to migrate email from gmail with imapsync
If you want total control, imapsync is the standard command-line tool to migrate email from gmail over IMAP. The critical part is excluding Gmail’s archive folder and mapping special folders cleanly so sent and draft mail land where users expect.
Here’s a practical template:
imapsync \
--host1 imap.gmail.com --port1 993 --ssl1 \
--user1 "user@source-domain.com" --passfile1 "/path/to/gmail_pass" \
--host2 imap.trekmail.net --port2 993 --ssl2 \
--user2 "user@dest-domain.com" --passfile2 "/path/to/dest_pass" \
--gmail1 \
--exclude "\\[Gmail\\]/All Mail" \
--exclude "\\[Gmail\\]/Trash" \
--exclude "\\[Gmail\\]/Spam" \
--regextrans2 "s/^\\[Gmail\\]\\/Sent Mail/Sent Items/" \
--regextrans2 "s/^\\[Gmail\\]\\/Drafts/Drafts/" \
--dryWhat each flag is doing:
| Flag | Why it matters |
|---|---|
--gmail1 | Tunes the source side for Gmail behavior |
--exclude "\[Gmail\]/All Mail" | Prevents the biggest source of duplicate imports |
--exclude Trash/Spam | Keeps junk and deleted mail out of the destination |
--regextrans2 | Maps Gmail folder names to standard IMAP folder names |
--dry | Simulates the run so you can inspect counts before copying data |
Run the dry test first. Always.
If you’re using TrekMail as the destination, the standard client settings are imap.trekmail.net on port 993 with SSL/TLS. TrekMail is IMAP-only, not POP3, which is the right default for synced mailboxes anyway. If you need the client reference later, use the IMAP and SMTP settings doc.
If you want a deeper operational guide to the CLI side, read imapsync. It pairs well with this workflow.
Failure modes that matter during a Gmail migration
When you migrate email from gmail, three failure modes matter most: Google throttling, authentication interruptions, and a tiny number of unreadable messages. None of them are reasons to panic. They are reasons to pause, adjust, and verify carefully instead of rerunning blindly.
The first is throttling. Gmail will slow or temporarily block aggressive IMAP pulls. When that happens, the right response is to wait, not hammer retry.
The second is auth loops. A migration may run for a while and then fail if Google flags the sign-in. Check the account’s security activity, confirm the login, and try again with the same session design. Don’t keep changing variables if the problem is just account trust.
The third is ghost items. A report might show a handful of failed messages in a mailbox with tens of thousands of items. That usually points to corrupt blobs, broken invites, or zero-byte oddities. If the miss rate is tiny, treat it as acceptable noise, not a catastrophic loss event.
Bad migration logic says: rerun the whole job until the report is perfectly clean.
Good migration logic says: identify whether the failures are real user-visible mail or broken artifacts that were never readable in the first place.
One more operational detail: don’t judge success by gigabytes. Gmail size and IMAP destination size are not apples to apples. Compression, metadata, and message representation vary. Judge success by item count and spot checks in key folders like Inbox, Sent, and user-created folders.
How to verify you really did migrate email from gmail cleanly
To verify you migrate email from gmail successfully, compare message counts and folder placement, not just storage size. Check Inbox, Sent, Drafts, and a few user-created folders. Then send live test mail after MX changes to confirm new mail is landing on the destination server.
Use this checklist:
- Compare total item count in Gmail versus the destination mailbox.
- Check Inbox count and unread count.
- Open Sent Items and confirm sent mail didn’t land in a random custom folder.
- Open 3 to 5 folders with unusual names or nested labels.
- Search for a few old messages with attachments and confirm they open.
- Send a live inbound test after the MX switch.
- Reply from the new mailbox and confirm SMTP and DNS are working.
If you’re moving the domain at the same time, clean DNS matters just as much as the mailbox copy. Old Google MX records left behind will split delivery and make people think the migration failed when the real problem is mixed routing. TrekMail’s docs on adding a domain and DNS checks are worth using before cutover. If you’re still deciding how to set up the destination mailbox structure, create email with domain is a good companion piece.
Old Way vs New Way
The old way to migrate email from gmail was paying per seat forever, then treating migration like a one-night project. The new way is pre-stage the data, verify counts, and move to flat-rate infrastructure that fits multi-domain operations instead of punishing growth.
Old Way: keep paying Google Workspace per user, put off the move because it feels risky, then rush the migration in one weekend and hope the mailbox math works out.
New Way: pre-sync most of the mailbox, switch DNS cleanly, run a final delta, and land on a platform built for custom domains and pooled storage. TrekMail starts at $3.50 per month, supports custom domains, IMAP mailboxes, mailbox forwarding, catch-all routing, BYO SMTP or included SMTP depending on plan, and server-side migration from the dashboard.
If you need multi-domain email without the per-user tax, this is the practical path. You can review TrekMail pricing, start on the free plan if you just want to test the workflow, and migrate for real when the pilot proves out.
Bottom line: if you need to migrate email from gmail, don’t overcomplicate it. Exclude All Mail, run a staged sync, switch MX once the destination is ready, and verify by message count. That’s how you migrate email from gmail without duplicate chaos and without babysitting users through a broken Monday morning inbox.
