Migrate Google Workspace to JustEmails: 5-Day Zero-Loss Runbook
Migrate Google Workspace without losing mail — 5-day runbook inside.
Migrate Google Workspace without losing mail — 5-day runbook inside.
The migration email arrived on a Tuesday: "Your Google Workspace subscription renews in 14 days." That was the morning we decided to migrate Google Workspace to JustEmails.
We stared at it. Fourteen users, each one billed per head, every month, forever. The Docs and Sheets are nice, but everyone's in Notion anyway. And the per-user storage sounds generous right up until you check Reports and find nobody's touched more than 3GB.
Look, I'll be honest — I've messed up migrations before. Forgot to lower TTL once and spent a weekend watching mail disappear into the void. That was fun.
We're the JustEmails team — built by Velocity Digital Labs, same people behind JustAnalytics and ClickzProtect. We've walked a fair few teams off Google Workspace over the past year, and the pattern never changes: they're nervous about losing mail, nervous about the DNS cutover, nervous about breaking something they don't fully understand. (Honestly? That nervousness is healthy.)
This is the runbook we use. Five days, zero lost email, and a final bill of $49/year flat instead of a line item that grows every time you hire.
Every historical message migrated, every mailbox receiving new mail, SPF/DKIM/DMARC configured, Google Workspace ready to cancel. Same addresses, same clients, same IMAP. Your team shouldn't notice.
You'll need:
One thing people forget: you need app passwords for Google accounts with 2FA enabled. Regular passwords won't work with IMAP. Generate these in Google Account → Security → App passwords before day one.
(Ask me how I know. Go on.)
One caveat on that trial, because it stops people cold on Day 1: a trial account is capped at 1 domain, 2 mailboxes and 1 GB of storage, with no API access at all. Fine for checking that IMAP connects and your DNS is shaped right. Nowhere near enough to move fourteen people. Be on the paid plan before you start — the trial is great for kicking the tyres and useless as a migration runway. Different jobs.
One more number, because it shapes the whole plan. Outbound sending is capped per account per day, and it ramps: a new account with a new domain — you, if you're signing up for this — sits at 20 sends a day for the first week, 200 a day in the second, 500 a day from day 15. Mailbox sends and API sends share that allowance. No side door.
Two misreadings to head off. It's per account, not per mailbox — fourteen users share one number, and that's the bit that catches people. And the warm-up clock belongs to the domain, running from the day you verify it rather than the day you signed up. Add a second domain to a year-old account and that domain warms up from scratch; the account's age doesn't carry across. The dashboard shows the figure that applies to you today, which is a better source than working it out from a blog post. Including this one.
The imapsync copy doesn't draw on any of it — that's an inbound write. The caps govern what your team sends after cutover, so tell them on Day 1 rather than letting a rep hit a wall on Day 3.
Log into JustEmails and add your domain — the dashboard walks you through TXT-record verification. Then create a mailbox per user, matching addresses exactly: sarah@yourcompany.com in Google Workspace means sarah@yourcompany.com here.
Don't mess with MX records yet. We're not cutting over today.
The mailbox password you set is the IMAP and SMTP password. There's no separate app-password screen on the JustEmails side — if a tutorial tells you to generate one, it's describing a screen that doesn't exist. Save each password as you go; imapsync wants them shortly.
While you're in there, separate two things that sound identical and aren't. A mailbox is free and unlimited. A team member — someone who needs their own login to the dashboard to manage domains and DNS — is $2 a month. Fourteen people reading mail in Outlook need fourteen mailboxes and zero team members. The two of you who actually administer the account need seats.
Then stop and do the storage arithmetic. The 10 GB on the plan is an account-wide pool, not 10 GB per mailbox — nobody reads it that way the first time, us included. Fourteen mailboxes at roughly 3 GB each is over 40 GB about to be poured into a 10 GB bucket. Extra storage is $99 a year per 100 GB and the blocks stack, so one covers that with room left. Your real numbers are in Google's Admin console → Reports → Storage.
Buy it before the sync. Not at 2am with a progress bar in front of you, which is when we did ours.
imapsync is the workhorse. It copies mail between any two IMAP servers, preserving folder structure, flags, and dates. On Ubuntu/Debian it's sudo apt install imapsync; on macOS, brew install imapsync.
It's twenty-year-old Perl with a help text longer than this article, and it has never once let me down.
Then check the version:
imapsync --version
You want 2.x or higher. Older builds have bugs with Gmail's folder naming.
The command template — swap in your own values:
imapsync \
--host1 imap.gmail.com --port1 993 --ssl1 \
--user1 "sarah@yourcompany.com" --password1 "google-app-password" \
--host2 mail.justemails.app --port2 993 --ssl2 \
--user2 "sarah@yourcompany.com" --password2 "justemails-password" \
--gmail1 --automap --exclude "^\[Gmail\]/All Mail$"
--gmail1 handles Gmail's weird folder mapping (labels become folders, All Mail is a pseudo-folder), --automap works out the names, and --exclude skips All Mail — it's a duplicate of everything already in your folders.
Run this for every mailbox. For 14 users, we wrote a simple bash loop:
while IFS=, read -r user gpass jpass; do
imapsync \
--host1 imap.gmail.com --port1 993 --ssl1 \
--user1 "$user" --password1 "$gpass" \
--host2 mail.justemails.app --port2 993 --ssl2 \
--user2 "$user" --password2 "$jpass" \
--gmail1 --automap --exclude "^\[Gmail\]/All Mail$"
done < users.csv
The CSV has three columns: email, google app password, justemails password. Not pretty, but it works. Elegance is overrated when you're moving 14 mailboxes at midnight.
First sync takes a while — a 5GB mailbox runs 2-4 hours depending on your connection. Let it go overnight. imapsync is resumable, so if it crashes you just run it again and it picks up where it stopped. This is the one time I'll advocate for "start it and go to bed."
Before you touch MX records, lower the TTL on your existing ones. At a 24-hour TTL (86400), some mail servers will cache the old MX for a full day after you change it — a day of mail going to the wrong place. In Cloudflare: DNS → Records, find each MX, set TTL to 300, save.
Then wait 24 hours. Seriously. The old TTL has to expire everywhere before the new short one takes effect. This is the boring part. I know you want to skip it. Don't. Skipping it is how you get mail delivered to Google for 6 hours after you thought you'd cut over.
While waiting, grab the records you'll need from your JustEmails domain settings:
mail1.justemails.app at priority 10)a:mail1.justemails.app)Write these down or screenshot them. You'll add them on Day 3.
This is the scary day. It's also simpler than people think.
Deep breath.
In your DNS panel, delete the old Google Workspace MX records:
ASPMX.L.GOOGLE.COM (priority 1)
ALT1.ASPMX.L.GOOGLE.COM (priority 5)
ALT2.ASPMX.L.GOOGLE.COM (priority 5)
... etc
Add the JustEmails MX record. Singular — Google's whole stack of rows comes out, and one goes back in:
mail1.justemails.app (priority 10)
Coming from Google's stack of primaries and alternates, one line looks like a mistake. It isn't. Inbound mail arrives on a single host, so don't pad the zone with an invented mail2 at priority 20 — a backup MX that doesn't resolve adds retries, not resilience.
Find your existing SPF record. It probably looks like:
v=spf1 include:_spf.google.com ~all
Change it to:
v=spf1 a:mail1.justemails.app ~all
Google's was an include:; ours is an a:, which authorises whatever IP mail1.justemails.app resolves to instead of delegating to another TXT record. Swapping the hostname inside include: is the natural mistake, and a quiet one: the record parses, authorises nothing, and SPF fails while your DNS panel looks perfectly healthy.
If you're also using other senders (Mailchimp, SendGrid, your app's transactional email), keep their includes:
v=spf1 a:mail1.justemails.app include:servers.mcsv.net include:sendgrid.net ~all
One SPF record only. I have watched smart people create a second one: two records means SPF fails validation outright, which means the spam folder. A fun debugging session you don't want.
JustEmails generates the DKIM keys for you — there's nothing to create on your end. Your domain settings page lists the exact records to publish, selector names and all. Copy them from there, verbatim.
I'll be blunt about why: do not retype a DKIM hostname from memory, or from another tutorial, ours included. A record pointing at a name that doesn't resolve fails silently. It parses. Your DNS panel goes green. Your mail goes out unsigned and you hear about it from a deliverability complaint three weeks later.
The one detail worth knowing in advance is the underscore — the record name contains _domainkey, and some DNS panels will "helpfully" rewrite underscores on you.
Delete the old Google DKIM record (google._domainkey) once JustEmails is signing. Keeping it doesn't break anything. It's just dead weight.
Here's where people mess up. Don't tighten DMARC during a migration. At p=reject, consider dropping to p=quarantine for a week; at p=none, stay put.
The change that matters: check your rua address still works. If it points at a Google Workspace inbox that no longer receives mail, you've just gone blind to authentication failures at the exact moment you need to see them.
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=r; aspf=r
Our guide on ramping DMARC safely covers the policy progression if you want to tighten up after the migration settles.
Don't trust "instant" propagation. Check with MXToolbox:
https://mxtoolbox.com/SuperTool.aspx?action=mx:yourcompany.com
You should see the single JustEmails MX host. Check SPF and DKIM while you're there. Anything still showing Google means wait — that's what yesterday's TTL drop was for.
Then send a test mail from an outside account to a migrated address, and confirm it lands in JustEmails rather than Google.
Mail that arrived at Google between your initial sync and the MX cutover is still sitting in Google. Run the exact same command from Step 3 again, for every mailbox — or just re-run the bash loop.
imapsync only copies new and changed messages, so nothing duplicates. The delta sync is usually minutes, not hours.
Your team's mail clients need new server settings:
Incoming (IMAP):
Outgoing (SMTP):
Outlook, Apple Mail, Thunderbird, mobile apps — all of them. Budget 15 minutes per person. Some will figure it out instantly; others will need a screenshot of every step. (You know who they are.)
If you have DMARC aggregate reports flowing (you should), look for alignment failures over the past 48 hours. A spike means something is sending as your domain without being authenticated against JustEmails yet. Usual culprits: a marketing tool still holding old SMTP credentials, a transactional service you forgot about, or calendar invites forwarded from Google — that last one caught us off guard.
Fix each by updating its SMTP config or adding its sender to your SPF record. Tedious? Yes. It's also the only part of this migration that hands you an honest inventory of what's been sending mail as you for the last three years. Ours turned up a status-page tool I'd forgotten we paid for.
Don't cancel Google Workspace immediately. Their post-cancellation retention window has historically run about a month — confirm the current terms in Admin before you lean on it — and some stragglers will still have your old MX cached, especially big corporate mail servers that cache like it's 2009.
Run imapsync one more time at day 14 and day 28. Belt and suspenders.
On day 30, log into Google Admin, verify the mailboxes show zero new mail, and cancel. If you're paranoid (we are), download a Google Takeout export first. Then close the tab and try not to think about how much you overpaid for years.
imapsync fails with "NO AUTHENTICATE"
Nine times in ten the Google app password is wrong, or you generated it while signed into a different Google account. Regenerate. Check the account picker first.
The client can't find the server at all
Same host for both directions — mail.justemails.app. If your mail client helpfully auto-filled imap. or smtp. in front of your domain, that's your bug: neither of those hostnames exists, so the connection dies at DNS lookup before it ever reaches us. You get a timeout instead of an error message, which is the least useful failure mode there is.
Mail arrives at Google after MX cutover
Propagation isn't finished. If your old MX TTL was 86400, you may be waiting a while yet. Keep Google Workspace active, keep running delta syncs.
DKIM fails in MXToolbox
Give it 15-60 minutes to propagate. If they still show as missing after an hour, put the dashboard next to your DNS panel and compare them character for character. The underscore is the usual culprit: it's selector._domainkey.yourcompany.com, never selector.domainkey.yourcompany.com.
Folder names are mangled
Gmail labels don't map 1:1 to IMAP folders. --automap handles most cases, but nested labels like Projects/ClientA sometimes flatten. You can remap with --regextrans2, though honestly it's faster to drag-and-drop the handful of affected folders in your mail client.
imapsync handles these automatically. Gmail's [Gmail]/Sent Mail maps to Sent, [Gmail]/Drafts to Drafts. Duplicates almost always mean the "All Mail" pseudo-folder got synced — that's why we exclude it.
The move to $49/year flat is real; we made it ourselves, and we've watched enough teams make it to know where the gotchas hide. The 5-day window isn't about the technical work. It's about giving DNS time to propagate and giving yourself time to catch mistakes before they cost you mail.
Is it glamorous? No. But neither is a mail bill that climbs every time you hire someone.
Questions? support@justemails.app. We answer email. (Obviously.) For the DNS groundwork that comes first, see our custom domain email setup guide, and if you're still comparing, how JustEmails stacks up against Google Workspace.
Plan for a 5-day window. Day 1 is setup and initial IMAP sync. Days 2-3 are TTL lowering and MX cutover. Days 4-5 are verification, delta sync, and cleanup. The actual hands-on work is 3-4 hours total, but you're spacing it out to catch any stragglers and let DNS propagate. Rushing it is how you lose mail.
Not if you follow the dual-delivery window. Keep Google Workspace active for 30 days after cutover; Google's own post-cancellation retention window has historically run about that long, though it's worth confirming the current terms in Admin. Run imapsync twice: once before MX cutover (bulk), once after (delta). Any mail that lands at Google during the gap gets pulled in the second sync.
Yes. Your SPF record swaps Google's include:_spf.google.com for JustEmails' a:mail1.justemails.app — note that ours is an a: mechanism, not an include, so there's no JustEmails hostname to put inside include:. DKIM keys are provider-specific, and JustEmails generates the new ones for you — publish the records your domain settings page lists, copied from the dashboard rather than retyped from a tutorial. DMARC stays the same, but watch aggregate reports for alignment failures the first week.
Yes. Mailboxes are unlimited on the $49/year plan and creating one has no billing effect. Do it on the paid plan though — a trial account is capped at 2 mailboxes and 1 GB of storage, which won't hold a real team. Create all the accounts first, then run imapsync in parallel, one process per mailbox. We've run a dozen at once from a cheap VPS. The bottleneck is Google's IMAP rate limiting, not JustEmails.
Custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB of pooled storage, full IMAP/SMTP, and a unified inbox across every domain you own. Built for agencies, freelancers, and anyone managing email across more than one domain.
Start the 7-day trial → — card required, nothing charged until it ends. · How it compares