How to Cancel Google Workspace Without Losing Your Email

Cancelling Google Workspace is one of the few email decisions that can silently destroy years of mail. This guide is how to cancel Google Workspace without losing email — what actually happens to your custom-domain mailboxes when the subscription ends, the exact order to export before you cancel, and how to move the MX record so no message drops on the floor mid-cutover. The single most common mistake is cancelling first and asking about export second; that is the version that loses mail.

Two things make this cutover higher-stakes than most SaaS cancellations. Custom-domain mailboxes at yourcompany.com are not consumer Gmail accounts you can just downgrade to a free tier — the address itself is tied to the paid subscription, and Google's free consumer Gmail does not host custom domains. And the grace window Google gives you after cancellation is measured in days, not months. Once the subscription ends, the recovery clock is short, and it is running against you.

This is a planning guide, not a click-by-click walkthrough. Both the Google Admin console and the Workspace cancellation flow change on their own release schedule, so the steps below link to Google's own live pages for the exact clicks rather than restating a UI that will look different in six months.

What actually moves — and what doesn't#

The mental model that gets people into trouble is treating Workspace like a Netflix subscription: cancel and the account sits there quietly, waiting. It does not. When you cancel the subscription, the associated user accounts and their Gmail data are on a countdown, and the domain-attached mailboxes go with them. There is no automatic export, no consumer-Gmail inheritance, and no long grace period.

The table below is the honest map of what survives cancellation, what needs an active export before you cancel, and what is a separate migration project entirely. Notice how many rows are "export before you cancel" — that is the whole reason the sequence in this guide matters.

The row people underestimate is the second one: the email address. When the MX record stops pointing at Google, every mail server on the internet learns about it on its own schedule and starts trying the new destination — but only if there is a new destination. Cancelling Workspace without provisioning a new mail host first turns every message from that moment into a bounce. Not a delay. A bounce.

The retention window: how long you actually have#

Google does publish a post-cancellation retention window during which admins can restore user data, and it changes. Rather than repeat a number that will be wrong by the time you read this, treat the window as "short, and it starts the moment you cancel." Verify the current period on the Google Workspace Admin Help page before you rely on it, and assume less than you find, because retention is not the same as guaranteed export access — some admin surfaces stop working the instant the subscription ends even if the underlying data still exists for a few days.

The practical implication is that you never want the retention window to be the plan. The plan is: complete the export while the subscription is fully paid and active, verify the exports open, stand up the new host, cut the MX record, and only then cancel. The retention window is your safety net for the mistake you did not catch, not the runway for the migration itself.

Pre-migration checklist#

Before you touch the cancellation button, work through this list end to end. Every item on it is a thing that has, in real migrations, turned into lost mail or a week of downtime when it was skipped.

• You have chosen and provisioned the destination mail host — Microsoft 365, Fastmail, Zoho Mail, Proton, another Workspace tenant, or a self-hosted stack — and every yourcompany.com address exists there.
• Every user knows their new mailbox password (or SSO is wired up), and can log in and send a test message from the new host through a temporary hostname before you touch MX.
• You have exported every mailbox as MBOX using either the admin Data Export tool (for the whole tenant at once) or per-user Google Takeout, and the exports open in a mail client you can read them with.
• You have exported calendars as ICS and contacts as vCard or CSV, and confirmed at least one of each imports into the destination.
• You have downloaded or transferred anything from Drive, Shared Drives, and Vault that the business cannot afford to lose.
• You have documented the current MX record, SPF record, DKIM selector, and DMARC policy for the domain, so you can restore them exactly if the cutover has to be rolled back.
• You have lowered the domain's MX TTL to 300 seconds at least 48 hours before the planned cutover, so the change propagates fast when you make it.
• You have a scheduled window — evening or weekend — for the actual cutover, with someone available to watch the mail queue on both sides for the first hour.

How to cancel Google Workspace without losing email — the steps#

Run this sequence in order. Every step assumes the previous one succeeded and was verified, not just clicked.

1. 1

   Provision the new mail host and every mailbox on it

   Create the tenant or account at the destination provider, add yourcompany.com as a verified domain, and create every user's mailbox there. Do not point MX at it yet — the new host should be reachable via its own hostname (like alice.newhost.com) so you can send test mail to and from it without disturbing production.

2. 2

   Export every mailbox from Google, twice if it matters

   For an admin-run export, use the Data Export tool in the Google Admin console — it packages the whole tenant's Gmail, Calendar, Contacts, Drive and more into an archive available for download. For individual users, Google Takeout at takeout.google.com produces the same MBOX-per-mailbox format. Download the archive, unzip it, and open at least one MBOX in a real mail client to confirm the mail is readable, not corrupt.

