Move from Google Workspace to Microsoft 365
Move mail, calendars, Drive files and sign-ins from Google Workspace to Microsoft 365 in a safe order, without bouncing mail or locking anyone out.
Official sources last reviewed · How we review
Build your personalized plan
A few questions, revealed as they become relevant. Your answers stay in this browser.
Start with the basics
We never ask for phone numbers, card numbers, passwords or codes. Names of providers or nicknames are enough.
Your plan so far
26things this change touches
- critical8
- high11
- moderate6
- low1
Updates as you answer. Every item will explain why it’s there.
What could break
In a typical google workspace to microsoft 365 plan, these are the most serious things to get right.
Keep Google Workspace fully active until the move is confirmed
Critical · Business operations
Cancelling, downgrading or deleting accounts early can cut the migration short and delete data you haven't copied yet.
Add and verify your domain in Microsoft 365 (TXT record only)
Critical · Website & DNS
Changing MX records during setup sends all new mail to empty mailboxes before the migration is ready.
Require multi-factor sign-in for every Microsoft 365 account
Critical · Sign-in & recovery
An account taken over during the move gives an attacker your company's mail and files.
Copy mail, calendars and contacts with Microsoft's Google Workspace migration
Critical · Data & files
Started too late or set up wrongly, people arrive in Microsoft 365 with missing mail or calendars.
Copy Google Drive files with Microsoft's Migration Manager
Critical · Data & files
Files arrive without their sharing permissions or older versions, or some files are skipped entirely.
Apps your team signs in to with Google
Critical · Sign-in & recovery
When the old accounts are removed, staff can't sign in to those apps, and the data in them may be hard to reclaim.
Change MX records to Microsoft 365
Critical · Email delivery
A wrong or partial change can bounce mail or split it between two systems.
Test incoming and outgoing mail from outside your organization
Critical · Email delivery
Customer emails bounce or your replies land in spam, and nobody notices for days.
Export a final copy of your Google Workspace data
Critical · Data & files
Once the old subscription is cancelled, anything not exported may be unrecoverable.
Cancel Google Workspace only after everything is validated
Critical · Subscriptions & billing
Anything you forgot to move or export is lost.
Before and after the change
Before you change it
- Keep Google Workspace fully active until the move is confirmed
- Inventory Google Workspace users, addresses, groups and shared drives
- Files and mail owned by suspended or former staff accounts
- Choose Microsoft 365 plans and buy licences
- Tell staff the cutover date and what they'll need to do
- Create Microsoft 365 users with matching addresses
- Set up two protected Microsoft 365 admin accounts
- Add and verify your domain in Microsoft 365 (TXT record only)
- Set up the mail routing subdomains the migration uses
- Add Gmail aliases as extra addresses in Microsoft 365
- Re-create Google Groups as distribution lists or Microsoft 365 groups
- Require multi-factor sign-in for every Microsoft 365 account
After the change
- Change MX records to Microsoft 365
- Add the Autodiscover record for Outlook
- Update SPF to include Microsoft 365 (one record only)
- Publish Microsoft 365 DKIM records and turn on signing
- Verify DMARC alignment for mail sent from Microsoft 365
- Services that send email as your domain
- Set up Outlook, OneDrive and Teams on every computer
- Add Microsoft 365 to phones and tablets
- Re-create rooms, shared calendars and recurring meeting links
- Update links to Google Drive files, forms and calendars
- Give people a short orientation on Outlook, OneDrive and Teams
- Test incoming and outgoing mail from outside your organization
Your own plan adds or removes items based on your answers, and explains why each one is there.
The safe order
Doing things in the right sequence is what keeps you from getting locked out halfway through.
Before the change
Step 1: Inventory what you have and plan the move
List users, addresses, shared drives and holds, buy licences and tell staff the plan. Google stays fully active throughout.
- Keep Google Workspace fully active until the move is confirmed (critical risk)
- Inventory Google Workspace users, addresses, groups and shared drives (high risk)
- Files and mail owned by suspended or former staff accounts (high risk)
- Choose Microsoft 365 plans and buy licences (moderate risk)
- and 1 more
Step 2: Create Microsoft 365 users
Matching addresses, licences and two protected admin accounts.
- Create Microsoft 365 users with matching addresses (high risk)
- Set up two protected Microsoft 365 admin accounts (high risk)
Step 3: Verify your domain in Microsoft 365
TXT record only. Mail keeps flowing to Google until the MX step.
- Add and verify your domain in Microsoft 365 (TXT record only) (critical risk)
- Set up the mail routing subdomains the migration uses (high risk)
Step 4: Create aliases, groups and shared mailboxes
Every address that receives mail today needs a home in Microsoft 365 before MX changes.
- Add Gmail aliases as extra addresses in Microsoft 365 (high risk)
- Re-create Google Groups as distribution lists or Microsoft 365 groups (high risk)
Step 5: Configure security before anyone moves
Multi-factor sign-in, security keys and mail filtering, before any data is copied.
- Require multi-factor sign-in for every Microsoft 365 account (critical risk)
- Set up Exchange Online spam, phishing and quarantine settings (moderate risk)
Step 6: Begin the mail and data migration
Pilot first, then copy mail, calendars, contacts and Drive files while Google stays live.
- Run a pilot with a few users first (moderate risk)
- Copy mail, calendars and contacts with Microsoft's Google Workspace migration (critical risk)
- Map shared drives to SharePoint sites or Teams (high risk)
- Copy Google Drive files with Microsoft's Migration Manager (critical risk)
- and 1 more
Step 7: Export or rebuild what the tools don't move
Forms, Sites, scripts, chat history and personal items.
- Ask users to save Keep notes, Tasks, bookmarks and saved passwords (high risk)
- Google Forms: export responses and test how forms move (moderate risk)
Step 8: Inventory everything that depends on Google sign-in
Apps, single sign-on, integrations, devices that send mail and Google services owned by work logins.
- Apps your team signs in to with Google (critical risk)
- Integrations connected to Gmail, Calendar or Drive (high risk)
- Printers, scanners and apps that send mail through Gmail (high risk)
- Google Ads, Analytics and other accounts owned by Workspace logins (high risk)
Step 9: Prepare DNS for cutover
Save your records, confirm access and lower TTLs a day or more ahead.
- Save your current DNS records and confirm you can edit them (high risk)
- Lower the TTL on your MX records ahead of cutover (moderate risk)
During the change
Step 10: Change MX records
The moment new mail starts arriving in Microsoft 365.
- Change MX records to Microsoft 365 (critical risk)
- Add the Autodiscover record for Outlook (moderate risk)
Step 11: Change SPF
One SPF record that includes Microsoft 365 and every other sender.
- Update SPF to include Microsoft 365 (one record only) (high risk)
Step 12: Configure DKIM
Microsoft 365 doesn't sign mail for your domain until you turn it on.
- Publish Microsoft 365 DKIM records and turn on signing (high risk)
Step 13: Verify DMARC alignment
Make sure mail from Microsoft 365 and your other senders still passes.
- Verify DMARC alignment for mail sent from Microsoft 365 (high risk)
- Services that send email as your domain (moderate risk)
Immediately after
Step 14: Switch computers, phones and people over
Desktop apps, phones, device management, calendars, links and a short orientation.
- Set up Outlook, OneDrive and Teams on every computer (high risk)
- Add Microsoft 365 to phones and tablets (high risk)
- Re-create rooms, shared calendars and recurring meeting links (moderate risk)
- Update links to Google Drive files, forms and calendars (moderate risk)
- and 1 more
Verify
Step 15: Validate incoming and outgoing mail
Test from outside your organization, not just between colleagues.
- Test incoming and outgoing mail from outside your organization (critical risk)
Step 16: Validate aliases, groups and shared mailboxes
Every address on your inventory gets a test message.
- Send a test to every alias, group and shared address (high risk)
Step 17: Validate mobile and desktop clients
Phones, Outlook, calendar invites and app sign-ins.
- Check phones, computers and calendar invites (high risk)
- Sign in to every business app with the new method (high risk)
Step 18: Confirm the migration is complete
Final sync, reports reviewed and every user signed off.
- Confirm the migration is complete before anything is removed (high risk)
Clean up
Step 19: Archive and export old Google data
While Google Workspace is still fully active.
- Export a final copy of your Google Workspace data (critical risk)
Step 20: Remove Google Workspace only after validation
DNS cleanup, the domain, and finally the subscription.
- Remove Google mail records and the migration's routing domains (moderate risk)
- Cancel Google Workspace only after everything is validated (critical risk)
Why this change needs a plan
Moving from Google Workspace to Microsoft 365 is more than moving mailboxes. Your DNS records decide where mail goes and whether it's trusted, aliases and groups have to be rebuilt, Drive files are converted to Office formats, and every app that uses Sign in with Google is tied to accounts you're about to retire.
Microsoft provides tools for the heavy lifting: a Google Workspace migration for mail, calendars and contacts, and Migration Manager for Drive files. Neither moves everything. Auto-replies, shared calendars, room bookings, Google Sites and most automations need separate handling, and settings such as file-level permissions and older file versions have to be switched on.
The safe pattern is to build Microsoft 365 alongside Google, copy data while Google keeps receiving mail, cut over DNS in a quiet window, validate everything from outside your organization, and only then export a final copy and cancel. Provider tools and instructions change, so check the linked official documentation before each step.
Why it matters
Email is how customers, suppliers and banks reach your business, and your Google accounts quietly sign you in to other apps and own your ads and analytics. A rushed switch can bounce customer mail, leave files behind or lock staff out of the tools they use every day.
What makes it risky
Risk is highest when MX records change before mailboxes and aliases are ready, when SPF, DKIM and DMARC aren't updated for Microsoft 365, when apps depend on Sign in with Google, and when Google Workspace is cancelled before a final export. Larger teams, legal holds and domains bought through Google add more risk.
Common mistakes
- Letting the Microsoft 365 domain setup change MX records on day one, before mailboxes and aliases are ready.
- Cancelling Google Workspace or deleting users before the final export and user sign-off.
- Forgetting aliases, groups and catch-all addresses, so mail to sales@ or info@ bounces after cutover.
- Creating a second SPF record instead of editing the existing one.
- Never turning on DKIM in Microsoft 365, so mail fails DMARC or lands in spam.
- Assuming Drive permissions, older versions and sharing links carry over without changing any settings.
- Losing access to apps, Google Ads or Analytics that were tied to a Workspace login.
- Leaving printers, scanners and website forms sending mail through Gmail.
Frequently asked questions
Does Microsoft's migration tool move everything from Google Workspace?
No. Microsoft's Google Workspace migration covers mail (with filters, which arrive as rules turned off by default), calendars and contacts, and Drive files move separately with Migration Manager. Microsoft's documentation lists things that don't move, including vacation replies, room bookings, shared calendars, Google Sites and Google Maps, so plan for those separately.
What happens to Google Docs, Sheets and Slides?
Microsoft's Migration Manager documentation says they're converted to Word, Excel and PowerPoint files during the copy, and the originals in Google Drive aren't changed. By default only the latest version is copied. Formatting, comments, scripts and Google-only spreadsheet functions may not carry over, so check important files during a pilot.
When should we change the MX records?
After users, aliases and groups exist in Microsoft 365 and most mail has been copied. Lower the TTL a day or two ahead, change MX in a quiet window, then run a final sync so mail that reached Gmail during the switch is copied across.
Will we lose email during the cutover?
Not if Google stays active. Some servers keep delivering to Gmail until their cached DNS expires, which is why the final sync after the MX change matters. Cancelling Google too early is the usual cause of lost mail.
Do we need to change SPF, DKIM and DMARC?
Yes. Add Microsoft 365 to your existing SPF record (one record only), publish Microsoft's DKIM records and turn on signing, which Microsoft says doesn't happen for custom domains by default, and confirm mail still passes DMARC. Remove Google's entries only after Google stops sending.
What happens to apps we sign in to with Google?
They keep working only while the Google accounts exist. Before removing those accounts, add a password or switch each app to Sign in with Microsoft. Some apps can't change their sign-in method, so ask the vendor early.
How long should we keep Google Workspace after moving?
Until users have signed off, a final export is downloaded and nothing new is arriving in Gmail, which is often a few weeks. Google's cancellation guide says users' data is deleted and can't be restored after you cancel, so verify Google's current policy before cancelling.
Can we move Google Forms, Sites and Apps Script?
Microsoft's Migration Manager documentation says Google Forms can now be migrated when a Forms destination is set, while Google Sites aren't migrated. Apps Script and AppSheet automations have to be rebuilt, for example in Power Automate or Power Apps.