For most small and medium organisations, the reliable path is Microsoft’s native Exchange migration for mail plus Migration Manager for Drive content. Reserve third-party tooling for complex migrations, large Shared Drive estates, or when you need concurrent migrations with permission fidelity. Whichever route you choose, run a pilot batch with a small group of test users before touching production, and keep Google Workspace fully active as a parallel safety net until you’ve verified everything.
TL;DR:
- Native Microsoft tools are typically sufficient for migrating under 150 mailboxes with simple sharing structures, but third-party tools become cost-effective above that threshold.
- Proper planning, including DNS pre-staging, verifying permissions, and testing with a small pilot batch, is essential to avoid migration failures and reduce downtime.
- Migration timelines vary from one to three days for small, straightforward tenants to four weeks or longer for larger, regulated environments with complex sharing setups.
- Data compliance requires careful handling of sensitive information, secure storage of credentials, and post-migration security reviews, especially for regulated industries.
- Coexistence during migration necessitates controlling where data lives, with users referencing both systems before full cutover, while budgeting for licensing costs for both platforms during the safety window.
Table of Contents
- What actually migrates from Google Workspace to Office 365
- Native Microsoft tools or third-party migration software?
- Prerequisites and planning checklist before you migrate
- How do you run the migration step by step?
- Common migration problems and how to fix them
- TechBug’s take on realistic migration timelines
- Keeping data compliant and secure during the move
- What happens to your third-party integrations?
- Running Google Workspace and Microsoft 365 side by side
- What licensing and costs should you plan for?
- Decommissioning Google Workspace after migration
- Why staged migration beats a big-bang cutover
- How TechBug can help with your migration
- Sources
What actually migrates from Google Workspace to Office 365
Mail, calendar entries, and contacts move across cleanly using Microsoft’s Exchange migration tooling, whether you run it through the Exchange admin centre or script it with PowerShell. Drive content follows a separate path: My Drive maps to OneDrive, and Shared Drives map to SharePoint sites through Migration Manager. Google Docs, Sheets, and Slides convert automatically into Word, Excel, and PowerPoint formats, and version history along with original authorship typically survives the move.
Some things don’t come across intact:
- “Shared with me” links and shortcuts, which need rebuilding manually on the destination side
- External sharing links, since the underlying tokens don’t migrate and every external share needs re-issuing after cutover
- Google Groups, which require manual recreation as Microsoft 365 distribution lists or groups
- Google Chat history, which has no direct equivalent and generally gets archived rather than migrated
- Complex Shared Drive permission structures, which rarely map one-to-one and usually need a manual reconciliation pass
Budget time for that clean-up work now, not during cutover week.
Native Microsoft tools or third-party migration software?
Microsoft gives you two free, fully supported workflows that run side by side rather than as one unified tool. For mail, the automated Google Workspace migration in Exchange Admin Centre handles most of the prerequisite setup itself, provided you supply a JSON service account key and a working migration endpoint. Drive content runs through Migration Manager, which handles both the “Lite” native Drive-to-OneDrive path and the fuller Shared Drives-to-SharePoint mapping.
Third-party tooling earns its cost when you need capabilities native tooling doesn’t offer: concurrent migrations across many mailboxes at once, incremental delta syncing, and unified reporting across mail and Drive in a single dashboard.
Use these rough thresholds when deciding:
- Under 150 mailboxes with simple sharing structures — native tooling is usually sufficient and free.
- 150 to 500 mailboxes, or any tenant with deep Shared Drive nesting — third-party tooling starts paying for itself in saved admin hours.
- 500+ mailboxes, a hard cutover deadline, or regulatory data handling requirements — third-party tooling’s concurrency and permission fidelity become the deciding factor.
Pro Tip: Run your pilot batch through whichever method you’re leaning towards before committing. A ten-user test tells you more about real-world throttling and permission quirks than any vendor brochure.
Prerequisites and planning checklist before you migrate
Skipping prerequisites is the single biggest cause of failed cutover weekends. Work through this list at least two weeks before your target date.
- Verify domain ownership in the Microsoft 365 admin centre and pre-stage every DNS record you’ll need, lowering TTL values several days ahead of cutover so changes propagate fast when it counts.
- Create a Google Cloud service account, generate its JSON credentials, and grant it the API scopes and project creator role the migration endpoint requires.
- Provision destination users in Microsoft 365, assign the right licences, set up a migration subdomain, and prepare a CSV mapping source mailboxes to destination accounts.
- Audit mailbox sizes and flag anything oversized. Microsoft’s default single-message transport limit sits around 35MB, and messages above that threshold need splitting or a transport configuration change before they’ll migrate.
- Plan batch sizes and concurrency limits with throttling in mind. Both platforms rate-limit migration traffic, so scheduling overnight batches is standard practice.
- Keep Google Workspace licences active for 30 to 90 days after cutover as a rollback window.
A tenant migration checklist built around these steps saves far more time than it costs to write.
How do you run the migration step by step?
Treat this as four distinct phases, each with its own validation point before you move to the next.
Phase one: pilot. Pick five to ten test users spanning different roles and mailbox sizes. Run a combined mail and Drive pass, then have those users log in from their normal clients and confirm mail arrives, calendars sync, and Drive files open with the right permissions intact.
Phase two: staging. Once the pilot checks out, run batched mailbox migrations for the wider user base, scheduling incremental delta passes so mail sent during the migration window still lands. In parallel, map each Shared Drive to its corresponding SharePoint site rather than trying to migrate everything in one pass.
Phase three: cutover. This is where DNS work happens. Lower TTL values if you haven’t already, then update MX records and any dependent SPF or DKIM entries. Run one final delta sync immediately before flipping mail flow, and confirm the sync completes before you consider the cutover final.
Phase four: verification. Check calendar entries and contacts landed correctly for a representative sample of users. Spot-check Shared Drive permissions against your pre-migration notes. Re-issue external sharing links, since tokens don’t carry over automatically. Only retire the old MX records once you’ve cleared your safety window, typically 30 days minimum.
Guides for fast Exchange Online migration under 150 mailboxes cover this same four-phase structure in more technical depth if you’re running it in-house.
Common migration problems and how to fix them
Most failures fall into a handful of predictable categories.
- API connection errors: usually a stale or mis-scoped JSON key. Re-verify the service account’s API scopes and check your Google Admin console hasn’t revoked access mid-migration.
- Missing messages or migration timeouts: often oversized messages hitting the 35MB transport limit. Split the offending mailboxes into smaller batches and re-run rather than restarting the whole migration.
- Permission mismatches on Shared Drives: re-map group membership against your pre-migration audit, then run manual spot checks on a sample of files rather than assuming the mapping held.
- DNS and mail delivery issues: validate SPF, DKIM, and DMARC records against Microsoft’s published values, and check MX propagation with a public DNS checker before panicking. Keep the old MX record ready to restore if delivery breaks critically.
Pro Tip: Before you sign off a migration as complete, run a verification pass covering user spot checks, item counts against your pre-migration baseline, sample message opens, and a test send to any migrated distribution groups. Five minutes of checking beats a week of support tickets.
TechBug’s take on realistic migration timelines
Some managed cloud service providers offer end-to-end Google Workspace to Microsoft 365 migrations, covering discovery, the migration itself, and post-cutover support to ensure configurations are completed.
Timelines vary more than most guides admit. Small teams with straightforward mailboxes typically finish core email in one to three days, with Drive content following within another day or two. Medium tenants with more complex sharing structures usually need one to two weeks. Larger or regulated environments, where permission fidelity and compliance sign-off matter, can run four weeks or longer.
The real difference between doing this in-house and hiring a managed provider isn’t the migration mechanics. It’s who owns troubleshooting when something doesn’t sync correctly at 11pm on cutover weekend.
Keeping data compliant and secure during the move
Migration is a window where data sits partially in two systems, and that’s exactly when compliance gaps open up. Before you start, document where sensitive data lives, particularly in Shared Drives with external collaborators, and confirm who retains access during the parallel-run period.
Service account credentials deserve the same handling as any privileged access: store the JSON key securely, restrict who can view it, and revoke it once migration completes rather than letting it linger in a shared drive somewhere. The same discipline applies to any migration endpoint you configure, since it’s effectively a bridge with read access to your entire mail estate.
Check your industry’s data residency and retention obligations against both platforms before finalising SKU choices, particularly if you handle health, financial, or government data. Some organisations need to confirm where Microsoft 365 stores tenant data geographically before signing off on a migration date.
Once migrated, review your security baseline immediately rather than assuming Workspace protections carry over. Multi-factor authentication, conditional access policies, and anti-phishing settings need configuring fresh in Microsoft 365. Reviewing how Microsoft 365 surfaces threat information is a sensible first step for admins setting up their new security posture post-cutover.
Audit logging is worth switching on before migration starts, not after. If something goes wrong with permissions or data access during the parallel-run window, you’ll want a record of who accessed what and when.
What happens to your third-party integrations?
Every app connected to Google Workspace through OAuth, whether it’s an accounting package, a CRM, or a marketing automation tool, breaks or behaves unpredictably once you decommission Workspace. Inventory these integrations before migration starts, not after users start reporting broken workflows.
For each integration, check three things: does it authenticate through Google specifically (meaning it needs reconfiguring for Microsoft 365 or Azure AD), does it write data back into Drive or Gmail (meaning it needs a new destination path), and does it have a Microsoft 365 equivalent connector already built.
Some integrations migrate painlessly, particularly SaaS tools that support both Google and Microsoft authentication out of the box. Others, especially custom-built internal tools or older API integrations, may need genuine redevelopment work. A step-by-step preparation checklist for SMB tooling changes is a useful pattern to adapt here, even outside its original marketing automation context, because the sequencing logic (inventory, test, cut over, verify) applies directly to integration migration too.
Run integration testing during your pilot phase, not after full cutover. If a critical tool breaks, you want to know with ten test users affected, not five hundred.
Running Google Workspace and Microsoft 365 side by side
Coexistence isn’t optional. It’s the safety mechanism that makes staged migration possible. The parallel-run period, typically your 30 to 90 day rollback window, exists precisely so both systems can serve live mail and files simultaneously without users noticing a hard switch.
The trick to coexistence working smoothly is controlling where “live” data lives at any given moment. Once you’ve migrated a user’s mailbox, that user’s inbound mail should route to Microsoft 365 exclusively rather than splitting between both systems, which is why the MX cutover happens in one atomic step rather than gradually per user.
Drive content can genuinely coexist for longer. Users can keep referencing Google Drive files for shared or archival content while actively working in OneDrive and SharePoint for new files, provided you’re clear internally about which system is the source of truth for new work from a given date forward.
Communicate the coexistence timeline to staff explicitly. The most common support ticket during migration isn’t a technical failure. It’s a user who doesn’t know which system to save a file in during the transition window.
What licensing and costs should you plan for?
Running both platforms in parallel means paying for both simultaneously during your safety window, which administrators frequently forget to budget for. If you’re moving 200 users, plan for 200 Google Workspace licences and 200 Microsoft 365 licences overlapping for the duration of your rollback period.
Microsoft 365 licensing tiers matter more than most Google Workspace admins expect, since Microsoft segments features across plans more granularly than Workspace does. Comparing Microsoft 365 plans against your current Workspace SKU helps you map users to the right destination tier rather than over-licensing everyone onto the most expensive plan by default.
Security features are a common licensing trap. Advanced threat protection, conditional access, and some compliance tools sit behind Business Premium or higher, not the entry-level plans. If your Workspace tier included security add-ons, check the Microsoft 365 equivalent isn’t gated behind a pricier tier before you commit to a plan.
Factor in migration tooling costs separately from ongoing licensing if you’re using third-party tooling, since these are frequently priced per-migrated-user or per-project rather than as a recurring subscription, and it’s easy to conflate the two when building a budget.
Decommissioning Google Workspace after migration
Don’t rush decommissioning. The temptation to cancel Workspace licences the day after cutover is understandable, but it removes your rollback option along with any lingering dependencies you haven’t spotted yet.
Wait out your full safety window, generally 30 to 90 days, before cancelling anything. During that period, monitor for any workflow, integration, or user habit still quietly depending on Google services. Export any remaining data you’re not confident migrated cleanly, particularly Chat history and Groups membership lists, since these have no automated migration path and become unrecoverable once you cancel.
Once you’re confident nothing depends on Workspace, cancel licences, remove the old MX records entirely rather than leaving them as a fallback, and revoke the service account credentials and JSON key you created for migration. Document the decommissioning date and what you verified beforehand, since that record matters if a compliance question comes up later.
Why staged migration beats a big-bang cutover
The conventional advice treats migration as a weekend event: plan hard, flip the switch, hope for the best. That thinking gets people into trouble. The organisations that struggle with Google Workspace to Office 365 moves are almost always the ones that skipped the pilot batch or tried to migrate everything in one pass instead of staging it.
What’s underrated is how much a small pilot batch actually tells you. Ten test users surface throttling limits, permission mapping quirks, and integration failures that a spreadsheet plan never will. What’s overrated is the assumption that native tooling and third-party tooling are competing philosophies. They’re not. Most competent migrations use native Exchange tooling for mail and lean on third-party capability only where Shared Drive complexity or deadline pressure genuinely demands it.
If there’s one thing to prioritise above all else, it’s the rollback window. Keeping Workspace active for 30 to 90 days after cutover costs you double licensing for a short stretch. It also means a bad permission mapping or missed integration doesn’t become a business-stopping crisis.
— Ru
How TechBug can help with your migration
Chasing down JSON keys, DNS propagation, and Shared Drive permission mismatches while running a business isn’t most administrators’ idea of a good week. Managed service providers can handle Google Workspace to Microsoft 365 migrations end to end, including pilot batches, staged cutover, and post-migration support where most troubleshooting occurs.
To scope a migration quote, providers typically need your approximate user count, an estimate of Drive and mailbox data volume, and information on any high-risk mailboxes, such as executives or shared inboxes. This allows them to put together a realistic timeline and fixed-scope quote rather than an open-ended hourly estimate.
If you’d rather have someone else own the 11pm DNS panic, get in touch through TechBug’s managed IT services page and request a migration quote.
Sources
- Perform a Google Workspace (formerly G Suite) migration to Microsoft 365 or Office 365 | Microsoft Learn
- What to consider for your Google Workspace to Microsoft 365 migration | ShareGate