Skip to main content

Migrate Email From Google Workspace: Cutover Planning for Domains and Users

 

Migrating from Google Workspace is not a file transfer; it is a routing change. If you treat it as a simple copy-paste operation, you will trigger "split-brain" DNS scenarios where half your company is emailing the other half, but the messages are landing in abandoned inboxes.

The difference between a seamless cutover and a helpdesk disaster is the sequence of events. This is the forensic runbook for executing a zero-downtime migration from Google Workspace to a standard IMAP provider like TrekMail.

For a broader strategy on the entire migration lifecycle, refer to Gmail Migration: How to Move from Gmail/Workspace to a New Provider Without Losing Mail.

Phase 1: The Forensic Inventory (Users, Aliases, and "Ghosts")

Google Workspace obscures the difference between a user, an alias, and a group. If you export a simple user list from the Admin Console, you will miss the "shadow identities" that receive 30% of your inbound mail.

1. The Hidden Alias Trap

A user logging in as jane@company.com may have five years of history receiving mail at sales@company.com or j.doe@company.com. If you provision the primary mailbox on the new host but fail to create these aliases, every email sent to them will hard-bounce (550 User Unknown) the moment you switch DNS.

The Fix: Do not use the Admin UI. Use GAM (Google Apps Manager) to export a forensic map of every routable address.

# Export all users and their aliases to CSV

gam print users aliases > aliases.csv

 

# Export all groups and their members

gam print groups members > group_members.csv

 

2. The Bandwidth Physics (Throttling)

You cannot migrate a 50GB mailbox over a weekend. Google enforces strict IMAP bandwidth limits that no tool can bypass.

  • Download Limit: ~2,500 MB (2.5 GB) per day, per account.
  • Upload Limit: ~500 MB per day.

The Math: A 50GB mailbox requires 20 days to migrate (50GB / 2.5GB daily limit).

  • Implication: You must run a "Pre-Stage" migration while users are still active on Google. Sync mail older than 30 days first. If you attempt a "Big Bang" cutover on Friday night for heavy users, you will hit Google's "Penalty Box" (HTTP 429 errors) and the account will be locked out for 24 hours.

Phase 2: The Domain Cutover Sequence (MX, SPF, DKIM)

The technical core of the migration is the DNS cutover. This is governed by the 300-Second Rule.

The TTL Strategy

Recursive DNS resolvers cache your MX records based on the TTL (Time To Live). If your TTL is set to the standard 86400 seconds (24 hours), it will take a full day for the internet to recognize your switch.

The Schedule:

Time

Action

Technical Detail

T-48 Hours

Lower TTL

Set MX, SPF, and DMARC TTLs to 300 seconds (5 mins).

T-24 Hours

Pre-Auth (DKIM)

Publish DKIM keys for the new provider. Since selectors differ (e.g., google._domainkey vs trek._domainkey), they can coexist without conflict.

T-0 (Cutover)

Switch MX

Update MX records to the new provider (e.g., mx1.trekmail.net, mx2.trekmail.net).

T+1 Hour

Verify Propagation

Use dig to confirm the world sees the new MX.

T+48 Hours

Restore TTL

Once stable, raise TTL back to 3600 or 86400 seconds.

Verification Command

Do not guess if propagation is complete. Query a public resolver:

dig @1.1.1.1 company.com MX +short

 

Output must show ONLY the new provider's MX records.

Authentication Coexistence (SPF)

