How to Migrate Off Google Workspace Without Breaking Your Week

Leaving Google Workspace feels bigger than it is, because everything is connected: your email is your login, your login holds your files, your files link to your calendar. The trick is to stop treating it as one move and break it into four smaller ones that you can do on separate weekends.

This is a plan, not a product pitch. It works with whatever open-source replacements you land on.

Before you touch anything: take stock

Spend an hour making a list. You are looking for:

• How many mailboxes you actually need, and which ones are real people versus aliases like hello@ or billing@.
• What depends on your Google login. "Sign in with Google" on third-party services is the sneakiest dependency. Search your password manager.
• Shared drives and their owners. Files owned by someone who has left the company are a common surprise.
• Calendar invites with external people. Recurring meetings need their organizer migrated carefully.
• Anything using the Google API. Scripts, automations, backup tools, a CRM that syncs contacts.

Write it down. This list is your migration scope. Everything not on it can wait.

Move 1: Files first (lowest risk)

Files are the easiest thing to move because copying them does not break anything. The originals stay where they are until you delete them.

1. Pick your destination: a self-hosted file sync tool, or plain object storage with a sync client.
2. Do a one-time bulk export using Google Takeout or a sync tool like rclone. For large drives, rclone is more reliable because it can resume.
3. Verify a sample. Open a spreadsheet, a slide deck, a PDF. Check that folder structure and sharing intent survived.
4. Tell people the new location exists, but do not remove Google Drive access yet. Run both for a couple of weeks.

Docs and Sheets are the wrinkle. Native Google formats convert to Office formats on export, and complex spreadsheets with scripts will not survive cleanly. For those, decide case by case: some become static exports, some get rebuilt, and a handful might justify keeping a single Google account around for a while.

Move 2: Calendar

Calendar is low volume but high visibility, because a broken recurring meeting annoys everyone at once.

1. Export each person's calendar as an .ics file.
2. Import into the new calendar server (most speak CalDAV, which is a well-supported standard).
3. Recreate recurring external meetings from scratch rather than importing them. Imported recurring events with external attendees often lose their update thread, so changes stop propagating.
4. Set up calendar sharing between colleagues again. This is manual and easy to forget.

Give it a week of overlap. Keep both calendars live so nothing falls through.

Move 3: Email (the big one)

Email is last among the "content" moves because it is the one people notice immediately if it breaks. Do it when you have a clear few days, not before a busy week.

Preparation:

• Stand up your new mail server or managed open-source mail host. Get it fully working with a test domain or subdomain first.
• Configure SPF, DKIM, and DMARC. Deliverability problems here are the number one reason email migrations go badly.
• Send test mail to a few big providers and check it lands in the inbox, not spam.

Cutover:

1. Lower your domain's MX record TTL to 300 seconds a day ahead, so the switch propagates fast.
2. Use an IMAP-to-IMAP sync tool (imapsync is the standard) to copy existing mail from Google to the new server, per mailbox. Run it once while Google still receives mail.
3. Change the MX records to point at the new server.
4. Run imapsync once more to catch mail that arrived during propagation.
5. Keep the Google mailboxes alive but forwarding for at least a month. Stragglers always appear.

After:

• Update every "send as" alias and every app that sends mail through your domain (invoicing, marketing, your product's transactional email).
• Watch your DMARC reports for a week or two to catch anything still sending as you from the old setup.

Move 4: Identity and logins

This is the one people forget until they are locked out of something.

• Go through your list of "Sign in with Google" services. For each: add a password-based login or switch to a different SSO provider before you close the Google account.
• If you used Google as an SSO provider for your team, stand up an open-source identity provider and re-point your apps one at a time.
• Only when this list is fully clear should you consider actually deleting the Google organization.

A realistic timeline

What usually goes wrong

• Email lands in spam because DKIM or DMARC was not fully set up. Test with real external accounts before cutover, not after.
• A recurring meeting breaks because it was imported instead of recreated.
• Someone is locked out of a vendor tool that only had "Sign in with Google." Do the identity pass early, not last.
• A script silently stops because its Google API credentials were revoked. Grep your automation for API keys during the inventory step.

Done this way, no single step is scary, and at every point you can roll back by just pointing records at Google again. The slow version is the safe version.