Google Workspace ↔ M365: Mail coexistence during staged migration

Posted by AshMost@reddit | sysadmin | View on Reddit | 12 comments

Hi fellahs!

I'm in the preparation phase of migrating a couple thousand users from Google Workspace to Microsoft 365. Unfortunately, some of the domains have several thousands of users, making a clean cutover migration ill-advised.

I'm therefore looking at a staged migration, meaning that I'd need to set up coexistence.

Google Workspace

First of all, I'm thinking that mail ingress will be through GWS (MX points to GWS). All email addresses would then be given a new email alias, like xxx@gws.contoso.com, and gws.contoso.com MX record would point to GWS.

Here's where I get some choices, with split delivery:

I could set up delivery to Microsoft 365 based on group membership. Meaning that emails sent to a user that's a member of the "Users migrated to M365" group, will be rerouted to M365. From my understanding this would affect aliases/proxy addresses of the users as well.
I could also set up delivery to Microsoft 365 based on address lists. Just throw all email addresses that should be homed in M365 into the list, and emails sent to those email addresses will be rerouted to M365.
Unrecognized / catch all: This would be routed to M365 as well. That means that I can set up new email addresses in M365, without having to create them in Google Workspace as well.

I'm leaning towards using a group based route for users, and an address list based route for groups. The reason is that groups are more complex, in that they can have nested groups.

Microsoft 365

Here I'm going off Microsoft's recommended method. They recommend using MailUsers for all users that have not been migrated, and for the domains to be set to Authoritative.
The way MailUsers work is that they have usernames and aliases, but they also have a "External email address" property. In this "External email address" property, that user's gws.contoso.com-alias is definied.

If a migrated user sends an email from Microsoft 365 to an unmigrated user, EXO would check the external email address property (xxx@gws.contoso.com", and send the email to that address based on the subdomain's MX record (which points to GWS).

When you migrate the user to M365, you add a license to the MailUser, and convert it to an ordinary mailbox.

Questions

Any glaring flaws here?
Am I overcomplicating the M365 setup? It's according to MS's recommendation, but I don't see why I couldn't just create a "Users not migrated to M365" security group and have those emails be forwarded to GWS, using Transport rules?

Resources

Any help is much appreciated!

[-]

saltyslugga@reddit

your plan is solid and pretty close to what i've seen work. a few thoughts:

mx at gws with a routing subdomain (gws.contoso.com) and mailusers in exo is the cleanest pattern, don't fight microsoft's recommendation here. transport rules with a "not migrated" group works in theory but you lose proper recipient resolution, NDRs get weird for unknown addresses, and you can't easily have m365-only addresses without also creating them in gws. mailusers handle all of that natively.

on the google side, the reason their docs say "one or the other, not both" is that if an address exists in both systems, gws will deliver locally and never forward, so the split delivery rule never fires. as long as you suspend or remove the address in gws post-migration you're fine.

one thing to test early: autodiscover/free-busy and calendar federation between the two during coexistence, that's usually where the pain shows up, not mail flow itself.

avan199@reddit

Hi, I have also done similar staged migrations, and you are on the right track. The biggest issue in staged migration is that Microsoft 365 is authoritative for the domain. MailUsers are there because transport rules alone won't cut it.

It is good that you are keeping GWS as MX + split delivery. Just watch out for edge cases - aliases and nested groups often tend to break.

Also, the guidance about users being in one system only is more about avoiding conflicts than routing. The right move is suspending users' posts after migration.

My advice is to test mail flow in all directions (especially cross-platform and calendar invites).

Frothyleet@reddit

Am I overcomplicating the M365 setup? It's according to MS's recommendation, but I don't see why I couldn't just create a "Users not migrated to M365" security group and have those emails be forwarded to GWS, using Transport rules?

So this could have changed or have a workaround, but the answer to this question the last time I interacted with it is that Exchange, by design, isn't going to forward emails externally if Exchange believes it is authoritative for the recipient domain. To my knowledge, the only sane workaround is to use the MailUser function you describe above.

AshMost@reddit (OP)

Yes, that was a primary concern when I was planning for the coexistence. I'm unsure, however, if transport rules would override this behavior. Some former colleagues just told me "Just use transport rules", but I'm not sure how well that'd work.

I guess you can always test the functionality with a demo subdomain or something.

Yeah, that's true. I have a dev tenant, and I could set up a 14 day GWS trial. I was just hoping that someone had some real life experience of the scenario.

Healthy_Holiday_738@reddit

I just used Atera during a similar migration and it made it way easier to troubleshoot split delivery issues on the fly.

Altruistic-Meal6846@reddit

i just used Atera during a similar migration and it made it way easier to troubleshoot split delivery issues on the fly.

WallaceFred@reddit

If you need some help with this, either planning or on migration day, let me know. I’d be glad to help.

FruitReasonable949@reddit

Your approach aligns well with Microsoft's recommendations and should work effectively. Using group-based routing for users and address lists for groups is a practical way to handle nested groups. Transport rules with a security group could simplify the setup but might lack some flexibility compared to MailUsers with external addresses.

ITGuyThrow07@reddit

I can't really follow what you're asking, but I can say that I followed Microsoft's instructions for a much smaller migration and it worked perfectly. I tested mail flow in every direction possible at each step and everything worked the way it should. I would say to just try to keep at as simple as possible.

My experience was a few years ago, but MS is very motivated to get you to use their product, so I imagine the instructions will still be good.

Sorry, the scenario is a bit complex and hard to put into words.

Ideally, I'd want to follow MS documentation as well. There are two issues:

Microsoft doesn't say much about what you're supposed to do on the GWS side of things. With Split Delivery, I don't even see the need to create a "m365.contoso.com" routing domain.
All users will be synced from AD through Entra Connect. According to Microsoft's documentation, the Entra Connect needs to be disconnected for the tool to be able to convert MailUsers to mailboxes. I do not want to disconnect Entra Connect.