3. 3

   Import the exported mail into the new host

   Most destinations accept MBOX either directly or via an IMAP upload from a desktop client. If your destination has a native Google Workspace migration tool (Microsoft 365's Exchange admin center is the best-known example), use it against the live Workspace mailboxes over OAuth rather than round-tripping through MBOX — a live-to-live migration preserves folder structure and read/unread state that MBOX imports sometimes lose.

4. 4

   Lower the MX TTL, wait, then cut over

   Twenty-four to forty-eight hours before the cutover, drop your domain's MX TTL to 300 seconds. When you actually change the MX record to point at the new host, most of the internet's mail servers will pick it up within minutes rather than hours. Change MX, SPF, DKIM, and DMARC together, using the exact values your new host publishes.

5. 5

   Run a final delta sync

   In the window between when you last exported and when MX flips, some mail will have landed at Workspace. Do a final IMAP or migration-tool sync for that delta immediately after the MX change, so the last hour of mail lands in the new mailbox instead of only living in a Google account you are about to cancel.

6. 6

   Verify mail flow at the new host for at least 24 hours

   Send from an outside address to each critical mailbox, check spam scores on mail-tester.com, look at the mail logs at the new host, and confirm that replies from your users land where you expect. Do not cancel yet. Keep Workspace paid and live during this observation period so that any misconfiguration is a fix, not a disaster.

7. 7

   Cancel the Workspace subscription

   Once the new host has been receiving mail cleanly for a day or more and the exports are safely stored outside Google, cancel the subscription in the Google Admin console under Billing → Subscriptions. Keep the archived exports for at least the length of your data-retention policy — the mail may be worth accessing years later even if the subscription is gone.

What breaks and when — the cutover matrix#

The value of a matrix here is that most "we lost mail during the move" incidents are one specific breakage that happened at one specific moment. Naming them makes them avoidable.

Rollback plan if something goes wrong#

The whole reason to leave Workspace live during the observation period is that rollback stays cheap. If the new host is misbehaving, revert MX to the original Google values and mail flows back to Workspace within minutes. Rollback becomes expensive the moment you have cancelled — after that, the domain has nowhere paid to fall back to.

1. 1

   Revert MX to the documented Google values

   The four Google MX records you recorded during the pre-migration checklist go back exactly as they were. Because you dropped the TTL to 300 seconds before the cutover, propagation is minutes, not hours.

2. 2

   Re-enable SPF and DKIM alignment for Google

   Put the Google SPF include back into your SPF record and re-enable the Google DKIM selector in the Admin console. If you already published new SPF for the destination host, keep both includes temporarily rather than swap one for the other.

3. 3

   Replay any mail that arrived at the new host during the broken window

   Forward or import from the new host back into the corresponding Workspace mailboxes so the archive at Google is complete. This is the reason to keep the new host live during rollback rather than deleting it.

4. 4

   Diagnose in daylight, cut over again on a fresh window

   Do not iterate on the destination during a live cutover. Roll back, fix the problem on the new host with test mailboxes and a subdomain, prove it works end to end, then schedule a new cutover window.

Doing it without downtime#

Zero downtime on a domain-level mail cutover is possible, and it comes from three habits, not from any single tool. The first is timing — schedule the MX change for the lowest-traffic hour of your week, typically Friday evening or Saturday morning in your business's main timezone, so that even a small propagation delay lands in a period where a delayed mail is not a missed deal.

The second is dual delivery during the observation period. Some destinations (Microsoft 365, for example) can be configured with mail routing so that mail arriving during the cutover window is delivered to both hosts. Where dual delivery is not natively supported, a temporary Workspace-side rule that forwards a copy of every incoming message to the equivalent new-host address achieves the same effect. This turns "we might miss mail" into "we will have every mail at both places and pick the better copy."

The third is not a technical trick: it is telling external contacts nothing. A quiet, well-executed cutover reads to the outside world as no change at all — the address is the same, the domain is the same, replies flow. It is only the customer-visible outages and "please email our new address" messages that turn a migration into a communications event, and none of those are necessary here because the domain does not move.

Does downgrading to a free account keep the mail?#

This is the most common wrong assumption in the entire topic, so it deserves its own answer. No — there is no downgrade path from paid Google Workspace to free consumer Gmail that preserves a custom-domain mailbox, because free consumer Gmail does not host custom domains at all. The two products are related in branding, not in what they do.

What people usually mean by "downgrade" is one of two things. One: they want a cheaper paid plan, which is a plan change inside Workspace and does keep the mail. Two: they want to stop paying entirely while keeping the address, which is not possible on Google — the address itself is the paid feature. If you want the address without paying Google, the answer is to move to a different host, which is what the rest of this guide is about.

Where AI Emaily fits after the move#

Once the mail is off Google Workspace and living at a new host, the mailbox has to be worked, and that is where AI Emaily fits. We are an AI-native email client that connects over Gmail, Outlook / Microsoft Graph, and any IMAP account — so the archive you just rescued from Workspace, whether it now lives in Microsoft 365, Fastmail, Zoho, Proton or another IMAP host, becomes a normal live mailbox: searchable, triaged, and worked by an assistant that files, drafts in your voice, and closes loops. Full disclosure — we build AI Emaily.

Here is the honest limit, because it is worth naming plainly: if your team also lived inside Google Docs, Meet, and Drive as much as Gmail, moving mail is only half the project — Microsoft 365 or an equivalent suite is the right destination for the rest, and AI Emaily does not replace those tools. We are an email client, not a productivity suite. Where we help is the part after "mail is at the new host": approve-before-send drafts, Copilot and Autopilot modes with a full audit trail, and one inbox across every provider you might land on.

Putting it together#

The whole difference between a successful Workspace cancellation and a catastrophic one is the order of operations. Provision the new host first, export every mailbox while the subscription is fully paid, run a live migration or MBOX import into the destination, cut the MX record after everything is verified end to end, and cancel Workspace last. The cancellation itself is a two-minute click; the two weeks around it are the actual work.

Everything else is a variation on that sequence. Larger tenants add licensing and SSO checks. Regulated tenants add Vault exports and legal-hold sign-off. Teams that live in Google Docs and Drive add a suite-migration workstream that runs in parallel. But the mail side of the story is always the same: export before you cancel, move the domain before the users lose access, and never let the cancellation window be your safety net.