For most businesses, Google Workspace is the default starting line. It’s easy to set up, familiar, and reliable. But success brings a specific kind of pain: the "per-user tax."
When you start, paying $6/month for
a single user is negligible. When you scale to 20, 50, or 100 users, that bill
transforms into a massive, recurring liability. Suddenly, you're paying
thousands of dollars a year for "Jane in Accounting" to have an email
address, even though she never logs into Google Drive or uses Google Meet.
For Agencies and MSPs, the math is
even worse. You're reselling a product with shrinking margins, managing
hundreds of tenants, and fighting a billing department that doesn't care about
your cash flow.
A Gmail migration is the
highest-leverage infrastructure change you can make to fix your burn rate. But let’s
be honest: it scares people. Email is the central nervous system of a business.
If it goes down, work stops.
This isn't a marketing brochure.
This is a forensic runbook for Operators. We are going to walk through exactly
how to move off Google’s infrastructure without losing data, bouncing emails,
or getting fired.
Gmail
vs. Google Workspace: The Architecture of a Headache
To survive a gmail migration, you
have to understand that you aren't just moving files from Server A to Server B.
You are translating data between two fundamentally different languages.
Standard email servers (like
TrekMail, cPanel, or bare-metal Postfix) speak "IMAP/Standard."
Google speaks "Google." The differences are subtle, but they are
where the disasters happen.
1.
The "Label" Illusion (The Duplication Trap)
In the standard world, an email
lives in a Folder. It is a physical location. If you move an email from
"Inbox" to "Work," it physically moves.
In Google's world, Folders don't
exist. There is only one massive pile of mail called "All Mail." When
you "move" an email to a folder in Gmail, you are actually just
slapping a sticky note (Label) on it. Crucially, a single email can have multiple
labels. It can be in "Inbox," "Project X," and
"Urgent" simultaneously.
The Migration Risk:
When a standard migration tool looks at Gmail, it sees those three labels as
three separate folders. It will download the same email three times.
- Result:
Your 10GB mailbox explodes into 30GB on the destination server.
- The Fix:
You must map labels carefully. Most importantly, you must strictly exclude
the [Gmail]/All Mail folder from your sync. If you sync "All
Mail" plus your other folders, you are guaranteeing 100% duplication
of every message.
2.
The Throttling Math (Physics vs. Google)
Google does not want you to leave.
They enforce strict bandwidth limits on IMAP data extraction that you cannot
bypass.
- Download Limit:
~2,500 MB (2.5 GB) per day, per account.
- Upload Limit:
~500 MB per day.
The Reality Check:
If you have a CEO with a 50GB mailbox, do the math: 50GB / 2.5GB per day = 20
days.
You cannot migrate that mailbox over a weekend. If you try to force it by
increasing concurrent connections, Google will trigger a "penalty
box" lockout (HTTP 429 errors), and that account will be completely inaccessible
for 24 hours.
3.
Identity is Not Just a Username
In Workspace, users often accumulate
"shadow identities."
- Aliases:
Jane might be jane@company.com, but she also receives mail at info@, sales@,
and jane.doe@.
- Groups:
That support@company.com address might not be a user at all, it could be a
Google Group.
The Migration Risk:
If you only migrate the primary user accounts, every email sent to an alias or
a group will bounce the second you switch your DNS. You need a forensic inventory,
not just a user list.
What
to Preserve (And What You Will Lose)
Manage expectations now, or manage
anger later. IMAP is an email protocol. It handles text and attachments. It
does not handle the proprietary "glue" of the Google ecosystem.
The
"Safe" List (Migrates Perfectly)
- Email Bodies & Attachments: Full fidelity.
- Folder Structure:
Gmail Labels are converted to Folders (with the duplication caveats
mentioned above).
- Read/Unread Status:
Mapped via the \Seen flag.
- Timestamps:
The INTERNALDATE attribute preserves the original receipt time, so your
history doesn't look like it all arrived today.
The
"Friction" List (Requires Manual Work)
- Google Drive/Docs:
These are not files; they are links to Google's database. You cannot
"migrate" them to an email server. You must export them via
Google Takeout or move them to a storage solution like Dropbox or
OneDrive.
- Calendars & Contacts: IMAP does not sync calendars. You must export
calendars to .ics files and contacts to .vcf or .csv files, then import
them into your users' local clients (Outlook/Apple Mail).
- Server-Side Rules:
If a user has a rule saying "Move all emails from @vendor.com to
Trash," that rule lives in Google's brain. It does not transfer. It
must be recreated on the new host.
Recommended
Approach: The "No-Surprises" Runbook
We use a methodology called
"Pre-Stage & Cutover." This is the only way to handle large
mailboxes without downtime.
For a deeper technical dive on the
protocol itself, read our guide on IMAPMigration: How It Works and How to Migrate Mailboxes Safely.
Phase
1: Forensic Discovery
Don't guess. Audit.
- Export User List:
Pull the full user list from the Google Admin Console, including suspended
users.
- Map Aliases:
Use a tool like GAM (Google Apps Manager) or the Admin export to find
every alias.
- Agency Note:
If you are managing 50 domains, do not do this manually. Script the
export.
- Identify the "Whales": Find every mailbox over 15GB. These are your critical
path. You need to start migrating them weeks before your deadline.
Phase
2: The Pre-Stage Sync (The "Silent" Move)
This happens while your users are
still working in Gmail. They won't notice a thing.
- Provision Destination: Create all mailboxes on your new provider (e.g.,
TrekMail).
- Sync History:
Configure your migration tool to sync all mail older than 30 days.
- Run the Job:
Let it run. It might take a week for the "Whales" to finish. If
it hits a throttle limit, let it back off and resume.
TrekMail Context:
If you use TrekMail, our built-in migration tool handles the
"backoff" logic automatically. You enter the source credentials
(usually a Google App Password), and our servers pull the data, respecting
Google's rate limits so you don't get locked out.
Phase
3: The Delta Sync & Cutover
This is the final weekend.
- The Freeze:
Ideally, ask users to stop moving folders around.
- The Delta:
Run a final sync pass. This grabs the last 30 days of mail and updates
read/unread statuses. Because 90% of the data is already there, this pass
is fast.
- The Switch:
Once the Delta reports "Success," you are ready to touch DNS.
Domain
Cutover Checklist (The "Danger Zone")
This is where operators sweat. You
are changing the routing of your company's communication. If you mess this up,
mail bounces, and clients get angry.
For the exact records you need, keep
our Transfer
Email Domain: The DNS Cutover Checklist (MX/SPF/DKIM/DMARC) open in
another tab.
1.
The 300-Second Rule (TTL Strategy)
DNS records are cached. If your MX
record has a TTL (Time To Live) of 86400 (24 hours), and you change it on
Friday night, some servers on the internet will still be sending mail to Google
on Saturday night.
- The Move:
48 hours before your cutover, log into your DNS provider (GoDaddy,
Cloudflare, Route53) and lower the TTL on your MX records to 300 seconds
(5 minutes).
- Why:
This tells the internet, "Check back every 5 minutes for
updates." When you finally switch the record, the world will notice
almost immediately.
2.
Authentication: Don't Break Deliverability
If you switch MX records but forget
SPF and DKIM, your new emails will land in Spam folders.
- SPF (Sender Policy Framework): During the transition, you need to authorize both
Google and your new provider.
- Bad:
v=spf1 include:spf.trekmail.net -all (Blocks Google immediately).
- Good:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all (Allows
both).
- DKIM (DomainKeys):
Set this up before the switch. TrekMail (and others) allow you to
generate the DKIM key before the domain is active. Publish the CNAME/TXT
record now. Since Google and TrekMail use different "selectors,"
they won't conflict.
3.
The Split-Brain Reality
Even with a low TTL, there is a
"long tail" of DNS propagation. For about an hour after the switch,
mail will land in two places:
- New Mail:
Lands in TrekMail.
- Stragglers:
Land in Gmail (from servers that ignored your TTL).
- The Fix:
Keep the Gmail accounts active for 48 hours post-cutover. Run one final
"mini-delta" sync 24 hours later to scoop up any stragglers that
landed in the old inbox.
Post-Cutover:
Client Fixes and Verification
Monday morning is when the helpdesk
tickets arrive. Here is how to close them fast.
1.
The "Re-Add" Rule for Mobiles
Your users will try to just change
the server settings on their iPhone. This rarely works.
Modern iOS and Android versions use OAuth tokens tied to Google. They won't
simply accept a password change to a generic IMAP server.
- The Protocol:
Tell users to Delete the Account and Add New Account (choose
"Other" or "IMAP", not "Google"). It sounds
drastic, but it is 10x faster than troubleshooting cached certificates.
2.
Outlook's "Last Known Good" Problem
Outlook loves to remember that user@company.com
used to be an Office 365 or Google account. It might try to force a connection
to the old server even after DNS changes.
- The Fix:
Create a new Outlook Profile. Do not try to repair the old .OST file.
Start fresh.
3.
Verification: Item Counts vs. Storage Size
A common panic moment: "My
Gmail was 12GB, but TrekMail says 10GB! I lost data!"
- The Truth:
You probably didn't. Gmail calculates storage differently (including
Google Drive metadata, trash, and compression).
- The Metric:
Compare Item Counts. If the Inbox had 5,400 messages in Gmail and has
5,398 in TrekMail, you are fine. The missing two are likely corrupt
calendar invites or zero-byte ghost files.
Where
TrekMail Fits: The Logical Alternative
Let's address the elephant in the
room. Why leave Google?
If your organization lives and dies
by real-time collaboration in Google Docs, if you have complex automated
workflows in Google Sheets, or if your team refuses to use anything but the
Gmail web interface on Workspace. It is a premium product with a premium price.
But if you are an Operator looking
at your P&L and seeing $12,000/year spent on email for staff who only need
to send PDFs and reply to clients, that is wasted capital.
TrekMail is built for the 90% of use cases that just need
professional, reliable email.
- For SMBs:
We kill the per-user tax. You pay a flat rate for the domain. Whether you
have 5 users or 50, the price is the same. You get pooled storage (e.g.,
50GB shared across the team) so you aren't paying for unused space.
- For Agencies:
This is your margin engine. Instead of reselling Workspace at a 10% margin
(and managing 50 different billing relationships), you move your clients
to a TrekMail Agency plan. You pay a flat fee, you charge your clients
per-seat, and you keep the difference.
We handle the dirty work: Managed
SMTP delivery, IP reputation, backups, and security. You just bring the domain.
Ready to stop renting your email?
Check out TrekMail and see how the
math works in your favor.
Comments
Post a Comment