Migrate Email From Google Workspace Without Losing Mail

Migrate email from Google Workspace the wrong way and you get split delivery, missing aliases, and angry users by Monday morning. This is a cutover job, not a drag-and-drop export. If you need the bigger buying context first, read business email. If you're already planning the move, this runbook shows how to migrate email from Google Workspace to an IMAP host like TrekMail without breaking inbound mail.

The trap is simple: admins focus on copying old messages and forget the routing layer. Mail does not care that your migration is 92% done. The second MX changes, new messages go somewhere. If aliases, groups, DNS, and client setup are not ready at the same moment, you create two inbox realities. Users keep sending. Customers keep replying. Half that mail lands in the wrong place.

The fix is sequence. Inventory first. Pre-stage second. Cut DNS once. Reconnect clients cleanly. Then verify by item count, not by gut feel. TrekMail fits this model because it gives you pooled storage, flat-rate multi-domain hosting, built-in IMAP migration, and standard IMAP/SMTP client support without the per-user tax.

What does it mean to migrate email from Google Workspace?

To migrate email from Google Workspace, you need to move stored mail over IMAP and then switch live mail routing from Google to the new provider. The copy matters, but the cutover matters more. If routing changes before identities, DNS, and clients are ready, mail starts disappearing into the wrong inboxes.

That distinction matters because Google Workspace hides several identity types behind one admin experience. A login account is not the same thing as every address that receives mail for that person. Shared aliases, group addresses, forwarding paths, and catch-all behavior can all affect the cutover.

Before you touch DNS, build the destination side properly. In TrekMail that usually means adding the domain, confirming the DNS records, creating each mailbox, and deciding which aliases should stay aliases versus real mailboxes. These docs help with the prep work: add a domain, check the required DNS records, and review how TrekMail handles Gmail migrations.

Phase 1: Build a forensic inventory before you copy anything

When you migrate email from Google Workspace, the first real task is discovering every address that can receive mail. Primary users are obvious. Aliases, groups, and old routing rules are where migrations fail. If you miss those addresses, the DNS cutover turns them into hard bounces or silent dead ends.

Start with four lists:

1. Primary users and their mailbox sizes.
2. All aliases tied to each user.
3. Google Groups that still receive real inbound mail.
4. Forwarders, catch-alls, and retired addresses that still show up on invoices, contact forms, or signatures.

This is why simple admin exports are not enough. A sales rep might sign in as jane@company.com but still receive live mail at sales@company.com, quotes@company.com, and an old acquisition domain nobody documented. Miss one and the cutover looks broken even when DNS is fine. If you want to migrate email from Google Workspace cleanly, every routable address needs a destination.

If you are extracting data from Google, operators often use GAM or the Admin SDK to build a full routing map. The exact tool matters less than the result: every routable address needs an explicit home on the destination system before you migrate email from Google Workspace.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

While you sort those addresses, decide what each identity should become on the new host:

If you need a quick decision framework for identity mapping, read domain email alias vs mailbox. That is where a lot of migration mistakes start.

Phase 2: Pre-stage the data because Google throttles IMAP

To migrate email from Google Workspace at any real size, you need a pre-stage pass. Google documents IMAP bandwidth limits that cap how much data you can pull and push per account per day. Large mailboxes will not finish in one weekend, no matter how optimistic the project plan looks.

Google publishes Gmail bandwidth limits for Workspace accounts: IMAP download is 2,500 MB per day and IMAP upload is 500 MB per day. That is the physics of the migration, not a suggestion. A 50 GB mailbox can take weeks if you are pulling the full history over IMAP.

That means the right pattern is:

1. Pre-stage older mail while users still work in Google.
2. Run delta syncs on the days before cutover.
3. Move the newest mail after DNS flips or in the final sync window.

For heavy users, split the job by date range where your tool allows it. TrekMail's migration flow supports staged imports through its IMAP migration workflow, which makes it much more practical to migrate email from Google Workspace in batches instead of one blind full-history pull.

Example: If accounting has a 36 GB mailbox but only needs the last 90 days immediately, import recent folders first, cut mail flow, then backfill the archive after production is stable.

Google's current guidance on sign-in also matters here. Legacy basic auth is gone for most cases, with app passwords as the main exception on supported setups. For Gmail-source migrations, TrekMail's live docs specify using a Gmail app password rather than the normal account password when Google policy requires it. See Google's app passwords help.

