Google Workspace to Microsoft 365: a migration checklist

By Akash Sengar · 6 October 2026 · 5 min read

Before you start

A move between Google Workspace and Microsoft 365 is mostly planning. The data copy is the visible part; the risk sits in DNS, devices, shared files and people. This checklist assumes a move to Microsoft 365. The reverse move uses the same discipline with the tools swapped.

Microsoft documents its built-in tools: Google Workspace migration in Exchange Online for mail, calendars and contacts, and Migration Manager for Google Drive for files. Read both before you plan; they set the prerequisites, such as the Google service account and API access, and list what is and is not migrated.

1. Inventory

• Users, with mailbox sizes and Drive usage
• Groups and distribution lists, and who can post to them
• Shared mailboxes, delegates and aliases
• Shared drives, with owners, members and the external people who have access
• Calendars, meeting rooms and other resources
• Third-party apps that sign in with Google or send mail as your domain (CRM, billing, website forms)
• Devices: company laptops and phones, and how they are managed today
• DNS records at your registrar: MX, SPF, DKIM, DMARC and any verification records

Record what will not move automatically. Each tool's documentation lists exclusions; plan a manual step or an accepted loss for each.

2. Licensing and tenant

• Choose plans by what users need: desktop apps, device management, advanced security. Mixed licensing is common.
• Create the tenant and add and verify your domain in the Microsoft 365 admin centre. Verification uses a DNS TXT record and does not affect mail flow.
• Create users with the same primary email addresses they have today, and add aliases.
• Set up multi-factor authentication and the security baseline before users arrive, not after.

3. DNS and MX cutover plan

The MX change is the moment mail starts arriving in Microsoft 365. Plan it in writing:

1. Lower the TTL on your MX record a few days before cutover so the change propagates quickly.
2. Pick a quiet cutover window and tell users when it is.
3. Pre-stage most mail with an initial migration batch so the final sync after cutover is small.
4. At cutover, update MX to the value shown in the Microsoft 365 admin centre, and add the Autodiscover record it asks for.
5. Update SPF to include Microsoft 365 and remove Google once nothing sends through Google any more. Keep one SPF record only.
6. Enable DKIM in Microsoft 365 and publish its CNAME records. Keep the DMARC record, and watch its reports during the transition.
7. Run a final incremental sync to pick up mail that arrived in Gmail during propagation.

4. Mail, calendar and contacts

Exchange Online's Google Workspace migration moves mail, calendar and contacts in batches. Check folder and label behaviour, large attachments and calendar sharing in the pilot. Recurring meetings and room bookings deserve a test: recreate resources in Microsoft 365 and check that meetings created before the move still behave.

5. Drive and shared drives

Map each source to a destination before you copy anything:

• Personal My Drive content usually moves to each user's OneDrive.
• Shared drives usually become SharePoint sites or Teams, one per team or function.
• Google Docs, Sheets and Slides are converted to Office formats; check complex spreadsheets, scripts and forms, which may not convert cleanly.
• Sharing permissions do not always map one to one. Review external sharing after the move.

Freeze edits on shared drives during the final pass, or agree how late changes will be handled.

6. Devices and sign-in

• Plan how laptops will be managed after the move, for example with Microsoft Intune, and how they will be enrolled.
• Re-point apps that use Sign in with Google to Microsoft Entra ID single sign-on where they support it.
• Set up Outlook, OneDrive and Teams on phones, and remove the Google account only after mail has been verified.

7. User communication

Most migration complaints are surprises. Send three short messages:

1. A week before: what is changing, the date, what users need to do, and who to contact.
2. The day before: sign-in instructions, MFA set-up, and a reminder not to delete anything in Google.
3. After cutover: how to find mail, files and calendars, and where to report problems.

Keep a one-page guide with screenshots for sign-in, MFA and file locations.

8. Rollback

Write the rollback plan before cutover. Keep Google Workspace licences active for a period after the move. If mail flow fails, rollback means pointing MX back to Google and syncing any mail that landed in Microsoft 365. Decide in advance who can call a rollback and by when.

9. Post-migration checks

• Send and receive tests to and from external domains, including Gmail and Outlook.com
• SPF, DKIM and DMARC pass on messages from the new platform (check with our free email security check)
• Every user can sign in with MFA, and admin accounts are separate from daily accounts
• Shared mailboxes, distribution lists and delegates work as expected
• Files are in the expected sites, with the right permissions and external sharing settings
• Third-party apps send mail and sign in correctly
• Old Google data is retained for an agreed period, exported if needed, and then the subscription is closed

Allow a hypercare period of focused support straight after cutover. Questions cluster in the first few days.

A typical cutover sequence

Every migration is different, but most follow the same order:

1. Weeks before: inventory, licences, tenant set-up, domain verification in Microsoft 365, pilot group chosen.
2. Pilot: move a handful of willing users first, including someone from finance and someone who travels. Fix what they find.
3. Pre-stage: copy older mail, calendars and files in batches while users keep working in Google Workspace.
4. Lower the TTL on MX and related records a day or two ahead, so changes take effect quickly.
5. Cutover: switch MX, run a final incremental sync, and give users their new sign-in details.
6. First days: hypercare support, mobile device set-up, checks on shared mailboxes and calendars.
7. Afterwards: keep the old platform read-only for an agreed period, then export what you must keep and close it.

Microsoft documents its built-in mailbox move in performing a Google Workspace migration through the Exchange admin center. Third-party migration tools are another option, particularly for Drive content. Test whichever tool you pick in the pilot before trusting it with everyone.

Common pitfalls

• Forgetting services that send mail as your domain, such as billing, CRM and website forms, so they break or fail DMARC after cutover
• Not checking Google Drive file ownership: files owned by departed users can be missed
• Assuming Google Docs, Sheets and Slides arrive unchanged: they are converted to Office formats, and complex formulas, scripts or add-ons may need rework
• Leaving MFA and Conditional Access until after cutover, when the tenant is busiest
• Cancelling Google Workspace too early, before exports and retention are settled
• Telling users on the day: people need the date, what changes and where to get help in advance

The reverse move, Microsoft 365 to Google Workspace, needs the same discipline: inventory, a pilot, a DNS plan, rollback and checks afterwards. Only the tools change.