Switching from Google Workspace to a different mailbox host takes about a week of clock time and 3-4 hours of active work when done carefully. The trick is parallel-receive: configure the new host while Workspace still accepts mail, run the IMAP migration tool to copy historical mail in the background, then flip MX records with low DNS TTL so cutover takes minutes not hours.
Most "switching from Google Workspace" guides describe cold cutovers that drop messages during DNS propagation. The cold pattern usually loses 10-50 messages depending on inbound volume. The six-step pattern below loses zero. The extra discipline costs 30 minutes of setup and prevents the year-zero "what happened to that customer email?" scramble.
This guide walks the six-step migration with concrete DNS-record blocks. For the broader frame see migrate email from Google Workspace.
Why Switching From Google Workspace Is More Doable Than It Looks
Switching from Google Workspace looks intimidating because Workspace bundles mail, calendar, Drive, and Meet under one identity. The intimidation is mostly about the bundle. The mail piece by itself is just IMAP plus DNS records, which migrate cleanly to any IMAP-supporting host.
The actual switching effort splits cleanly. Mail: 1-2 days of work using the six-step pattern below. Calendar: Workspace's calendar export plus import at the new calendar host (Fastmail Calendar, Apple Calendar, or self-hosted CalDAV). Drive: rsync-style copy to the new file storage host. Meet: replace with Zoom or similar at signup. Each piece migrates separately, which makes the total project feel less overwhelming than "switching from Google Workspace" suggests.
The Six-Step Migration at a Glance
Six steps cover switching from Google Workspace mail without losing inbound messages during the cutover window. The order matters: each step's output enables the next, and skipping any step creates downstream gaps that cost mail-in-flight loss during the DNS propagation transition.
- Lower DNS TTL 48 hours ahead. Reduces MX propagation time from hours to minutes during the cutover window.
- Provision the new host. Add the domain at the new mailbox host; create matching mailboxes.
- Run IMAP migration in background. Copy historical mail from Workspace to the new host while Workspace still receives.
- Flip MX records. Point DNS at the new mailbox host. Parallel-receive during propagation.
- Verify and round-trip test. Confirm authentication passes at three receivers.
- Decommission Workspace. Wait 48-72 hours after MX flip, then disable Workspace mailboxes.
The whole sequence takes about a week of clock time. Active work is 3-4 hours spread across the week. The discipline of the six-step pattern prevents the mail-loss patterns that ad-hoc switching from Google Workspace migrations consistently produce.
Step 1: Lower DNS TTL 48 Hours Ahead
Step one of switching from Google Workspace is lowering DNS TTL on MX records 48 hours before the planned cutover. Workspace's default MX TTL is usually 3600 (one hour). Lower to 300 (five minutes) so the MX flip in step 4 propagates fast.
; before — default TTL
yourcompany.com. 3600 IN MX 1 aspmx.l.google.com.
; after — low TTL for cutover window
yourcompany.com. 300 IN MX 1 aspmx.l.google.com.
Edit each MX record's TTL at the DNS host. The change propagates over the next 1-2 hours as caches expire. Wait 48 hours for the low TTL to fully propagate worldwide. After the migration completes in step 6, raise the TTL back to 3600 for normal operation.
Step 2: Provision the New Host
Step two of switching from Google Workspace provisions the new mailbox host. Sign up at TrekMail (or your chosen alternative). Add the domain in the dashboard. Verify ownership through the verification TXT record. Create mailboxes matching the names at Workspace (sarah.smith@, mike.davis@, etc.). Generate SPF, DKIM, and DMARC values but don't publish them yet — that happens in step 4.
At this point the new host has the mailboxes ready but MX still points at Workspace, so no real mail arrives at the new mailboxes yet. The provisioning is preparatory work that makes the parallel-receive cutover in step 4 work cleanly. See Google Workspace replacement for the broader replacement-vendor frame.
Step 3: Run IMAP Migration in Background
Step three of switching from Google Workspace runs IMAP migration in the background. TrekMail's server-side IMAP migration tool handles this. Provide Workspace IMAP credentials per mailbox; the tool copies folder-by-folder over a few hours while Workspace still receives new mail in parallel.
Most migrations finish within 24 hours for typical mailbox sizes (1-10GB per user). Heavy mailboxes (50GB+) take longer. Run the migration ahead of the cutover so all historical mail is present at the new host before step 4 fires. Monitor the migration through the dashboard; the tool surfaces errors per mailbox if any individual mailbox has IMAP issues that need attention.
Step 4: Flip MX Records
Step four of switching from Google Workspace updates MX records to point at the new host. Publish the new MX values plus SPF, DKIM, and DMARC records from step 2. DNS propagation takes about 5 minutes given the low TTL from step 1.
; new MX pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; authentication records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
During the propagation window, some receivers still send to Workspace while others use the new host. Both receive in parallel — no mail bounces. Keep Workspace mailboxes active and accessible for at least 48-72 hours after the MX flip to catch lingering mail-in-flight from receivers with longer DNS caches.
Step 5: Verify and Round-Trip Test
Step five of switching from Google Workspace verifies authentication on outbound mail from the new host. Send test messages from each mailbox to Gmail, Outlook.com, and Yahoo accounts. Confirm headers read SPF=PASS, DKIM=PASS, DMARC=PASS at all three. Any FAIL means the records published in step 4 need adjustment before going production.
Also verify inbound: send a test message from an external address to one of the new mailboxes. Confirm it lands at the new host within a few minutes. If mail arrives at Workspace instead, DNS propagation hasn't completed yet — wait another 10-15 minutes and retest. The verification is non-negotiable; skipped verification means deliverability problems surface at scale rather than at cutover time.
Step 6: Decommission Workspace
Step six of switching from Google Workspace decommissions the Workspace mailboxes 48-72 hours after the MX flip. DNS propagation is complete globally. Disable mailboxes through the admin console; cancel the subscription at the end of the current billing cycle. Raise DNS TTL back to 3600.
Keep a Workspace data export (Mail, Calendar, Drive) before the final cancellation in case you need historical access later. Google's Takeout service handles the export; download it to local storage before the subscription terminates. The export gives you a backup of historical Workspace state independent of the new host. See email migration checklist for the structured run sheet.
Next Steps
The six-step pattern for switching from Google Workspace mail takes about a week of clock time and 3-4 hours of active work, with zero mail loss when the parallel-receive setup is done correctly. The new host catches mail-in-flight during propagation while Workspace continues handling whatever stragglers arrive at the old MX.
Test TrekMail Nano free at trekmail.net/pricing — no card required. Starter at $4/month includes the server-side IMAP migration tool needed for step 3 of switching from Google Workspace. The flat-rate model at $42/year typically saves 90%+ on the Workspace bill for mail-focused teams that don't depend on Docs/Sheets daily across most seats. See IMAP migration for the broader IMAP-migration frame.
A concrete example: a 24-person SaaS company in Helsinki switching from Google Workspace after years on the platform. Pre-migration spend: $1,728/year on Workspace Business Starter. Migration: 5 days clock time including the low-TTL window, parallel-receive cutover, IMAP migration of 180GB of historical mail across 24 mailboxes. Post-migration spend: $96/year on TrekMail Pro for the same workload. Annual savings: $1,632 funding the team's Notion subscription plus margin to spare across the operating year following the migration completion event.
A second example: a 40-person mid-market firm in Tel Aviv switching from Google Workspace Business Standard. Pre-migration: $5,520/year. The team's audit revealed Docs/Sheets usage concentrated in 8 specific seats (executives plus accounting). Migration plan: TrekMail Pro for the 40 mailboxes ($96/year) plus 8 retained Workspace Business Starter seats for the doc-heavy users ($576/year). Total post-migration spend: $672/year. Annual saving: $4,848.
The pattern across both examples: switching from Google Workspace doesn't have to be all-or-nothing. Teams that audit which seats actually use the productivity bundle can split — most seats move to flat-rate mail-only hosts while doc-heavy seats stay on Workspace. The split usually saves 70-90% of the Workspace bill while preserving the productivity bundle for users who genuinely depend on it.
