The world of cloud services has never been so competitive as it is today. Office 365 clearly is the big driver nowadays in cloud adoption, but that has not always been the case. Google Apps, now called Google Suite was way earlier on the market with a viable cloud service than Microsoft. You still going to see a lot of large enterprises who have their first cloud footprint on Google. The adoption of Google Apps/Suite was very similar to the adoption of Office 365. Mailboxes were a no-brainer, later Google Drive followed, Google Hangouts, etc.
So one of the features Google Suite offers you, like in Office 365 is resources. However that is where all comparison stops. In Office 365 all the resources get an email address within the vanity domain you chose to use. E.g. email@example.com or firstname.lastname@example.org .. All nice and clean. However when we look into the Google Suite side of things, that is a whole different thing. For some inexplicable reason Google creates an entity within its own domain @resource.calendar.google.com, and not in your own vanity domain. When we look at the structure you can extrapolate that all resources will look like this:
<vanity domain>_<hash/unique identifier>@resource.calendar.google.com
which results in: email@example.com
When you use the Google Calendar and setup a meeting, you won’t even see that smtp address. You get the user friendly name in the rooms list. So why do we care? Well, one thing that cloud services have done to the industry is turning it into a competitive market. Mailboxes size increases, price drops, new features, etc are some of the incentives that all cloud service providers offer to their customers. Currently Office 365 is clearly leading but even so, when companies decide to move from Google Suite to Office 365, they are not doing a ‘start blank’ scenario. They want their new setup as best as possible to match their current setup. So in case of resources, new resources are created on Office 365 and data has to be migrated.
And here is where the issues start. Lets assume that we just migrate all the date from the resource within Google to Office 365. Calendar items within the resource would have firstname.lastname@example.org in their invite list, same goes for people using the resource in their calendar items. So when a calendar item is updated, the updated version will not go the new Office 365 resource but will be redirected to the Google Resource domain. This means that updates are not going through in the resource mailbox. Big deal? Well if your resources are used frequently and you cherish the correctness of their availability, I would say so.
So what is the solution? We know that coming from Google the Microsoft migration tools are not that great. Even Fast Track, the migration service of Microsoft does not cover resources for this specific reason. So, when you have a customer or you are the customer who is thinking about doing Google Suite to Office 365 mailboxes, make sure you ask about resources. If they are a part of the scope know that you will need a migration tool that is capable of doing recipient mapping, this means that the tool will take e.g. email@example.com and translate it into firstname.lastname@example.org . This is the only way to cover for this.
I am not going to tell you which tool to use but bases on my experience, I go MigrationWiz every single time.