Google Workspace to Microsoft 365: what actually breaks
Most of a Google Workspace to Microsoft 365 migration is boring, which is how it should be. Mail copies across, calendars come with it, files land in OneDrive and SharePoint, and on Monday morning people log in and get on with their day.
The interesting part is the handful of things that don't map cleanly between the two platforms. None of them are disasters if you know about them beforehand. All of them are irritating if you find out on Monday.
Here's what actually catches people out.
Gmail labels don't survive as labels
This is the big one, and almost nobody thinks about it until afterwards.
In Gmail, a message can carry five labels at once. It's one message, filed in five places. Outlook has folders, and a message sits in exactly one of them.
So when the migration runs, something has to give. A message with five labels either gets copied into five folders, and now you have five copies of it, or it picks one and the other four filings are lost. Different tools handle it differently, and the default is rarely what you'd have chosen.
Worth deciding in advance which labels actually matter. Most businesses have three or four that get used and a long tail nobody has touched since 2019.
"Shared with me" has no equivalent
Google Drive's "Shared with me" isn't a folder. It's a view of everything anyone has ever shared with you, and none of it lives in your Drive.
Microsoft doesn't have that concept in the same shape. Files somebody shared with you from their OneDrive stay in their OneDrive. If a document your whole team relies on is sitting in a departed employee's Drive and reaching everyone through "Shared with me", the migration will not bring it across, because it isn't yours.
Find those before you move. There's usually at least one spreadsheet the entire business depends on that turns out to belong to someone who left.
Shared Drives and SharePoint disagree about permissions
Google Shared Drives and SharePoint document libraries do roughly the same job, but their permission models aren't the same shape. Google has five access levels on a Shared Drive. SharePoint has inheritance, unique permissions per folder, and sharing links with their own settings.
A straight copy moves the files. Getting the permissions right is a separate piece of work, and it's the part worth spending time on, because "everyone can see the payroll folder" is a bad way to start a Monday.
Google Docs stop being Google Docs
Native Docs, Sheets and Slides aren't files in the normal sense. They convert to Word, Excel and PowerPoint on the way across.
Simple documents convert perfectly. Complicated spreadsheets do not always. Anything with Apps Script behind it stops working entirely, because Apps Script doesn't exist in Microsoft's world. If someone in your business has built a quoting sheet with scripts in it, that's a rebuild, not a migration, and it's better to know that a month out.
Recurring meetings get strange
Calendars move fine. Recurring meetings mostly move fine. The ones that break are the awkward ones: a fortnightly meeting with three exceptions where somebody moved one instance to a Thursday, and one where the room changed.
Room and resource bookings need setting up on the Microsoft side separately. They don't come across on their own.
Third-party apps stay pointed at Google
Everything that authenticates through "Sign in with Google" is still doing that after the migration. Your CRM, your accounting package, whatever sends your invoices out.
Those don't break at cutover, which is the trap. They break later, when the Google account eventually gets shut down and nobody has connected the dots. Make a list before you start.
Most of the move happens before the weekend
The instinct is that a migration is a weekend job. The copying isn't the hard part, and it isn't what the weekend is for.
For a small business we set Microsoft 365 up first, and everyone logs in while they're still working in Google. The mailbox opens, Teams works, OneDrive is there. Anything that's going to be wrong with an account gets found on a Tuesday afternoon, not at eleven on a Saturday night.
Then the data gets pre-staged. Everything older than ninety days is copied across ahead of time, while nobody notices, because nobody is touching mail from March. By the time the weekend comes, the bulk of it is already sitting in Microsoft and has been for days.
The weekend is the last ninety days and the DNS
What's left is the recent mail, the recent files, and moving mail flow itself.
Mail flow has to move from Google to Microsoft, which means changing MX records and waiting for the internet to catch up. During that window some mail arrives at the old place and some at the new one.
Done properly this is invisible. Both sides stay live, mail gets collected from both, and nothing is lost. Done badly, a few hours of enquiries land in a mailbox nobody looks at again.
This is why the cutover runs Friday night through Sunday. Not because there's a lot left to copy, but because the quiet period is when a cutover can go wrong without anyone missing anything important.
What to do about all of it
Every one of these is manageable if it's on the list before you start. The pattern is always the same: the migration itself is mechanical, and the problems live in the things that were never quite standard in the first place.
So before anyone touches anything, work out:
- which labels people actually use
- what's living in "Shared with me" that shouldn't be
- which spreadsheets have scripts behind them
- what signs in with Google
- who owns the files that matter
That list takes an hour to put together and saves the awkward conversation afterwards.
If you're weighing up a move and want a straight answer on what's involved for your business, tell us how many people you have and which way you're heading. We'll tell you what it takes and whether it's worth doing.