Migrating from Microsoft 365 to Google Workspace: A Zero-Downtime Field Guide

TL;DR

Migrating from Microsoft 365 to Google Workspace is not “import the PSTs and switch the MX”. The work is identity sync, mail dual-delivery, bulk content move, and a controlled DNS cutover, with Drive permissions, calendar recurrences and Teams chat history as the predictable trouble spots. We have run this sequence more than thirty times. Plan around the failure modes and end users see one thing change overnight: the icon they click for email.

Why are people moving from M365 to GW?

Three reasons keep recurring on the discovery call. None of them is “we hate Microsoft.”

The first is collaboration culture. A team that lives in shared Google Docs, where ten people edit the same URL at the same time without tracked-changes ceremony, will quietly resent SharePoint and OneDrive. The Microsoft stack does collaborative editing, properly, but the muscle memory is different. Companies that hire under thirty-five and run distributed gravitate to Workspace whether IT planned it or not.

The second is cost, but rarely in the headline way. Per-seat, Business Premium and Workspace Business Standard land in the same neighbourhood. The savings show up in operations: fewer admin hours, less third-party tooling, no Conditional Access policy estate to maintain quarterly. A 60-seat tenant we moved last year cut annual managed-IT spend by roughly 22%.

The third is OEM-buying decisions further up the stack. A business gets bought, the parent runs Workspace, the new CFO wants one estate. Or the founders pick ChromeOS hardware to dodge the Windows 11 upgrade cycle, and once the fleet is Chrome the productivity suite follows. We’ve migrated companies the other way too. See the Google Workspace and Microsoft 365 pages for the fit comparison.

What does the migration sequence look like at a high level?

Six phases, in this order, every time. Skip a phase and something breaks.

1. Provision Google Workspace. Tenant created, primary domain verified (TXT record, leave MX alone), Cloud Identity SKU decided, OU skeleton built, super-admin and break-glass accounts on hardware keys.
2. Identity sync. Users created in Workspace from the M365 source of truth, via GCDS or SCIM.
3. Mail dual-delivery. Inbound mail copied to both tenants during the migration window. Users see no gap.
4. Bulk content move. Mail, Drive, Calendar move on the back end while users keep working. Multiple passes with delta syncs.
5. Cutover MX. Friday evening, DNS swap, mail flow now primary to Workspace, Outlook profiles retire over the weekend.
6. Decommission. M365 licences ramp down on the partner agreement, mailboxes archived for legal hold, the tenant retired or kept skeleton-only for legacy services.

The whole run is typically six to ten weeks of elapsed time for a 50-seat estate, of which the visible cutover is one weekend. Bigger estates run twelve weeks plus. We have done compressed two-week migrations and we don’t recommend them.

Identity and provisioning

Identity is where the migration rests on solid ground or wobbles forever. Two provisioning patterns; the choice depends on what you want the post-migration estate to look like.

GCDS (Google Cloud Directory Sync) is the classic answer. It runs on a Windows host, reads from your source directory (Entra ID via LDAP, or the on-prem AD that still feeds Entra), and one-way provisions users, groups and OUs into Workspace. Heavily configurable, deals with multi-domain estates cleanly, the right answer when you intend to retire Entra eventually.

SCIM is the right answer when Entra ID stays as your primary IdP and Workspace becomes one more SAML-connected app. Entra pushes provisioning into Workspace, you keep MFA and Conditional Access in Microsoft, Google trusts the SAML assertion on every login. We use this pattern for mixed estates: Workspace for productivity, M365 still on the bench for Teams telephony or Power BI, Entra as the identity spine.

OU mapping is the bit that matters most for downstream policy. Workspace policies attach to OUs, not groups. Map a flat M365 tenant into a flat Workspace OU and every policy applies tenant-wide; you’ve thrown away the granularity that makes admin sane. Redesign the OU tree before sync starts. Per-department, per-region, per-role; pick the metaphor.

