Have you been tasked with migrating your Google Workspace organization to Microsoft 365? A quick search will produce dozens of tools and guidance to get you started. Unfortunately, migrating deeply-entrenched collaborative environments like Google Workspace is often not an easy task, and even well-seasoned admins find themselves caught off guard mid-migration when they trust the marketing.
Here I’ll cover five hidden considerations of Google Workspace to Microsoft 365 migration.
1. Collaborative Drive Permissions
Lots of tools will market their ability to migrate Google Drive and Google Shared Drive permissions. The vendor may make documentation available before you buy, and they may promise 24-hour support. This is all well and good, but are you willing to put your career on the line without a test drive? I wouldn’t! I highly recommend blocking out your day, putting on a pot of coffee, and performing a deep-dive into any migration tool you plan on using for document migration.
Google Drive and Microsoft SharePoint/OneDrive are designed differently and therefore handle permissions differently. Google has more flexible collaboration features available by default, which can lead to scenarios that work naturally at the source but do not necessarily translate well (or at all) to the target. Migration tools must handle these scenarios somehow, and it is important to understand how your SharePoint/OneDrive permissions will look after. One-to-one share permissions are generally handled easily by most tools, but I highly recommend a detailed pilot of anything more complex than that.
2. Domain Aliases
Google Workspace has the concept of Domain Aliases and Microsoft 365 does not. If you are utilizing Domain Aliases at Google and those alias email addresses are important to you, you will have to manually add all those alias email addresses to each migrated mailbox and group. For organizations that utilize multiple Domain Aliases this can quickly add up to thousands of alias email addresses, so get ready to break out Excel and brush up on remote PowerShell to import them into Exchange Online.
3. Group Settings & Posts
Google pioneered the concept of the collaborative group. Microsoft was quick to copy the concept, releasing Unified Groups (a.k.a. Microsoft 365 Groups) as a platform for Microsoft Teams. Unfortunately, the two platforms are built differently enough that an intimate understanding of both environments (and a creative interpretation of several permissions) will be required to map Google Group settings to Unified Groups/Teams.
I am not aware of any tools that take group settings (post settings, mail flow, etc.) into consideration, so those are up to the admin to migrate manually. Some tools handle owner/member permissions, but they are handled as part of membership migration and usually require significant cleanup and translation efforts of their own. I highly suggest assessing your environment for important group features well in advance so you can identify which settings and permissions may require special attention. For these reasons many organizations opt to start over from scratch with groups and Teams.
In addition, as of the writing of this article, only one tool offers Google Group post history migration due to Google API limitations. The task is a slow, manual process performed by the vendor (not the customer) which requires expensive consultation hours. Plan in advance if you require Google Group post history to be migrated, and plan for multiple limitations compared to traditional workloads like mail and documents.
4. Forms
As of the writing of this article there is simply no migration path from Google Forms to Microsoft Forms. The raw data can of course be exported/imported in multiple formats, but the web forms used by end-users to submit data cannot be migrated. If Google Forms are mission-critical, get ahead of this and start rebuilding them as Microsoft Forms in advance.
5. Third-party Integrations & Customizations
SaaS solutions like Google Workspace and Microsoft 365 provide organizations with scalable and economical software suites for enhancing the productivity of end-users. Once a productivity suite has been deployed, the natural next step is to seamlessly add third-party apps and protocols into the mix. Migrating these integrations from Google Workspace to Microsoft 365 may not be as easy.
It’s common for the established SMB to have SSO, MFA, MDM, SIEM, filtering, archiving, and CRM integrations at minimum. Organizations with an open, agile approach to infrastructure often end up with significant “app sprawl” and “shadow IT” to sniff out before they can move forward. Proprietary code and apps that write custom data (document metadata, Google Apps Script, calendar apps, etc.) will likely not be supported at Microsoft 365 at all, but your staff may depend on them for their day-to-day. All of these must be handled in an ad-hoc manner, with their own planning on parallel timelines. I suggest allocating resources in your migration plan for a full audit of such items.
Final Thoughts
Not all organizations will have the above considerations, but don’t be caught by surprise! When in doubt, navigate through all the links in the admin portal and read the guide to figure out what everything means so nothing gets left behind on cutover day. Planning ahead and testing your migration tools will go a long way to ensuring a smooth transition for end-users.
Are you considering helping your organization with Google Workspace to Microsoft 365 migration? Our experienced consultants would love an opportunity to assist with any aspect of the process, from hands-off consultations to turn-key, fixed-cost projects. Contact us today to discuss your project goals.
By: Chris King, Director of Migration Services