Phase 3: Cut DNS once, and do it in the right order

When you migrate email from Google Workspace, DNS is the cutover point that decides where new mail lands. Lower the TTL ahead of time, publish the new authentication records, and change MX only after the destination mailboxes and aliases already exist. If you reverse that order, you create split-brain delivery.

The clean sequence is boring on purpose. Two days before cutover, lower the TTL on MX, SPF, and DMARC to 300 seconds. One day before cutover, publish DKIM for the destination provider. At cutover, replace Google's MX with TrekMail's. Then verify propagation from a public resolver instead of trusting your own laptop cache.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

During the overlap window, keep both Google and TrekMail in SPF if mail can still leave through both systems. That lines up with RFC 7208. Watch the 10-DNS-lookup limit. If your record is already bloated with vendors, flatten it before you migrate email from Google Workspace.

If you expect to repeat this across many client domains, this is where TrekMail starts paying for itself. The old way is editing DNS and mailbox settings one domain at a time while paying per user. The new way is one flat-rate platform with multi-domain control, pooled storage, a DNS wizard, and migration built in.

Phase 4: Fix the clients, not just the password

After you migrate email from Google Workspace, a lot of support tickets look like password failures but are not. Google-trained clients often keep OAuth assumptions, cached autodiscover data, or old provider presets. Users need a clean IMAP setup pointed at the new host, not a desperate password retry loop.

This hits mobile devices and Outlook hardest. On phones, users love tapping the Google logo during setup because it feels familiar. That is wrong after the cutover. On Outlook, old profiles can keep trying to reconnect to Google even after MX already points somewhere else.

Use direct IMAP settings for TrekMail:

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

On iPhone and Android, tell users to remove the old Google account entry and add the mailbox again as Other or IMAP. On Outlook desktop, create a new mail profile instead of repairing the old one. If you want the exact steps, TrekMail's client guides cover IMAP/SMTP settings, and you can pair that with the published guide on imapsync if you need a more manual migration workflow.

One more point: TrekMail is standards-first IMAP hosting. No POP3. No pretending to be Exchange. If a device or user insists on proprietary Google or Microsoft setup flows, you will waste time chasing the wrong protocol.

Phase 5: Verify with counts, then keep rollback simple

To migrate email from Google Workspace safely, verify mailbox health by folder counts and live mail flow, not by total gigabytes. Google's storage view includes compression and non-mail factors that do not map cleanly to IMAP destinations. Count messages. Confirm new inbound. Confirm new outbound. Then call the cutover done.

Your minimum verification checklist should look like this:

1. Folder counts are close enough on every critical mailbox.
2. Inbound test messages land only on TrekMail after MX propagation.
3. Outbound mail passes SPF, DKIM, and DMARC checks.
4. Aliases and shared addresses receive exactly where expected.
5. Users can log in on desktop and mobile with the new settings.

Small count gaps can be normal. Corrupt messages, broken invites, and strange zero-byte items do not always survive IMAP. What is not normal is new inbound mail still landing in Google after you think you finished. If that is happening, you did not fully migrate email from Google Workspace yet.

Rollback should be blunt and fast. If inbound mail is failing broadly, point MX back to Google while the TTL is still low. Then export any messages that landed on the new host during the bad window and re-inject them if needed. A rollback plan you cannot execute in five minutes is not a rollback plan.

Old Way vs New Way: why operators pick TrekMail for this move

If you migrate email from Google Workspace often, the real cost is not just license price. It is the repeated admin labor around domains, mailbox creation, client resets, and migration retries. TrekMail cuts that work down with a flat-rate, multi-domain model built for operators instead of per-seat spreadsheets.

TrekMail gives you custom domains, IMAP mailboxes, catch-all support, mailbox forwarding, BYO SMTP or included SMTP depending on plan, and server-side migration. The Nano plan is always free and does not need a card. Paid plans include a 14-day free trial, and that trial requires a credit card. If you manage one brand today and twenty client domains next quarter, that pricing model is the difference between margin and mess.

For teams handling many mailboxes at once, the operational upside looks a lot like multi domain email hosting: one dashboard, fewer moving parts, and no per-user fee trap every time a client adds another inbox.

If you want to migrate email from Google Workspace without turning the cutover into a weekend fire drill, start at TrekMail pricing. Build the destination first. Pre-stage the mail. Flip DNS once. Then verify like an operator.