Moving from Google Workspace to Microsoft 365: what the process really looks like
We moved our own email from Google Workspace to Microsoft 365. Copying the mailbox was the easy part. Addresses, domains stuck in old tenants and the final checks took longer.
We recently moved our own email from Google Workspace to Microsoft 365. On paper it is three steps: set up the new platform, copy the mailbox, change a few DNS records. In practice the copy was the easy part. The addresses, the domain ownership and the checking afterwards took longer.
The main thing we learned is that a finished mailbox transfer and a finished migration are different milestones. Our historical mail was sitting in Exchange Online while other domains and addresses still needed work, which is why we kept Google Workspace running for an extra month.
Here is how the move went, and where it is worth slowing down.
Start with what you already have
Before setting up Microsoft 365, work out exactly what Google Workspace is doing for you. The main mailbox is usually obvious. Aliases, groups and addresses used by websites, billing systems or security notifications are easier to overlook.
Each address needs a destination. Some belong on an existing mailbox as aliases; others may suit a shared mailbox or group. An alias is just another address delivering into a mailbox, so it does not need its own historical mail transfer. It does need to exist at the destination before mail delivery switches.
Put calendars, contacts, Drive files and applications that use Google sign-in on the same list. Moving email does not move every service attached to the account. Export anything important and check that the export actually opens before you retire the source.
Prepare the destination before switching delivery
The Microsoft groundwork is creating the tenant, securing administrator access with multifactor authentication, choosing licences and provisioning destination users to suit the migration method.
Custom domains also need to be added and verified. That is separate from directing incoming email to Microsoft: proving ownership does not require an MX change. Keeping the two apart gives you time to prepare recipients and copy data while mail keeps arriving at Google.
This is where we hit something we had not planned for: domains already attached to another Microsoft tenant.
Your domain may have a history
Owning a domain and controlling its DNS does not necessarily mean you can add it to your current Microsoft 365 organisation. An earlier setup may have left it verified in another tenant.
We ran into both versions of that problem. For one domain, we recovered access to the previous tenant, released the domain and finished the move. Another was attached to a tenant we could not get into, so we raised a Microsoft support request. At the time of writing, that one is still waiting on Microsoft.
Check domain availability early. If you administer the old tenant, follow Microsoft’s process for resolving dependencies and removing the domain. If you cannot access it, contact support rather than assuming another DNS change will release it. Microsoft’s domain removal guidance covers the dependencies, and its guidance for domains in another account explains the difference between managed and unmanaged situations. Tenant takeover does not apply to every case.
Copy the data, then read the report
The Exchange admin center has a Google Workspace migration workflow. Preparation covers Google permissions, the migration connection, routing configuration and destination recipients. Microsoft’s prerequisites and automated migration instructions are worth keeping open during setup.
For a larger move, migrate one pilot mailbox first and check the result before doing everyone else. The tool handles mail, calendars, contacts and rules, with some documented limitations. Drive and shared drive content need their own plan for destinations, ownership and permissions.
Our batch reported completion with a good data consistency result, and also one skipped item. Read the report rather than stopping at the completion badge. Skipped or failed items need looking at before you can say all the data is accounted for.
The cutover needs more than an MX change
Once recipients and data are ready, changing the MX records sends new mail to Microsoft 365. Use the MX and Autodiscover values Microsoft gives you. Review SPF so it covers every legitimate sending service, turn on Microsoft 365 DKIM and check DMARC alignment. Do not leave two SPF records in place during the changeover.
Follow the migration workflow’s documented order for the final sync and completion. Then test what people actually use: incoming and outgoing external mail, replies, aliases, groups, calendar invitations, phones and messages sent by applications. A green domain status in the admin centre is not the same as having tested the addresses people depend on.
Leave time before retiring Google
It is tempting to cancel Google Workspace as soon as Outlook works. We kept it for another month while we finished the remaining domain work and looked for anything left behind.
That overlap is a checking period, not a backup. Before you cancel, confirm the data you need has been migrated or exported, the exports are usable, and nothing important still depends on Workspace. Google’s cancellation guidance sets out what happens to your data and billing.
The mailbox transfer is a milestone, not the finish line. The move is done when the addresses, the retained data and the everyday workflows have all been checked.