Aliases catch people out. M365 mailboxes often carry three or four SMTP aliases accumulated since 2014. Workspace supports aliases on the user object but they need to be explicitly recreated. Miss one and the personal address Jane has been giving out for a decade starts bouncing on cutover Monday. Run a Get-Mailbox | Select PrimarySmtpAddress, EmailAddresses extract during discovery and feed it to the user-creation script.

Mail migration: data movement

The actual mailbox data has more options than people realise, and the right tool depends on size, source mix, and how clean you want the result.

Google Workspace Migrate and Migrate for Microsoft 365 are Google’s first-party answers. They run on a Windows server, talk to Exchange Online via Graph API or EWS, and pull mail, contacts and calendar items into Workspace. Free with a Workspace licence; for tenants under a few hundred mailboxes the job is clean.

BitTitan MigrationWiz is the third-party heavyweight most consultants reach for above 200 mailboxes. Per-mailbox licensing, but throughput is meaningfully higher, scheduling and retry logic is mature, and reporting is friendlier when you need to show a project sponsor a percentage-complete chart. For mixed-source estates (some Exchange Online, some on-prem Exchange 2016 still in a cupboard, some legacy IMAP), MigrationWiz handles all of them in one console.

Cloudfuze is the option we reach for when Drive and SharePoint volumes dominate. Stronger on file-system migration than on mail, but it does both, and the licensing is friendlier for short intense projects.

PST handling for legacy archives is the piece nobody plans for and everybody hits. Half the M365 tenants we inherit have a fileshare full of PSTs from 2008 to 2018 that nobody has opened in five years and nobody is willing to delete. Workspace has no PST concept. Honest options: ingest the PSTs into a holding mailbox in Workspace before user cutover (BitTitan handles this well), convert to MBOX and archive outside the tenant, or leave them on the fileshare under a documented retention policy. We default to the third for ZA clients with no specific legal-hold requirement.

A pre-migration extract is the rule. Get-MailboxStatistics from Exchange Online, exported to CSV, gives size and item count per mailbox. The 18 GB mailbox with 460,000 items will take six times longer than the 8 GB mailbox with 30,000 items. Plan the wave order around that, not around the org chart.

Drive / SharePoint / OneDrive migration

This is where the timeline blows out if you haven’t planned. Mail is bounded; the OneDrive of a senior partner who has been at the firm for fifteen years is not.

Migrate for SharePoint is Google’s first-party tool. It moves OneDrive content into the user’s Drive and SharePoint document libraries into Shared Drives. Permissions translate to the closest Workspace equivalent but the translation is not lossless. Microsoft’s permission model is richer at the edges (item-level inheritance breaks, granular role assignments, sharing-link scopes that include “people in your organisation except”). Workspace flattens those. Expect to manually reconcile the 5-10% of items where the translation produces something nonsensical.

Cloudfuze and BitTitan MigrationWiz both do SharePoint and OneDrive too. The choice tends to come down to what mail tool you’ve already licensed; running one vendor end-to-end is operationally simpler.

The “Shared Drive vs My Drive” decision is the one to make consciously before the bulk move starts. OneDrive content is, by default, owned by the user. Migrate it as-is into My Drive and you preserve that ownership and the familiar mental model. Downside: when the user leaves, ownership transfers become an administrative job and shared links break unless reassigned. Shared Drives solve that (the drive owns the content, not the user) but they need designing: per-team, per-project, per-client.

The pattern that survives contact with reality: move clearly-personal OneDrive content into My Drive, move anything shared with more than two other people or representing a project or client into a Shared Drive, document the rule, and accept a long tail of case-by-case calls in week two. For the cleaner side of this debate, see Drive vs SharePoint.

Calendar migration

Calendar is technically simpler than mail and harder than it looks. Migrate for Google Calendar pulls events from Exchange Online into Workspace calendars. Single events translate cleanly. Recurrences are where the trouble lives.

