Google Workspace to Microsoft 365 — the Australian MSP migration playbook (2026)

Switching from Google Workspace to Microsoft 365 has become a more frequent question in Australian mid-market in 2025-26. The drivers are predictable: Copilot for Microsoft 365 outpacing Duet AI / Gemini for Workspace on enterprise integration, Microsoft's identity and security stack (Entra ID, Defender XDR, Sentinel, Purview) being substantially deeper than Google's equivalents, and Microsoft 365 licensing comparing favourably once you factor in the bundled security and compliance value. The cost arguments aren't always one-sided — Workspace remains cheaper per-user list — but the all-in TCO across security, identity and AI usually tips Microsoft for the AU mid-market.

The migration is a 10–14 week project for a typical 200–500 user tenant. Below is the phase-by-phase playbook Frontrow runs.

Phase 1 — Pre-migration (weeks 1–2)

Inventory the Google Workspace estate. Users (active vs suspended), groups, shared mailboxes, organisational units, Workspace Business / Enterprise edition, custom OAuth apps, Calendar resources, Sites, Drive total volume, Shared Drive count, Chat history retention, third-party apps using SSO via Google. The inventory determines tooling and timeline more than anything else.

Decision points: scope of mail history migration (last 12 months / 2 years / all), Drive content migration (Shared Drives are simpler than personal Drive; both can move), Calendar migration (typically last 30 days plus future events), Chat history (almost never migrated — operationally not worth it, and Google Chat history is often patchy).

Order Microsoft 365 licences for the destination tenant. Decide on E3 vs Business Premium vs E5 based on the security and Copilot positioning (most AU mid-market lands on Business Premium with selective E5 add-ons). Stand up the Microsoft 365 tenant; configure domain (initially as a verified-not-primary domain alongside Google), branding, default policies.

Phase 2 — Identity (weeks 3–4)

Identity is the hardest part of the migration. Three approaches: (1) Cloud-only Entra — create new Entra accounts and assign Microsoft 365 licences; pair with directory provisioning from a HRIS where one exists. (2) Hybrid with existing on-prem AD — sync existing AD users to Entra via Entra Connect. (3) Federation from Google as IdP during transition — Google Workspace can SAML-federate to Microsoft for a short window, useful for staged cutover.

Most AU mid-market Frontrow runs lands on cloud-only Entra with HRIS provisioning. Federation from Google adds complexity for limited benefit. Conditional Access policies, MFA enrolment and Intune device compliance need to be configured against the new Entra estate before mail cutover — staff arriving in Microsoft 365 should land on a fully-policed tenant, not an empty one.

Phase 3 — Mail migration (weeks 5–7)

BitTitan MigrationWiz is the most-used tool for Google Workspace mail to Exchange Online in AU mid-market. Quest On Demand Migration is the alternative for larger or more complex tenants. Both work the same way at a high level: connect to Google Workspace via service account credentials, connect to Microsoft 365 via Graph and EWS, queue per-user migrations, run delta syncs in the days leading to cutover.

Mail migration speed is roughly 1–3 GB per mailbox per hour. For a 200-user tenant with 15 GB average mailbox, plan for a 3,000 GB total at ~2 GB/hour ingestion across parallel streams — typically 5–10 days. The cutover day is when you flip MX records and primary domain from Google to Microsoft; mail flow lands in Microsoft 365 from that point.

Phase 4 — Drive content (weeks 6–9)

Google Drive to OneDrive (personal Drive) and Shared Drive to SharePoint (Shared Drives). Mover.io (Microsoft-owned, free for one-time migrations) covers most use cases for tenants under 100 GB per user. BitTitan and ShareGate handle larger and more complex estates. Permissions translation is the trap — Google's sharing model (per-file sharing, drive-wide sharing, link sharing) doesn't perfectly map to SharePoint's site-based permissions; expect a 2–5 percent permission-correction rate post-migration.

Migrate Shared Drives to dedicated SharePoint sites with the matching permissions group. Migrate personal Drive to each user's OneDrive. Verify owner-mapping during the run — Frontrow's pattern is to suspend migration if more than 5 percent of files have unmapped owners, fix the mapping, and resume.

Phase 5 — Cutover (weeks 9–10)

Cutover day. MX records flip to Microsoft 365. Google's mail flow now bounces; Microsoft's begins. Auto-discover changes to Microsoft. Outlook is deployed via Intune (or the user is walked through manual configuration). OneDrive sync client is installed. The Google account is converted to a 'Google email-only' account (so Workspace SAML federation can be retired) for a grace period of 30 days during which old Google links still resolve.

Communications matter more than tooling in cutover week. Staff need to know what's changing, when, where the new sign-in is, how to access old Google content during the grace period. Frontrow's pattern is a daily ops standup for the first week of cutover and a daily comms cadence to the whole company for 10 days.

Phase 6 — Post-cutover (weeks 10–14)

Permission cleanup against the SharePoint estate (the post-migration delta correction). Third-party app re-wiring — every SaaS app that used Google as IdP needs to be re-pointed at Entra. License cleanup — Google Workspace can typically be decommissioned at the end of week 12 once you're confident no business-critical content remains. Final Google data export and archive (PST or third-party archive solution) for the regulatory retention obligation.

The Australian-specific gotchas

1. 1Data residency — Microsoft 365 Australian datacentres (Australia East, Australia Southeast) house Exchange, SharePoint, OneDrive and most other workloads. Some niche workloads still sit in US datacentres; verify each one against your data classification and regulatory requirements (especially APRA, government, healthcare).
2. 2Calendar timezone correctness — Australian timezones plus daylight saving create predictable confusion during migration. Run a calendar-timezone test on a sample of users before broader cutover; adjust the migration tool's timezone handling if needed.
3. 3Government Workspaces (Workspace for Education, Workspace for Government) sometimes have features without direct Microsoft equivalents (Classroom, Vault retention specifics); each needs a Microsoft equivalent identified and licensed.
4. 4Google Voice — where used as the business phone system, plan the Teams Phone replacement separately. Migration tooling does not cover voice/call routing; this is a separate workstream with its own SOW.
5. 5Backup obligations — Microsoft 365 doesn't include long-retention backup; if Google Vault was the backup mechanism, a Microsoft 365 backup tool (AFI, Veeam, Druva, Spanning) needs to be in place from cutover day. Don't migrate without this in place — Frontrow has seen tenants discover the gap during a ransomware incident in week 8 post-cutover.

What the AUD cost typically looks like

For a 250-user AU mid-market Google Workspace → Microsoft 365 migration: vendor tooling AUD 8,000–15,000 (BitTitan + ShareGate combination), Frontrow services AUD 90,000–140,000 (project management, identity, mail, drive, training, cutover, post-cutover), 10–14 week duration, plus 6–8 weeks of dual licensing during the migration window. Use the Tenant-to-Tenant Migration Estimator (linked below) for an indicative range against your specific scope.