You've just closed another acquisition. The acquired company runs on Google Workspace. Your platform is Microsoft 365. The question isn't if you'll migrate-it's when, and how messy it'll be.
This pattern plays out repeatedly across roll-ups: integration teams delay the platform migration, hoping the acquired staff will naturally adopt Microsoft tools. They don't. Months later, you're paying for two platform licences, running duplicate security policies, and watching acquired teams quietly revert to old workflows because nobody explained why they're switching or how to use Outlook without losing their minds.
Here's the math: a 50-person acquisition running Google Workspace costs you roughly £250–400/month in duplicate licences whilst you "figure it out." Over six months, that's £1,500–2,400 in waste-before you count the hidden costs of fragmented file storage, broken calendar invites between platforms, and the IT tickets from users who can't find their old Google Docs.
This isn't a technical problem. It's an execution problem. The brutal reality is that most Google Workspace to Microsoft 365 migrations fail not because the tools don't work, but because operational leaders underestimate the human and data complexity-and overestimate how seamlessly the platforms talk to each other.
This article covers what actually works when standardising an acquired company onto your Microsoft 365 tenant: mailbox migration paths (and when each makes sense), the file migration tactics that avoid the Conversion Trap, calendar and identity consolidation, alternatives for Google Forms and Sites, and-critically-how to drive adoption using a Digital Champions model so your acquired team doesn't quietly sabotage the transition.
Why Serial Acquirers End Up Migrating From G Suite to Microsoft 365
Acquired companies typically run Google Workspace for three reasons. One, they started as a small team and Google was cheap and easy. Two, they valued real-time collaborative editing and browser-based work. Three, they never had internal IT and Google "just worked."
Your platform runs Microsoft 365 because you need enterprise-grade security controls, Active Directory integration, Teams for internal comms, and -- most importantly -- licensing economies of scale across a multi-site roll-up. When you're operating ten facilities across three regions, you need centralised identity management, consistent data governance, and a single pane of glass for IT administration.
The decision to migrate isn't philosophical. It's operational. Running dual platforms means:
- Duplicate licence costs that scale with every user.
- Fragmented file storage where contracts live in Google Drive, SOPs sit in SharePoint, and nobody knows which is current.
- Broken collaboration when your HQ sends a Teams meeting invite and the acquired sales team responds "I don't have Teams installed."
- Security and compliance gaps because your group IT policies only apply to Microsoft 365 tenants, leaving the Google Workspace environment outside governance.
For PE-backed roll-ups, the sponsor expectation is clear: one platform, one identity system, one security posture. Google Workspace to Office 365 migration becomes a non-negotiable step in the integration roadmap-usually scheduled for months 2–4 post-close, after the finance and HR spine is unified but before you tackle operational systems.
What complicates this is that the acquired team likes Google Workspace. They're comfortable. Docs load fast, sharing is intuitive, and they've never had to think about OneDrive sync conflicts. Your job isn't to dismiss their preference-it's to execute a migration that respects their workflows whilst delivering the platform standardisation your group needs.
The Brutal Reality: Where Google Workspace to Office 365 Migrations Go Wrong
Platform migrations routinely experience data loss, broken workflows, or user adoption failures -- particularly when operational leaders skip the pre-migration audit. Not because the technology is immature-because operational leaders skip the pre-migration audit and assume "it's just email and files."
Here's where it goes sideways:
1. Mailbox Mapping Errors
You provision Microsoft 365 accounts but forget to match the Google Workspace username format. Migration tools fail to map users correctly, and suddenly half your sales team's email history is sitting in a limbo PST file nobody can find.
2. Shared Drive Chaos
Google shared drives don't map 1:1 to SharePoint. Permissions are different. Folder structures don't translate. Teams commonly migrate a shared drive to a SharePoint document library, only to discover that nested permissions (which Google handled elegantly) now require manual reconfiguration across 300+ folders.
3. Calendar Invites That Break
Google Calendar events migrate to Outlook, but recurring meeting exceptions, external attendee links, and colour-coded categories don't survive. Your COO's weekly leadership meeting disappears from half the participants' calendars, and nobody notices until someone misses the board prep session.
4. The Metadata Black Hole
File creation dates, version history, and "last modified by" data often don't migrate cleanly. In regulated industries (healthcare, finance), losing audit trails on documents can trigger compliance issues. In operations, it just means you can't tell which version of the safety protocol is current.
5. Underestimating User Confusion
Outlook works differently than Gmail. OneDrive sync is not Google Drive. Teams is not Google Chat. You migrate the data but don't train the users, and three weeks later the acquired team is still emailing files as attachments because they can't figure out how to share a OneDrive link.
The Hidden Cost of Gmail to Outlook Migration Delays
Every week you delay Gmail to Outlook migration, you're accruing integration debt:
- Licensing waste: £6–12 per user per month for duplicate Google Workspace licences.
- Administrative overhead: IT managing two identity systems, two security policies, two sets of admin consoles.
- Workflow fragmentation: Acquired staff defaulting to old tools, ignoring new processes, quietly operating outside group visibility.
- Data risk: Email and files sitting in an environment your IT doesn't monitor, backup, or control.
One facilities management roll-up delayed migration for nine months. The acquired company's Google Workspace admin left. Nobody knew the admin password. When they finally attempted migration, they discovered 18 months of email history locked in an orphaned account. Recovery cost them £8,000 in specialist data recovery fees and three weeks of effort.
Delaying isn't neutral. It's collecting problems.
Decision Framework: When to Migrate, When to Defer, When to Run Dual Platforms
Not every acquisition needs immediate migration. Deciding when matters as much as how.
Migrate immediately (months 1–2) if:
- The acquisition is High-Touch integration (full operational consolidation).
- Fewer than 50 users-small enough to execute fast without complex phasing.
- Significant security or compliance gaps in the Google Workspace environment (no MFA, external sharing enabled, no data loss prevention).
- The acquired company's IT contact is leaving or has already left-losing admin access creates future risk.
Defer to months 3–4 if:
- You're prioritising finance/CRM/ERP unification first and can't resource parallel projects.
- The acquired team is still reeling from ownership change-adding platform migration too soon risks change fatigue.
- Complex shared drive structures require detailed mapping and permission planning.
Run dual platforms temporarily (2–6 months) if:
- The acquisition is Medium-Touch or Low-Touch, and operational independence justifies the licensing cost.
- You're testing long-term integration intent-acquired company may remain semi-autonomous.
- The acquired company has deep Google Workspace integration (API connections, custom Apps Script automation, third-party tools) that need time to replicate in Microsoft 365.
Warning: Dual platforms beyond six months almost always drift into permanent paralysis. Roll-ups often end up still running dual platforms 18 months post-close because "we'll get to it next quarter." It never happens. Make the call early, resource it properly, and execute.
The Four-Phase Migration Model That Actually Works
This is a proven playbook used across serial acquirers. It's not fast-it's thorough. The goal isn't speed: it's avoiding the catastrophic failures that force rollback and destroy user trust.
Phase 1: Pre-Migration Audit and Licence Mapping
Timeline: 1–2 weeks
Owner: IT Director or integration lead, supported by technical execution partner
Before you touch anything, map what you're moving:
User Inventory
Export the full user list from Google Workspace admin console. Identify:
- Active users (logged in within 30 days)
- Dormant accounts (former employees still consuming licences)
- Shared mailboxes and group aliases
- Admin accounts and service accounts
Data Volume Assessment
For each user, capture:
- Mailbox size (Gmail + labels)
- Google Drive storage (My Drive + shared drives)
- Calendar complexity (number of recurring events, external attendees)
- Google Groups membership
Dependency Mapping
Identify:
- Third-party integrations (Zapier, calendar tools, CRM sync)
- Custom Google Apps Scripts
- Google Forms actively collecting data (customer feedback, job applications)
- Google Sites used for internal wikis or client portals
Microsoft 365 Licence Provisioning
Create Microsoft 365 accounts before migration starts. Match usernames exactly-if the Google Workspace account is sarah.jones@acquiredco.com, the Microsoft 365 account must be sarah.jones@yourgroup.com (or whatever your group domain is). Mismatched usernames break automated migration mapping.
Provision the right licence tier:
- Microsoft 365 Business Basic (£4.60/user/month): email, OneDrive, web-only Office apps-sufficient for most operational users.
- Business Standard (£9.60/user/month): adds desktop Office apps-needed for users doing heavy Excel/Word work.
- Business Premium (£16.70/user/month): adds advanced security (Conditional Access, Intune)-recommended for roll-ups with compliance requirements.
Real Talk: Integration teams often over-licence out of caution, provisioning Premium for everyone when half the users only need Basic. That's £144/user/year in waste. Right-size licences based on actual role needs.
Phase 2: Data Migration Execution (Mail, Drive, Calendar)
Timeline: 2–6 weeks depending on data volume and user count
Owner: Technical execution partner or specialist IT contractor
This is where execution starts. You have three migration paths:
Mailbox Migration: IMAP vs Native Google Migration Tool
Option 1: Native Microsoft 365 Migration Tool (Recommended)
Microsoft's Exchange admin centre includes a Google Workspace migration endpoint. It uses OAuth to authenticate directly to Google, preserving folder structure, labels (converted to Outlook folders), and calendar events.
Pros:
- Officially supported by Microsoft.
- Preserves most metadata (timestamps, sender/recipient data).
- Handles calendar and contacts in the same workflow.
Cons:
- Requires admin consent in both Google Workspace and Microsoft 365.
- Doesn't migrate Google Drive files-separate process required.
- Limited support for shared mailboxes and Google Groups.
Option 2: IMAP Migration
Uses IMAP protocol to pull mail from Gmail into Exchange Online. Older method, broader compatibility.
Pros:
- Works with any IMAP-accessible mailbox (useful if you're migrating from legacy on-prem systems alongside Google Workspace).
- Simple setup.
Cons:
- Loses labels. Gmail labels don't map to Outlook folders-everything lands in the inbox as a flat list.
- Slower transfer speeds.
- Doesn't migrate calendar or contacts-manual export/import required.
IMAP is typically worth considering only when the native tool fails (usually due to API access restrictions or very old Google Workspace legacy free edition accounts).
Shared Drive to SharePoint/OneDrive Migration
This is where the Conversion Trap lives.
The Conversion Trap Explained:
Google Docs, Sheets, and Slides are web-native formats. They don't exist as files-they're database objects rendered in a browser. When you migrate them to Microsoft 365, migration tools offer two options:
- Convert to Microsoft formats (
.docx, .xlsx, .pptx). Fast, but formatting breaks-complex tables in Google Sheets become mangled Excel files, collaborative Google Docs with comments lose comment threads, and embedded links inside documents often break. - Leave as Google formats and link. Preserves fidelity but forces users to keep a Google account active just to open files-which defeats the point of migration.
Neither option is perfect. Here's a practical approach:
For operational documents (SOPs, templates, forms): Convert to Office formats during migration, then manually QA the top 20% most-used files. Fix formatting breaks before go-live. Yes, it's tedious. Yes, it's necessary.
For archived reference material: Leave as Google formats, export as PDF, and store in SharePoint as read-only archives. Users don't need to edit old board decks-they need to reference them.
For active collaborative documents: Rewrite them natively in Microsoft 365 before migration. If your operations team has a living Google Sheet tracking site inspections, rebuild it as an Excel file or a SharePoint list before you migrate. Don't let migration tools make critical workflow decisions for you.
Migration Tool Options:
- Microsoft SharePoint Migration Tool (SPMT): Free, Microsoft-supported, handles Google Drive to OneDrive/SharePoint. Solid for straightforward migrations.
- Third-party tools (Cloudiway, SkyKick, BitTitan): Paid (£3–8/user), faster, better metadata preservation, handle complex permission mapping. Worth the cost for migrations over 100 users.
Permission Mapping:
Google shared drives use inheritance differently than SharePoint. A user with "Commenter" access in Google doesn't map cleanly to "Contribute" or "Read" in SharePoint. Plan to manually review and reconfigure permissions post-migration for shared drives with complex access controls.
Calendar Migration
Calendars migrate alongside mailboxes when using the native Microsoft 365 tool. Common issues:
- Recurring meeting exceptions (e.g., "this week's 1:1 is moved to Thursday") sometimes don't migrate-the exception disappears and the original time reappears.
- External attendee links (Zoom, Google Meet URLs in event descriptions) migrate fine, but Google Calendar event responses from external attendees don't always sync. Your external partner might have RSVP'd "Yes" in Google Calendar but show as "No response" in Outlook.
- Colour categories don't migrate. If your COO colour-coded personal vs work events in Google Calendar, that's gone.
Workaround: For critical recurring meetings (board sessions, executive leadership calls), manually verify post-migration that all instances and attendees migrated correctly.
Phase 3: Cutover, Testing, and Hypercare
Timeline: 1 week cutover + 2 weeks hypercare
Owner: IT lead + integration manager
Cutover is the moment you flip the switch: MX records point to Microsoft 365, users log into Outlook instead of Gmail, files live in SharePoint instead of Google Drive.
Pre-Cutover Checklist:
- [ ] All user mailboxes migrated and verified (send test emails, check folder structure).
- [ ] All shared drives mapped to SharePoint and permissions tested.
- [ ] Microsoft 365 desktop apps installed on user devices (Outlook, OneDrive sync client, Teams).
- [ ] User training completed (covered next section).
- [ ] MX records updated to point to Microsoft 365 (email now routes to Exchange Online).
- [ ] Google Workspace accounts converted to read-only for 2 weeks (users can access old data but can't send new email or create new files).
Post-Cutover Validation:
- Send/receive external email from every migrated mailbox.
- Open 10–15 migrated files per shared drive to confirm no corruption.
- Test OneDrive sync on user devices-common failure point.
- Verify calendar sharing between users works (internal meeting invites send and accept correctly).
Hypercare (Weeks 1–2 Post-Cutover):
This is where adoption lives or dies. Hypercare means:
- Daily check-ins with department heads-"What's broken? What's confusing?"
- Dedicated Slack/Teams channel for user questions.
- On-call support (internal IT or external partner) to handle "I can't find my old files" and "Outlook won't sync" tickets.
- Weekly triage meeting to track recurring issues and deploy fixes.
Real Talk: Budget 20–30 hours of support time in the first two weeks. If you resource it properly, user frustration stays manageable. If you under-resource it, resentment builds and users quietly revert to workarounds (like emailing files instead of using SharePoint links).
What Winners Do Differently: The People Side of Platform Migration
Here's what most integration teams miss: successful Google Workspace to Microsoft 365 migration isn't a technical win. It's a behaviour change win.
You can migrate systems faster than people change behaviour. The acquired team has muscle memory-Gmail shortcuts, Drive search habits, Google Docs collaboration rhythms. Outlook and OneDrive feel foreign, clunky, slower. If you don't address that, they'll comply on the surface (use the new tools when forced) but resist underneath (continue old habits wherever possible).
The Digital Champions Model
This is an adoption framework that works across platform migrations:
1. Identify Champions (Week 1 of Planning)
Recruit 1–2 people per department from the acquired company. Not your HQ staff-people the acquired team already trusts. Look for:
- Early adopters (the person who always tries new software first).
- Informal influencers (the person others ask "how do I…?" questions).
- Department representatives (operations, sales, admin, field staff).
Approach them with: "We're migrating to Microsoft 365. We need your help making sure this doesn't suck for your team. You'll get early training, and you'll be the go-to person when others have questions. Interested?"
Most say yes-it's informal status and a voice in the process.
2. Train the Champions First (Week Before Cutover)
Give Champions early access to Microsoft 365 and dedicated training:
- Outlook: mail rules, focused inbox, calendar sharing, search.
- OneDrive: sync client setup, file sharing links (view vs edit), version history.
- Teams: chat vs channels, @mentions, file collaboration.
- SharePoint: how to find files, how to request access.
Don't do generic Microsoft training videos-do role-based scenarios. "Here's how you share a site inspection report with your manager. Here's how you find last month's timesheets."
3. Deploy Champions as Embedded Support (Weeks 1–4 Post-Cutover)
Champions become the first line of support. When a user has a question, they ask their Champion before they ask IT. This:
- Significantly reduces IT ticket volume.
- Keeps support contextual (the Champion knows the team's workflows).
- Builds confidence faster (peer-to-peer teaching feels less intimidating than formal IT training).
4. Recognise and Reinforce (Month 2–3)
Publicly acknowledge Champions in team meetings. Small gestures-a thank-you email from the COO, a coffee voucher, first access to new tools-signal that adoption work is valued.
The Alternative to Forms and Sites
If the acquired company used Google Forms for timesheets, feedback, or job applications, you need alternatives before cutover:
- Microsoft Forms: Direct replacement, included in most Microsoft 365 licences. Slightly less elegant UI, but functional parity.
- Power Automate: For complex workflows (e.g., Google Forms → Google Sheets → email notification), replicate with Power Automate flows connecting Forms to SharePoint lists.
For Google Sites (internal wikis, project hubs), migrate to:
- SharePoint sites: More powerful but steeper learning curve.
- Teams channels with embedded OneNote: Simpler, better for informal team knowledge bases.
Don't just shut down Google Forms and Sites on cutover day-provide the replacement and train users on it at least one week beforehand.
Identity and SSO Consolidation
This is often overlooked but critical: your acquired staff now need Microsoft 365 credentials. If your group uses Azure Active Directory (now Microsoft Entra ID) with SSO, they need to be provisioned there.
Recommended approach:
- Sync on-premises Active Directory (if you have one) to Azure AD using Azure AD Connect.
- Enable SSO so users authenticate once and access email, SharePoint, CRM, ERP with the same credentials.
- Enforce MFA (multi-factor authentication) from day one-don't grandfather the acquired company into weaker security.
If the acquired company had Google Workspace SSO into other tools (e.g., their CRM or HR system), you'll need to reconfigure those integrations to use Microsoft 365 SSO instead. Budget time for this-it's fiddly, often requires vendor support, and breaks if done wrong.
Timeline, Budget, and Resource Reality Check
Here are realistic numbers for a 50-user migration.
Timeline (50-User Acquisition)
- Week 1–2: Pre-migration audit, licence provisioning, user mapping.
- Week 3–5: Data migration (mail, drive, calendar). Run in batches-migrate 10–15 users at a time, validate, then proceed.
- Week 6: Cutover preparation, Champion training, final user comms.
- Week 7: Cutover weekend (Friday night to Sunday)-flip MX records, verify mail flow, confirm file access.
- Week 8–9: Hypercare support, issue triage, permission fixes.
Total: 7–9 weeks from kickoff to hypercare completion.
For larger acquisitions (100–200 users), extend to 10–14 weeks. For smaller (under 25 users), compress to 4–6 weeks.
Budget (50-User Acquisition)
| Cost Item | Estimate (GBP) |
|---|
| Microsoft 365 licences (first month, Business Standard @ £9.60/user) | £480 |
| Migration tooling (if using third-party tool, e.g., BitTitan) | £200–400 |
| Pre-migration audit & planning (internal IT, 20 hours @ £50/hr) | £1,000 |
| Data migration execution (contractor or partner, 20 hours @ £100/hr) | £2,000 |
| User training (Champion training + end-user sessions, 10 hours @ £100/hr) | £1,000 |
| Hypercare support (2 weeks, 30 hours @ £100/hr) | £3,000 |
| Total (Estimated) | £7,680–7,880 |
This assumes you have internal IT capacity for project management and basic support. If you're fully outsourcing, add another £2,000–4,000 for project coordination.
Resource Model: Internal vs Partner
Do it internally if:
- Your IT team has prior experience with Microsoft 365 migrations (specifically from Google Workspace).
- You have 40+ hours of available IT capacity over 6–8 weeks.
- User count is under 30 and data complexity is low.
Bring in a partner if:
- IT is already stretched thin with BAU and can't dedicate 40+ hours.
- You're migrating 50+ users or have complex shared drive structures.
- The migration is time-sensitive (PE sponsor deadline, security audit finding).
- You want documented handover and hypercare coverage (internal IT often can't provide 2-week dedicated support).
If that sounds like your situation, it's worth considering a partner who can execute the migration alongside your IT (not around them), document everything, and hand off cleanly -- so your IT stays focused on BAU whilst someone else handles the project intensity.
FAQ: Google Workspace to Microsoft 365 Migration
Q: Can we migrate Google Workspace to Microsoft 365 without downtime?
Yes. The migration happens in the background whilst users continue working in Google Workspace. Cutover (the moment you switch MX records and users start using Microsoft 365) is typically scheduled for a weekend to minimise disruption. Expect 2–4 hours of "email in flight" delays during cutover-mail sent during the MX record propagation window may be delayed but won't be lost.
Q: Do we lose email history during Gmail to Outlook migration?
No, if executed correctly. The native Microsoft 365 migration tool and reputable third-party tools (BitTitan, Cloudiway) preserve full mailbox history, including sent items, folders, and attachments. IMAP migration also preserves history but loses Gmail labels. Always run a test migration on a pilot user and verify completeness before proceeding with the full user base.
Q: What happens to Google Docs, Sheets, and Slides during migration?
They must be converted to Microsoft formats (.docx, .xlsx, .pptx) or exported as PDFs. Conversion introduces formatting risks-the Conversion Trap. Complex documents (heavily formatted reports, Sheets with scripts, Slides with embedded videos) often require manual QA and reformatting post-migration. Budget time for this.
Q: Can we keep Google Workspace running alongside Microsoft 365 indefinitely?
Technically, yes. Practically, no. Running dual platforms costs £6–12/user/month in duplicate licences, doubles IT admin overhead, fragments collaboration, and creates security gaps. If you're running dual platforms beyond six months, you're not deferring-you're stalling. Make the decision and execute.
Q: How do we handle Google Groups after migration?
Google Groups map to Microsoft 365 Groups or distribution lists. For simple email distribution (e.g., sales@acquiredco.com forwards to 10 people), create a distribution list in Exchange Online. For collaborative groups (shared mailbox + file storage + calendar), create a Microsoft 365 Group. Group membership and mail history migrate, but group settings (moderation rules, external posting permissions) must be reconfigured manually.
Q: What if users refuse to adopt Outlook and OneDrive?
This is a change management failure, not a technical one. If users are resisting, it's usually because: (a) they weren't trained, (b) the tools weren't configured to match their workflows, or (c) they don't understand why the change is happening. Go back to basics-deploy Digital Champions, run role-based training, and explain the business rationale (security, cost, group standardisation). Refusal is almost always a symptom of poor communication, not tool preference.
Q: Do we need to migrate Google Drive files, or can we leave them in Google?
You can leave them, but it defeats the purpose. If your group's file storage standard is SharePoint/OneDrive, leaving acquired company files in Google Drive creates:
- Fragmented document repositories (where's the current version of the safety SOP?).
- Ongoing Google Workspace licensing costs (you need active Google accounts to access Drive files).
- Security gaps (files outside your group's data loss prevention and backup policies).
Migrate the files. It's work, but it's necessary work.
Q: How long should we keep Google Workspace active post-migration?
Two to four weeks in read-only mode. This gives users a safety net-if they can't find a migrated file, they can log into Google and retrieve it. After four weeks, export any remaining critical data, then decommission the Google Workspace tenant. Don't leave it active indefinitely "just in case"-it's a cost leak and a security risk.
Q: Can PMI Stack handle the migration for us?
Yes. PMI Stack executes Google Workspace to Microsoft 365 migrations as part of post-acquisition integration. The process covers auditing your Google environment, provisioning Microsoft 365 accounts, migrating mail/drive/calendar in batches, configuring SharePoint permissions, training Digital Champions, and providing two weeks of hypercare support post-cutover. Everything is documented and handed off cleanly, working alongside your IT rather than around them. Get in touch if you'd like to discuss your specific migration.