Outlook supports recurrence patterns Google does not, exactly. “The fourth Tuesday of every month, except in December when it moves to the third Tuesday because of the public holiday” is fine in Outlook. Google Calendar will round it to the nearest pattern it understands, December’s instance moves, and your CEO notices the staff meeting is wrong. We pre-extract recurring events with non-trivial rules, hand the list to a project owner, and either re-create the awkward ones natively post-cutover or accept the rounding.

Calendar resource accounts (meeting rooms, projectors, pool cars) are a separate piece. Exchange treats them as room-mailbox resources. Workspace has its own calendar resource concept and the migration tools don’t always carry them across cleanly. We script re-creation via GAM during the cutover weekend.

Delegated calendars (the EA who manages five executive calendars) are the third trap. The delegation lives in Exchange, not in the event. Migrating the events moves the items but not the delegate relationship. Re-establishing delegation is a manual step per delegator-delegate pair, and if the list isn’t ready before cutover, you find out on Monday morning when the EA can’t access the CEO’s calendar.

Teams content

This is the section where we are honest. Teams chat history is the hardest thing to migrate and the most likely thing to be lost.

Channel posts in Microsoft Teams live as Exchange-stored objects backed by a SharePoint library for files and a Stream for video. Migration tools can pull the files from the SharePoint backend into a Shared Drive and they can pull the recordings out, but the chat history itself is not really portable. Microsoft’s API access for chat content is restrictive, the message format is proprietary, and Workspace has no equivalent target structure to receive a threaded Teams channel.

Realistic options:

• Accept the loss. Export chat history to PDF or HTML for archival reference, file it on a Shared Drive, start fresh in Google Chat. For most SMEs, the chat nobody has scrolled in eight months is not worth the engineering hours.
• Use a paid tool that claims chat support (Cloudfuze and a couple of others). Migrates a subset of message types into Google Chat spaces. Fidelity is partial; threading and reactions don’t always survive; @-mentions become text.
• Run both side-by-side for a transition period. Keep Teams licensed for a few users for sixty days post-cutover so the chat is searchable while people resettle. Then archive and decommission.

We default to option one with an HTML export for retention. Promising “we’ll move all your Teams content” is a rod for your own back. Files attached to Teams messages migrate via the SharePoint tooling. Stream recordings migrate to Drive as MP4. Whiteboard content does not migrate; treat Whiteboard sessions as ephemeral.

Mail flow on cut-over day

The cutover itself is a DNS exercise. Done carefully it’s anticlimactic, which is the goal.

The Friday evening sequence:

1. Lower MX TTLs to 300 seconds, twenty-four hours earlier. Forget this and the Friday propagation tail stretches into Saturday afternoon.
2. Confirm dual-delivery is still active so mail in flight during the swap lands somewhere readable.
3. Update the MX record at the registrar to point to aspmx.l.google.com and the four secondary records.
4. Update SPF to remove include:spf.protection.outlook.com and add include:_spf.google.com. Do not leave both. Both passes SPF for two senders and DMARC alignment gets confused.
5. Republish DKIM for Workspace at the google._domainkey selector. The M365 DKIM CNAMEs (selector1, selector2) can stay published until the M365 tenant retires; they will not interfere.
6. Confirm DMARC is still at p=quarantine or wherever your existing posture sits. Do not raise it during a cutover.
7. Verify externally. Run the TamingDNS Google Workspace check to confirm SPF, DKIM, DMARC, MX and MTA-STS line up from the public internet. Run the TamingDNS DMARC analyser for cut-over alignment. Post-cutover XML reports start arriving within 24 hours; read them.
8. Send test mail in both directions: Workspace user out to Gmail, Yahoo, Microsoft. Confirm reply path lands back in Workspace.
9. Send authentication-test mail: a quiet mail-tester.com run, check-auth@verifier.port25.com, plus manual headers inspection. SPF=pass, DKIM=pass, DMARC=pass.

Authentication is the part that stings if rushed. The full play-by-play sits on the /dmarc/ page.