During the transition window (T-0 to T+48h), mail may still be sent from Google servers (e.g., delayed sends, mobile devices that haven't updated). Your SPF record must authorize both Google and your new provider to prevent delivery failures.

Correct Coexistence Record:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

 

Warning: RFC 7208 limits SPF to 10 DNS lookups. If adding the new provider pushes you over 10, you must flatten the record or risk PermError results.

Phase 3: Client Remediation (The "Modern Auth" Barrier)

The most common helpdesk ticket is "My password isn't working." This is rarely a password issue; it is a protocol issue.

Google Workspace uses OAuth (Modern Auth). Standard email hosting uses credential-based authentication (IMAP/SMTP). Email clients like Outlook and iOS Mail cache the authentication method, not just the password.

Mobile Devices (iOS/Android)

Users cannot simply update the password in their existing settings. The device will continue attempting to handshake via Google OAuth.

  1. Action: Delete the account entirely from the device.
  2. Re-Add: Add Account > Select "Other" or "IMAP".
  3. Critical Warning: Do NOT select "Exchange" or "Google." TrekMail does not support ActiveSync or MAPI. We are a standards-compliant IMAP host.

Outlook (Desktop)

Outlook profiles often cling to the "Last Known Good" configuration. If Outlook detects the domain was previously on Google or O365, it may override your manual IMAP settings with "helpful" autodiscover logic pointing back to the old host.

  • The Fix: Do not repair the profile. Create a new Outlook Profile (Control Panel > Mail > Show Profiles > Add).

Phase 4: Verification and Rollback

How do you validate success? Storage size (GB) is a false metric. Google Drive metadata, compression, and label duplication inflate the size on Google's side.

The Golden Metric: Item Counts

Compare the Item Count per folder.

  • Source: Inbox: 5,400 messages
  • Destination: Inbox: 5,398 messages
  • Verdict: Success. The missing <1% is typically corrupt calendar invites or zero-byte "ghost" files that cannot be transferred via IMAP.

The Rollback Trigger

If you encounter a catastrophic failure (e.g., 100% inbound rejection), you must be ready to revert.

  1. Revert MX: Point MX back to Google. (With TTL at 300s, this propagates in ~5 minutes).
  2. Export Stragglers: Any mail that landed on the new server during the outage must be exported to .eml or .pst and re-injected into Google to ensure zero data loss.

Stop Fighting DNS. Try TrekMail.

You can script GAM exports, calculate bandwidth throttling manually, and fight with SPF lookup limits. Or you can use the platform built for Operators.

TrekMail simplifies the cutover for SMBs and Agencies:

  • Automated Migration: Our built-in tool connects to Google Workspace, respects the 2.5GB/day throttling limit automatically, and handles the retry logic for you.
  • Managed Delivery: We handle the SPF/DKIM complexity and IP reputation.
  • Agency Scale: Apply these settings to 100 domains instantly. No per-user fees, just pure margin.

Stop paying the per-user tax. Start your free migration with TrekMail today.

 

Labels:
Location: United States

Comments

Post a Comment

Popular posts from this blog

Email Isn’t an App — It’s Operations: What Breaks First When You Manage Multiple Domains

Most people think email is "solved." It’s old (1971), it’s ubiquitous, and mostly, it’s boring. Until it isn't.   The moment you start managing email for a real business—handling custom domains, setting up mailboxes for employees, or routing inbound traffic—you learn a blunt lesson: Email isn’t an app. It’s operations. You can ship a beautiful UI for creating mailboxes in a weekend. But you cannot ship reliability in a weekend. Reliability is the product. This is a practical look at the invisible infrastructure "chain of custody" that breaks when you move beyond a simple Gmail account, and what I learned about the grim reality of SMTP, DNS, and deliverability while building an ops-first email platform.   The Stack You Don't See When a user says "email," they picture an inbox. When an operator looks at email, they see a hostile environment. A single message delivery relies on a fragile chain: DNS : The phonebook (MX) and the...
9 comments
Read more

Forward Email to Another Address: What You Can Break (and How to Avoid It)

You set up a forwarding rule. You send a test email. It arrives. You think you’re done. You aren’t. In 2026, "forwarding" is not a passive pipe; it is an active SMTP relay operation that fundamentally alters the chain of custody. When you forward email to another address, you are inserting your server as a "Man-in-the-Middle." To modern receivers like Gmail, Outlook, and Yahoo, a poorly configured forward looks identical to a spoofing attack. If you do not understand the distinction between the Envelope Sender (P1) and the Header Sender (P2), your forwards will fail. They won't just bounce; they will be silently dropped, or worse, they will burn the reputation of your domain. This guide deconstructs the mechanics of forwarding, the specific error codes you will see when it breaks, and how to architect a solution that survives strict DMARC policies. For a complete architectural breakdown, refer to our pillar guide: Email Forwarding: How It Works, How to S...
13 comments
Read more

Email Forwarding Not Working: The Step-by-Step Debug Checklist (Fast Triage)

  Email forwarding fails because modern security protocols (SPF, DKIM, DMARC) are designed to stop it. To a receiving server, a forwarded email looks identical to a spoofed email: a server that isn't the original sender is attempting to deliver mail on their behalf. When forwarding breaks, you rarely get a clear error. You get silence. This guide provides a rapid triage workflow to isolate the failure, followed by a forensic checklist to fix the root cause. For a deep dive into the mechanics of SRS and ARC, refer to our core documentation: Email Forwarding: How It Works, How to Set It Up, and How to Fix It When It Breaks (2026) . The 60-Second Triage: Identify the Symptom Do not guess. Categorize the failure behavior immediately to determine the fix. Symptom Behavior Likely Culprit Immediate Action The Bounce (NDR) Sender receives a 5xx error immediately. Policy Block or Invalid Address Read the SM...
12 comments
Read more