Google Workspace to Microsoft 365, then cancel Workspace
The migration and the cancellation in one plan, so Workspace isn't cancelled before everything has moved.
Saves the combined checklist in this browser with typical answers. You can refine each change afterwards.
The most expensive mistake in a Workspace to Microsoft 365 move is cancelling Google too early. This plan combines the migration with the cancellation and keeps the cancellation last.
Doing these together: read this first
Cancel Google Workspace only after the move is checked
Keep the old subscription until mail, files and calendars are confirmed in Microsoft 365 and nobody signs in with Google anymore.
Change one way of signing in at a time
More than one of these changes affects how you sign in or recover accounts. On each account, update one sign-in or recovery method, check you can still sign in and receive codes, then update the next. Never remove an old method before the new one works.
Cancel and close things last
Finish the other changes before you cancel or close anything. An old account, number or service is often what lets you sign in, receive a code or download your records while the rest moves.
The combined checklist
53 tasks from typical answers, with 20 shared tasks merged. Yours will match your answers.
Before the change36
Keep Google Workspace fully active until the move is confirmed Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacecritical
Do this: Don't cancel, downgrade, suspend or delete Google users until every verify step in this plan is done and a final export is downloaded. Budget for both subscriptions during the overlap.
For the other change: Complete the migration to your new provider, including a final copy after the MX change, before cancelling. Keep Google Workspace fully active until users confirm their data arrived.
Why: Microsoft's migration tools copy from live Google accounts, and mail keeps arriving in Gmail until DNS changes everywhere. Google's export documentation also says core services like Gmail and Drive are excluded from an organization export once the subscription is cancelled or suspended.
Check it worked: The old platform's billing page still shows an active subscription on cutover day.
Add and verify your domain in Microsoft 365 (TXT record only)Google Workspace to Microsoft 365critical
Do this: Add the domain in the Microsoft 365 admin center and publish only the verification TXT record. When setup offers to add MX and other email records, choose to add them yourself later. Microsoft's documentation notes that once the MX record changes, all new email for the domain goes to Microsoft 365.
Why: Verification proves you own the domain and usually needs only a TXT record. Setup wizards often offer to change MX and other records at the same time.
Check it worked: The admin console shows the domain as verified, and mail still arrives in the old mailboxes.
Require multi-factor sign-in for every Microsoft 365 accountGoogle Workspace to Microsoft 365critical
Do this: Microsoft's documentation says security defaults, which require everyone to register for multi-factor sign-in and block older sign-in methods, are on for new tenants. Confirm they're on (or use Conditional Access if your plan includes it) before any data is copied, and have users register before cutover day.
Why: New accounts with temporary passwords are an easy target during a migration, and phishing is easier when staff expect unfamiliar sign-in messages.
Check it worked: The admin console shows every user registered for multi-factor sign-in.
Copy mail, calendars and contacts with Microsoft's Google Workspace migrationGoogle Workspace to Microsoft 365critical
Do this: Start the copy well before cutover so the bulk is done early. Microsoft's documentation says filters arrive as rules turned off by default, and that vacation and auto-reply settings, room bookings, shared calendars and event colours don't migrate. It also recommends turning off archive and retention (MRM) policies on the Microsoft side until the move is finished.
Why: Microsoft's Google Workspace migration copies mail with its filters, calendars and contacts into Exchange Online, and can move users in batches.
Check it worked: Migration reports show each user completed, and skipped-item counts are explained.
Copy Google Drive files with Microsoft's Migration ManagerGoogle Workspace to Microsoft 365critical
Do this: Scan your Google Drives first and review the report. Microsoft's documentation says file-level permission migration is off by default, only the latest version is copied unless you change it, shortcuts are skipped and files that aren't in anyone's folders aren't scanned. Turn on what you need before the copy.
Why: Microsoft's Migration Manager copies Google Drive files, metadata and permissions to OneDrive and SharePoint, but several settings are off by default.
Check it worked: Scan and migration reports show no unexplained failures, and a sample of files opens with the expected access.
Apps your team signs in to with Google Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacecritical
Do this: In the Google Admin console, review the apps that have accessed your organization's data to find the ones people sign in to with Google. For each, add a password or switch to Sign in with Microsoft before Google accounts are removed. If an app can't change its sign-in method, ask the vendor how to move the account.
For the other change: List the apps people sign in to with their work account. For each one, add a password or switch to the new platform's sign-in before the old accounts are removed. If an app can't change its sign-in method, ask the vendor how to move the account.
Why: Sign in with Google or Sign in with Microsoft ties each app account to that identity rather than to a password.
Check it worked: Each user can sign in to every business app without the old account.
Change MX records to Microsoft 365 Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacecritical
Do this: In a quiet window after the bulk of mail has copied, replace Google's MX records with the MX value shown in the Microsoft 365 admin center. Microsoft's documentation says to remove MX records that point to the previous provider or give them a lower priority, and its batch migration overview describes updating MX after all batches are complete. Then let the migration run a final sync.
For the other change: Set up mailboxes, aliases and group addresses at the new provider, then change MX records to it. Wait for mail to arrive there, and copy anything that landed in Gmail during the switch, before cancelling.
Why: MX records decide where new mail for your domain is delivered. This is the moment the switch actually happens.
Check it worked: A DNS lookup shows only the new MX records, and a test message from outside arrives in the new mailbox.
Test incoming and outgoing mail from outside your organization Do once for 3 changesGoogle Workspace to Microsoft 365Cancel Google WorkspaceCancel Google Workspacecritical
Do this: From an outside mailbox, such as a personal Gmail or Outlook.com account, send to and receive from several users. Check the headers of a received message for spf=pass, dkim=pass and dmarc=pass.
For the other change: From an outside mailbox, send to each main address, alias and group and confirm it arrives at the new provider, not in Gmail. Check that replies from the new provider pass SPF, DKIM and DMARC.
For the other change: Send a test from an outside mailbox to your main address and a group address, and confirm replies still arrive and pass authentication.
Why: Mail between colleagues can work while mail from the outside world fails. Only an outside test proves MX, SPF, DKIM and DMARC work together.
Check it worked: Messages arrive both ways within minutes and the headers show all three checks passing.
Export a final copy of your Google Workspace data Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacecritical
Do this: Run the Data Export tool in the Google Admin console while the subscription is fully active. Google's documentation says it needs a super admin account with 2-Step Verification, that exports can take several days, and that exported files are only kept for a limited time, so download them promptly and store them somewhere access-controlled.
For the other change: Run the Data Export tool in the Google Admin console while the subscription is active. Google's documentation says it needs a super admin account with 2-Step Verification, that exports can take several days, and that exported files are only kept for a limited time, so start early and download promptly.
Why: A complete export is your safety net for anything the migration missed and for records you may need later.
Check it worked: Open the export and spot-check a few mailboxes and folders from different users.
Inventory Google Workspace users, addresses, groups and shared drivesGoogle Workspace to Microsoft 365high
Do this: Export the user list from the Google Admin console and note, for each person, their licence, aliases, group memberships, delegated mailboxes and Gmail and Drive storage. List every group address, shared drive, catch-all or routing setting, and accounts kept for former staff.
Why: Every later step depends on knowing exactly which users, addresses, groups, shared inboxes and storage you're moving. Most migration surprises are things nobody listed.
Check it worked: Every address that receives mail today appears on the list with a destination in the new system.
Files and mail owned by suspended or former staff accounts Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Decide which former-staff accounts still own files, forms or scripts the team uses. Transfer their Drive files to an active user in the Google Admin console (Google notes that items in Trash aren't transferred) or include them in the migration, and export anything you must keep.
For the other change: Check whether accounts kept for former staff still own files the team needs. Transfer those files to an active user or include them in your export before cancelling (Google notes that items in Trash aren't transferred).
Why: Accounts kept for former staff often own shared files, forms or automations the team still uses, and migration tools usually work account by account.
Check it worked: No file the team uses is still owned by a suspended or departed account.
Create Microsoft 365 users with matching addressesGoogle Workspace to Microsoft 365high
Do this: Create each user with the same primary address they have in Google Workspace and assign a licence. Microsoft's Google Workspace migration documentation asks for users to be provisioned before migration (as mail users for its batch method), so follow the method your tool expects to avoid duplicate accounts.
Why: Mail, calendars and files are copied into matching accounts. Addresses must match exactly so replies, meeting invites and sharing keep working.
Check it worked: The user count and addresses in the new admin console match your inventory.
Set up two protected Microsoft 365 admin accounts Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Create a second admin account that isn't tied to one person's daily mailbox, protect both with strong multi-factor sign-in, and keep recovery details somewhere the business controls.
For the other change: Make sure at least two super admins can sign in with 2-Step Verification, with recovery details that don't depend on the Gmail you're cancelling, such as an address on another domain.
Why: A new organization often starts with one admin account created at sign-up. If that person is unavailable or locked out, nobody can manage the migration.
Check it worked: Both admins can sign in to the admin console with multi-factor sign-in.
Set up the mail routing subdomains the migration usesGoogle Workspace to Microsoft 365high
Do this: If you use Microsoft's built-in Google Workspace migration, follow its prerequisites: create one routing subdomain for Microsoft 365 and one for Google Workspace, add the Google one as a user alias domain in Google, and verify both. Third-party migration tools may work differently.
Why: Microsoft's Google Workspace migration expects two routing subdomains, one pointing to each platform, so mail reaches users on whichever side they're on during the move.
Check it worked: Both routing subdomains show as verified or active in their admin consoles.
Add Gmail aliases as extra addresses in Microsoft 365 Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Add every alias from your Google inventory as an additional email address on the matching Microsoft 365 user before MX records change.
For the other change: Compare your Google aliases and group addresses with the new provider's settings, and add anything missing before cancelling.
Why: Aliases are settings on the old platform, not mail. Mailbox migrations copy messages, not every address that delivered them.
Check it worked: Each user's address list in the new admin console matches the old one.
Re-create Google Groups as distribution lists or Microsoft 365 groupsGoogle Workspace to Microsoft 365high
Do this: Re-create each Google Group with the same address and members, as a distribution list (mail only) or a Microsoft 365 group (with a shared calendar and files). Check whether people outside your organization can send to it, because addresses like sales@ usually need that.
Why: Addresses like sales@ or info@ are often groups, not mailboxes. Groups are recreated rather than migrated, and their delivery settings matter.
Check it worked: Send a message from an outside address to each group and confirm every member receives it.
Map shared drives to SharePoint sites or Teams Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Decide which SharePoint site or team each shared drive becomes and who can access it. Microsoft's Migration Manager documentation describes steps to complete before a shared drive migration so its permissions come across correctly; do those first.
For the other change: Copy or migrate each shared drive's files to the new storage before cancelling, and check that the team who used it can find and open them there.
Why: Shared drives hold team files with their own membership. Each needs a destination with the right people, and permissions need preparing before the copy.
Check it worked: Members of each shared drive can open its files in the new location, and non-members can't.
Ask users to save Keep notes, Tasks, bookmarks and saved passwords Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Ask each user to export Google Keep notes and Google Tasks they need, plus bookmarks and passwords saved to Chrome or Google Password Manager under their work account. Allow Google Takeout for users in the Admin console if it's turned off, and move business passwords into your company password manager.
For the other change: Make sure Google Takeout is allowed for users in the Admin console, and ask each person to download what they need, including Keep notes, Tasks, bookmarks and saved passwords, before the cancellation date.
Why: Mailbox and file migrations focus on mail, calendars, contacts and files. Notes, task lists, browser bookmarks and passwords saved to a work browser profile are easy to lose.
Check it worked: Each user confirms their passwords, bookmarks and notes are available outside the old account.
Integrations connected to Gmail, Calendar or Drive Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Review the apps with access to your organization's data in the Google Admin console, such as CRM email sync, scheduling links, e-signature, backup tools and scanners that save to Drive. For each one you keep, plan to reconnect it to Microsoft 365 at cutover.
For the other change: Review the apps with access to your organization's data in the Google Admin console. Reconnect the ones you keep to your new provider before cancelling, and remove the rest.
Why: CRMs, e-signature tools, schedulers, backup services and automations often connect directly to mailboxes, calendars or file storage.
Check it worked: Each integration shows a healthy connection to the new platform and has processed new data.
Printers, scanners and apps that send mail through Gmail Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Find every device and app configured with the old provider's mail server settings or app passwords, and plan new settings for each on the new platform or a dedicated sending service.
Why: Scan-to-email, website forms, accounting tools and alarm systems are often set up to send through the old provider's mail servers with a stored password.
Check it worked: Each device and app sends a test message after cutover.
Google Ads, Analytics and other accounts owned by Workspace logins Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: In each service, add an owner or admin that will remain after the move, confirm it works, then remove the old login.
Why: Ads, analytics and listing accounts are often owned by one Workspace user, and access to them follows that Google account.
Check it worked: Each service lists at least two owners you control, at least one of which isn't being removed.
Save your current DNS records and confirm you can edit themGoogle Workspace to Microsoft 365high
Do this: Export or screenshot every DNS record for your domain and confirm you can sign in to the DNS host. Mark which records belong to Google mail (MX, SPF, DKIM) and which belong to other services, such as google-site-verification records used by Search Console, which must stay.
Why: A copy of today's records is your rollback plan. Some records, such as site verification TXT records, belong to other services and must stay.
Check it worked: You have a dated copy of the records and a working login to the DNS host.
Confirm the migration is complete before anything is removed Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacehigh
Do this: Run a final sync after the MX change, review migration reports for skipped or failed items, compare mailbox and file counts, and ask each user to confirm their mail, calendar and files look right.
For the other change: Download the organization export and spot-check several users' mail and Drive files, plus any shared drive and Vault exports. Confirm the files open and cover the dates you need.
Why: Migration tools report skipped and failed items. Reviewing them, and asking users to check, is the last chance to catch gaps while the old data still exists.
Check it worked: Every user has signed off and every skipped item is explained or exported.
Choose Microsoft 365 plans and buy licencesGoogle Workspace to Microsoft 365moderate
Do this: Match what you use in Google today (desktop apps, device management, archiving, retention, mailbox size) to Microsoft 365 plans before buying, and assign a licence to each user who needs a mailbox.
Why: Plans differ in desktop apps, device management, archiving and retention. Buying the wrong plan can leave out something you rely on today.
Check it worked: Each user has a licence assigned in the new admin console, and the plan covers the features on your inventory.
Tell staff the cutover date and what they'll need to do Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacemoderate
Do this: Share the cutover date, how to set up multi-factor sign-in for Microsoft 365, which apps to install (Outlook, Teams, OneDrive), who to ask for help, and a request to avoid reorganizing large Drive folders while files are being copied.
For the other change: Tell everyone the cancellation date, where mail and files will live afterwards, and what to download beforehand. Ask them to list services they signed up for with their work address.
Why: People need to know the date, how they'll sign in, and what to set up on their phones and computers. Clear notice prevents lost work and panicked support calls.
Check it worked: Every user has acknowledged the notice and knows who to contact.
Set up Exchange Online spam, phishing and quarantine settingsGoogle Workspace to Microsoft 365moderate
Do this: Note allowed and blocked senders and any Gmail compliance or routing rules in the Google Admin console, and set up equivalents in Microsoft 365. Decide who reviews quarantined mail in the first weeks.
Why: Allowed senders, blocked senders, quarantine and forwarding policies are set separately on each platform and don't migrate.
Check it worked: Check quarantine daily for the first week after cutover for wrongly held messages.
Run a pilot with a few users firstGoogle Workspace to Microsoft 365moderate
Do this: Migrate two or three willing users end to end, including one heavy file user, then fix what you learn before migrating everyone.
Why: A pilot reveals tool settings, copy speed, permission and conversion problems while they're cheap to fix.
Check it worked: Pilot users confirm mail, calendar, contacts and files look right on the new platform.
Check how Docs, Sheets and Slides convertGoogle Workspace to Microsoft 365moderate
Do this: During the pilot, open your most important converted documents and spreadsheets. Check formulas that pull live data or link to other sheets, scripts attached to files, comments and formatting. Keep the originals until owners confirm.
Why: Microsoft's documentation says Google Docs, Sheets and Slides are converted to Word, Excel and PowerPoint files during the copy, and Google Drawings become images. Conversion isn't always perfect.
Check it worked: Owners of key spreadsheets and templates confirm the converted versions work.
Google Forms: export responses and test how forms move Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacemoderate
Do this: Export responses for each important form to Sheets or CSV. Microsoft's Migration Manager documentation says Google Forms are now migrated when a Forms destination is set; test a migrated form end to end, or rebuild it in Microsoft Forms, and update links on your website.
For the other change: Export responses for each form to a spreadsheet, rebuild the forms you still need elsewhere, and update links on your website and documents before cancelling.
Why: Forms often collect orders, bookings or applications, and their responses and public links are easy to forget.
Check it worked: Submit a test response to each replacement form and confirm it's received.
Lower the TTL on your MX records ahead of cutoverGoogle Workspace to Microsoft 365moderate
Do this: At least a day before cutover (longer than the current TTL), lower the TTL on your MX records to a short value, such as 5 to 15 minutes, if your DNS host allows it. Raise it again once the move is stable.
Why: TTL controls how long other servers cache your MX records. A short TTL makes the switch take effect faster and makes a rollback quicker.
Check it worked: A DNS lookup tool shows the lower TTL being served for your MX records.
Gmail, Calendar and Meet stop for every userCancel Google Workspacecritical
Do this: Pick a cancellation date that comes after email, calendars and files have a new home, and make sure everyone knows it.
Why: Google's cancellation guide says users lose core services such as Gmail, Calendar and Meet when you cancel, while some additional services, like YouTube and Google Photos, can stay available.
Check it worked: Every user can name the date and where their mail and files will live afterwards.
Users' Google Workspace data is deletedCancel Google Workspacecritical
Do this: Treat cancellation as permanent for data: export everything you need first and don't plan around a grace period. Verify the provider's current retention/cancellation policy.
Why: Google's cancellation guide warns that after you cancel, your users' Google Workspace data will be deleted and can't be restored.
Check it worked: Every export in this plan is downloaded and opened before you cancel.
Services registered to work email addressesCancel Google Workspacehigh
Do this: Ask each person to list services they signed up for with their work address. Make sure mail for those addresses keeps arriving somewhere, or change each account's email first.
Why: Staff often sign up for supplier portals, software, events and bank services with their work address, and password resets and security codes go to that address.
Check it worked: Each listed service shows an address that still receives mail.
Phones and computers managed through GoogleCancel Google Workspacehigh
Do this: Decide how these devices will be managed after cancelling. Remove company accounts and data from devices that are leaving, and enroll the rest in your new management tool before cancelling.
Why: Managed devices take security policies, Wi-Fi settings and work apps from the old platform. That management doesn't transfer on its own.
Check it worked: Each device shows as managed and compliant in the new console.
Export data from apps you won't keep usingCancel Google Workspacemoderate
Do this: For each app you won't keep, export the data you need and delete what you no longer want stored there.
Why: Google's cancellation guide recommends exporting data from third-party apps that users sign in to with Google, and deleting user data in apps you won't keep using.
Check it worked: Each app is either still reachable with a new sign-in or has been exported and closed.
Check your plan's commitment and final charges Do once for 2 changesCancel Google WorkspaceCancel Google Workspacemoderate
Do this: Check your plan type and billing in the Admin console before choosing a date. Verify the provider's current retention/cancellation policy, including any charges for the rest of an annual commitment.
For the other change: Check the next statement or invoice for the final charge, and confirm no further Workspace charges appear.
Why: How and when you're billed after cancelling depends on your plan type and how you bought Google Workspace.
Check it worked: You know the final charge and the date billing stops.
During the change6
Cancel Google Workspace only after everything is validated Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacecritical
Do this: Cancel only after users have signed off, the final export is downloaded, ownership of Google services has moved and nothing new has arrived in Gmail for a couple of weeks. Verify the provider's current retention/cancellation policy before you cancel. Afterwards, watch bounce messages, failed sign-ins and integration errors for a few weeks for anything still pointing at Google.
For the other change: On the date you chose, follow Google's current cancellation steps in the Admin console and save the confirmation. Verify the provider's current retention/cancellation policy before you cancel.
Why: Google's cancellation guide says your users' Google Workspace data will be deleted and can't be restored once you cancel.
Check it worked: The old platform's admin console shows the cancellation, and the final invoice is what you expected.
Update SPF to include Microsoft 365 (one record only)Google Workspace to Microsoft 365high
Do this: Edit your existing SPF TXT record to add include:spf.protection.outlook.com alongside Google's include:_spf.google.com and any other senders. Don't create a second SPF record, and stay within SPF's limit of 10 DNS lookups. Remove Google's include only after nothing sends from Google.
Why: SPF lists the servers allowed to send mail for your domain. A domain should have only one SPF record, and receivers junk or reject mail from servers that aren't listed.
Check it worked: An SPF checker shows one valid record that includes the new provider, and test messages show spf=pass.
Publish Microsoft 365 DKIM records and turn on signingGoogle Workspace to Microsoft 365high
Do this: Copy the two DKIM CNAME records (selector1 and selector2) exactly as shown in the Microsoft Defender portal, publish them, then turn on DKIM signing for the domain. Leave Google's DKIM record in place until Google stops sending.
Why: Microsoft's documentation says no DKIM signing happens for mail from custom domains until you set it up, and DMARC alignment needs your own domain in the signature.
Check it worked: Send a message to an outside mailbox and check the headers show dkim=pass for your domain.
Verify DMARC alignment for mail sent from Microsoft 365Google Workspace to Microsoft 365high
Do this: If you have a DMARC record, keep its policy and confirm mail from the new platform passes SPF or DKIM aligned with your domain. If you don't have one, add one in monitoring mode (p=none) with a reporting address, and tighten it once reports look clean.
Why: DMARC tells receivers what to do with mail that fails SPF and DKIM alignment. A strict policy plus a half-finished setup can get your own mail rejected.
Check it worked: Headers on test messages show dmarc=pass, and DMARC reports show the new platform passing.
Add the Autodiscover record for OutlookGoogle Workspace to Microsoft 365moderate
Do this: Add the Autodiscover CNAME that Microsoft documents for Exchange Online (alias autodiscover, target autodiscover.outlook.com) so Outlook finds Microsoft 365 without manual settings.
Why: Outlook uses an Autodiscover DNS record to find the mail server for an address. Pointing it at the right service avoids confusing setup prompts.
Check it worked: Set up Outlook with a user's address and confirm it finds the right server without manual settings.
Services that send email as your domainGoogle Workspace to Microsoft 365moderate
Do this: Keep each sending service in your SPF record or DKIM setup when you edit records, remove services you no longer use, and check DMARC reports for anything that starts failing.
Why: Website forms, invoicing, CRM and newsletter tools send as your domain and depend on your SPF, DKIM and DMARC records, not on your mailbox provider.
Check it worked: A test message from each service shows SPF or DKIM passing with your domain.
Immediately after5
Set up Outlook, OneDrive and Teams on every computerGoogle Workspace to Microsoft 365high
Do this: Set up each person's Microsoft 365 account in Outlook, OneDrive and Teams. If anyone used Outlook with Google Workspace Sync, create a new Outlook profile rather than reusing the old one. Remove Google Drive for desktop once files are confirmed in OneDrive.
Why: Desktop mail apps and file sync clients are tied to an account, so they need setting up again for the new platform.
Check it worked: Each user sends and receives mail and sees their files syncing on their computer.
Add Microsoft 365 to phones and tabletsGoogle Workspace to Microsoft 365high
Do this: Have each person add their Microsoft 365 account in Outlook (or the built-in mail app), Teams and OneDrive on their phone. Remove the Google work account after validation, once its data is confirmed moved.
Why: Phones keep syncing the old account until someone changes them, and many people read most of their mail on their phone.
Check it worked: Each user receives a test message and a calendar invite on their phone.
Re-create rooms, shared calendars and recurring meeting linksGoogle Workspace to Microsoft 365moderate
Do this: Set up room mailboxes for meeting rooms, re-share team calendars, and ask organizers to re-send important recurring meetings from Outlook so they carry Teams links.
Why: Microsoft's Google Workspace migration documentation says room bookings, shared calendars and event colours aren't migrated. Recurring meetings created in Google Calendar may also keep their Google Meet links.
Check it worked: Book a room and join a recurring meeting from the new calendar.
Update links to Google Drive files, forms and calendarsGoogle Workspace to Microsoft 365moderate
Do this: Search your website, email templates, signatures and key documents for links to the old platform's files and forms, and replace them with links to the new copies.
Why: Files copied to OneDrive and SharePoint get new addresses, and Microsoft's Migration Manager documentation says it doesn't recreate external sharing links.
Check it worked: Open each public link from a private browser window and confirm it reaches the right file.
Give people a short orientation on Outlook, OneDrive and TeamsGoogle Workspace to Microsoft 365low
Do this: Run a short session or share a one-page guide covering mail, calendar invites, where shared files now live, chat and meetings, and how to get help.
Why: Mail, calendar, files and chat work differently between platforms. A short session saves days of support questions.
Check it worked: Ask a few users to find a shared file and book a meeting without help.
Verify3
Send a test to every alias, group and shared addressGoogle Workspace to Microsoft 365high
Do this: Using your inventory, send a message from an outside mailbox to every alias, group and shared address and confirm it arrives where expected.
Why: Each extra address is its own setting. One missed alias or group setting is enough for important mail to bounce.
Check it worked: Every address on the inventory has a successful test noted against it.
Check phones, computers and calendar invitesGoogle Workspace to Microsoft 365high
Do this: With a few users, send an outside calendar invite, accept it on a phone, reply to a message from a computer and open a shared file on both.
Why: Clients can look set up while still syncing the old account, and calendar invites cross between systems in ways that are easy to miss.
Check it worked: Invites, replies and files work on both phone and computer for each tester.
Sign in to every business app with the new methodGoogle Workspace to Microsoft 365high
Do this: In a private browser window, sign in to each business app with the new sign-in method, including admin accounts.
Why: Apps can keep an old session open for days, hiding a broken sign-in until it expires.
Check it worked: Every app on your list has a successful fresh sign-in recorded.
Clean up2
Remove Google mail records and the migration's routing domains Do once for 2 changesGoogle Workspace to Microsoft 365Cancel Google Workspacemoderate
Do this: Once Google no longer sends or receives mail for you, remove any remaining Google MX records, the include:_spf.google.com entry and Google's DKIM record. Microsoft's migration overview says the routing domains and extra aliases can be removed once all batches are complete. Keep google-site-verification records that other services use.
For the other change: Once mail flows elsewhere, remove Google's MX records, the include:_spf.google.com entry and Google's DKIM record. Keep google-site-verification records if Search Console or other services still use them.
Why: Leftover MX, SPF and DKIM entries for a provider you no longer use can confuse delivery and let an unused service keep sending as your domain.
Check it worked: A DNS lookup shows only the new provider's mail records, and test mail still passes SPF, DKIM and DMARC.
Decide whether to keep your organization's Google accountCancel Google Workspacehigh
Do this: Keep the organization's account while you still need Google Cloud, a domain bought through Google, Cloud Identity or other Google subscriptions. Delete it only after those are moved, following Google's current instructions.
Why: Google's cancellation guide says cancelling Workspace doesn't remove user accounts, groups or your organizational structure, and that keeping the organization's Google account lets you manage other subscriptions such as domain registration and Cloud Identity.
Check it worked: You've recorded whether the account is kept or deleted, and why.
Later1
Watch for bounces, password resets and apps still pointing at GoogleCancel Google Workspacelow
Do this: For a few weeks, check bounce messages, failed sign-ins and integration errors, and ask staff to report anything that still mentions the old platform.
Why: Forgotten integrations and addresses usually reveal themselves only when they fail.
Check it worked: Nothing new has turned up for two weeks.