What is the best practice for migrating from Google Workspace to Microsoft Azure AD for IdP?

[Michael Hotchkiss]

Our organization is migrating from Google Workspace to Microsoft 365. We would like to change our identity provider to Microsoft without losing any user data. All users have the same email addresses. We do not have enterprise, so we can only have one provider at a time.

[Ed Letifov _TechTime - New Zealand_]

Hello, @Michael Hotchkiss 

1) I know you did say that the emails are not changing – however, please note, if they or names are — either during migration or in some time after you've moved Atlassian Cloud to EntraID while Google Workspace instance still stays running  – you really should raise a ticket with Atlassian support and have them clear "SAML ID" from the accounts during cut-over to avoid issues.

Apparently, if the user triggers the IdP-initiated SSO, from the IDP that matches the ID stored in the SAML ID attribute, the data from the SAMLLoginResponse message is used by Atlassian to update/override Atlassian Cloud data. So if this this not cleared and someone somehow still comes via Google – this can cause problems.

We have stepped into this with one of our customers before.

2) Unrelated to Google Workspace migration:

My personal preference for Azure AD is to avoid the option to "automatically setup user provisioning" (which is required for nested groups).

And in the manual setup of the SCIM i.e. the one described in these documents:

• https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/
• https://learn.microsoft.com/en-us/entra/identity/saas-apps/atlassian-cloud-provisioning-tutorial

I always suggest that in step 5.10 of the guide you need to make sure your "matching" attribute is ObjectID, not UPN – since names, UPNs, and emails all can change in enterprise operational scenarios.

Also see this answer for how is best (obviously, this is an opinion) to setup the EntraID app(s) integrating Atlassian Cloud with EntraID for SSO and User Provisioning: https://community.atlassian.com/forums/Questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaa-p/1862549#M743 

[Ahmed Masoud]

Yeah this is actually pretty straightforward since you're keeping the same email addresses. The key thing is you can't run both IdPs at once without Enterprise, so you'll need to plan the cutover carefully.

Create all your users in Entra ID (Azure AD) first but don't cut over authentication yet. Make sure UPNs match their Google email addresses exactly. Then sync your data (email, Drive, etc.) using the native Microsoft migration tools while Google is still the active IdP.

Once everything's migrated and you've verified users can access their M365 data, you flip the SSO configuration in your connected apps from Google to Microsoft.

This is the risky part - you'll want a maintenance window and a list of every app using Google SSO beforehand.

The actual user accounts and their data in M365 stay intact during the IdP switch since you're matching on email address.

Just make sure passwords are synced or users know their new Microsoft creds before you cut over.

We walk through the whole migration process including the IdP piece in our guide here and video here.

[Robert DaSilva]

Hey @Michael Hotchkiss , my understanding here is that this shouldn't be too challenging, but will require a few steps to occur in a specific order.

In your current state, you've got your Google Workspace configured as your identity provider. I'm assuming you also have SCIM enabled, such that new users on Google Workspace get new Atlassian Accounts configured automatically.

The good news is that all of your users have Atlassian Accounts already, they are just being forced through Single Sign On via Google Workspace, instead of using an Atlassian Account specific password.

Here are some assumptions I am making that you'll want to double confirm:

• You currently have SCIM enabled, such that any new user in Google Workspace syncs with Atlassian automatically, and has a new Atlassian Account created for them.
• The email address for every user is the same on Google Workspace and Office 365.
• The unique id for each user is their email address or prefix, and is the same across both Google Workspace and Office 365.
• You have a user account which has Organization Administrator privileges, that is NOT part of your Identity Provider configuration

Here's what you'll need to do:

1. Ensure your email domain is claimed and verified. This should already be the case due to the existing SSO configuration.
2. Export a list of your Claimed and Managed users, so that you have a record of which accounts you have claimed and managed, ideally for use later.
3. Disconnect your Google Workspace identity provider. This should release all of your user accounts from Single Sign On, but may not release them from being Managed. This won't be an issue, once Office 365 is connected, you can connect them back into SSO.
4. Connect your Microsoft 365 identity provider, and configure SSO as required.
5. Re-claim all accounts you previously had claimed. This likely will happen automatically once the IdP is connected, and the user list syncs.

If you do this quick enough, and ideally on off-hours, you can likely avoid a lot of confusion from your users with how they sign in.

Here are some documents and other Community threads I encourage you to read just to get your head around the process:

• https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/
• https://community.atlassian.com/forums/Articles/How-To-Atlassian-Access-Configure-User-Provisioning-with-a-Third/ba-p/1949871
• https://community.atlassian.com/forums/Questions/Switching-SAML-Identity-Providers/qaq-p/1096453
• https://community.atlassian.com/forums/Atlassian-Account-articles/Migrating-from-G-Suite-to-other-Identity-Providers-Okta-Azure-AD/ba-p/1275211

Hope this is helpful! You can always reach out to Atlassian Support directly via support.atlassian.com if you run into any specific issues.

The biggest takeaway I have though: Keep at least one account completely disconnected from your Identity Provider for the migration. Ideally, use a completely different domain (like a free gmail.com email account) to ensure you maintain administrative access if something does go wrong. Once you verify everything is working properly, you can remove that accounts access, but it's a great safety net to have.

Cheers,

Robert