The MTA-STS record (if published for M365) needs updating to point at the Workspace MTA-STS policy. Easy to forget; leave the old policy live and sending domains that honour MTA-STS can reject mail to your new MX because the policy declares the wrong hosts.

What goes wrong, and how OSH plans around it

Thirty migrations in, the failure modes are predictable. Naming them up front is half the protection.

Delegated mailbox surprises. “Reception manages info@ and accounts@ and the parent’s PA also manages two other inboxes that don’t show in the org chart.” We hear this on Tuesday of cutover week, never during discovery. Workspace handles delegation differently from M365: per-user, additive, configured in Gmail not the admin console. We extract the full Exchange delegation map (Get-Mailbox | Get-MailboxPermission) during discovery and put delegation re-creation on the post-cutover task list with explicit owners.

Calendar resource accounts. The boardroom calendar that lives as a resource mailbox in Exchange. Five other meeting rooms. The pool car. The projector trolley. None appear in the user list, all have bookings weeks ahead. We script re-creation as Workspace calendar resources via GAM and bulk-import the existing bookings.

Outlook .ost cache shock. Users come in Monday morning, Outlook still works, mail still flows, and they assume the migration is done. Then they realise they’re reading their old M365 mailbox via the cached .ost file, not the new Workspace mailbox. Replies bounce or go to colleagues in M365. Mitigation is part-technical, part-communication: Outlook profile rebuilds during cutover weekend (or retire Outlook entirely and move users to Gmail web or the GW Sync plug-in), plus a Monday-morning standup that says explicitly: “if you are still in Outlook today, stop, open Gmail in your browser.”

The legacy on-premise mailbox no one mentioned. The MD has a personal mailbox on an on-prem Exchange 2013 server in the boardroom cupboard, separate from the M365 tenant, used only for board correspondence. Nobody flagged it because it doesn’t show in the M365 admin centre. We discover it when somebody notices outbound mail from chairman@yourdomain.co.za is still flowing through the old server’s smarthost. Mitigation: a discovery step that always runs an external SPF and MX history check (TamingDNS Workspace check plus the SPF analyser) and asks “is anything in this record we haven’t accounted for?”

Modern Attachments. Outlook’s “share a OneDrive link instead of attaching a file” feature. After cutover, the old links 404 once OneDrive content moves or the licence drops. Pre-cutover, extract recently-sent items with attachments, pull the link list, re-share the underlying files into Drive with the same recipients, or accept the breakage and document it.

Service account passwords baked into apps. The accounting package that sends invoices through SMTP using basic-auth mapped to a service mailbox. The CRM that polls IMAP for inbound leads. The legacy line-of-business app that sends scheduled reports through Exchange’s relay connector. Extract SMTP and IMAP auth logs from M365 during discovery, find every authenticating service account, reconfigure them against Workspace’s SMTP relay or replace them with a modern integration during the same window.

The Power BI connection nobody documented. Power BI doesn’t migrate to Workspace; there’s no equivalent. Discovery should ask: “is there any reporting tool that pulls from M365 and feeds a dashboard?” Half the time the answer is yes and the owner is a director who will notice on day three.

Where OSH fits

OSH delivers M365-to-Workspace migrations as a managed engagement. Discovery is fixed-fee, the project schedule isn’t compressed artificially, the cutover weekend is staffed with two engineers. Post-cutover support runs sixty days at no extra cost while the unexpected things surface.

We’ve migrated more than thirty tenants this direction. We’ve reversed the migration twice when the destination was wrong. Honest scoping saves the money. See /google-workspace/ for the destination context, the Google Workspace SKU buyer’s guide if licensing is the open question, the Google Workspace onboarding checklist for the post-cutover tenant baseline, and /services/ for the wider managed-services catalogue.

First step is a sixty-minute fit assessment. We look at your M365 estate, the shape of the migration, the integrations to plan around, and tell you honestly whether the move makes sense.

Book a managed-migration scoping call or email support@osh.co.za.