Collaboration features to support migrations
Microsoft 365 multi-tenant organizations (MTO) attained general availability in 2024. The solution targets organizations that manage and collaborate across multiple Microsoft 365 tenants. The core purpose of MTOs is to remove barriers to collaboration between tenants. For some organizations, MTOs are a much-needed feature, but for many, hosting multiple tenants isn’t needed or wanted.
For example, an organization that acquires multiple other tenants through mergers or acquisitions will often want to centralize to a single tenant. This approach ensures the same security policies, tools, and features are available to everyone while reducing the administrative burden of managing multiple tenants, so it seems like an MTO is not needed. However, MTOs enhance collaboration before the migration happens and can help with the transition of user identities from one tenant to another. In this article, I explore how MTOs can help make tenant-to-tenant migrations a smoother process for both administrators and end users.
Quick Wins
In small organizations, tenant-to-tenant migrations are achievable using a single migration cutover or “big bang” approach. In larger or more complex organizations, it’s usually impossible to migrate users in a single movement, and the migration is phased out over several batches. The transition period, while batches are migrated, can often last for weeks or months, depending on the size or complexity of the environment. MTOs provide some quick wins to help make the migration process more seamless for end users:
- Synchronize users between tenants: Use cross-tenant synchronization to provision users across tenants as external members
- Global Address List Synchronization: Use cross-tenant synchronization to provide a unified Global Address List for Exchange Online and Teams
- Mail forwarding: Mails sent to the external member will be automatically forwarded to their source mailbox
- Access to Shared Channels: Access Teams Shared Channels across tenant boundaries
- Free/Busy Sharing: Automatically enable Free/Busy calendar sharing
Read More: To learn more about configuring Multi-tenant organizations, check out this article
Opportunities with External User Conversion
The initial configuration of an MTO is explained in a previous article, so I won’t cover that here. One of the key pieces of the MTO architecture to consider as part of a tenant migration is the cross-tenant synchronization functionality. While cross-tenant synchronization doesn’t require an MTO (cross-tenant synchronization can be configured separately), it works well as part of the overall MTO solution.
When you configure cross-tenant synchronization, in-scope users are provisioned into the target tenant as external member accounts (Figure 1). This is different from inviting user accounts from other tenants to join a tenant as Guest accounts.
A relatively new feature of cross-tenant synchronization (released to preview in January 2025) is the ability to convert these “external” members into fully fledged internal member accounts. This conversion process brings additional benefits during a tenant-to-tenant migration project, allowing tenant administrators to take external accounts into their tenant while maintaining the group membership and Object identifier for the external account. Maintaining the core of a user’s identity (their immutable object identifier) means that any Teams, Groups, or other apps based on Entra ID groups where external users are members are treated in the same manner as an internal user.
Converting an External Account
The conversion process for an external user account is simple. From the account page in the Microsoft Entra admin center, select the Convert to internal user option as shown in Figure 2. The conversion process requires you to specify a new User Principal Name and password for the account so the user can sign-in after conversion.
Conversion is also supported through the Graph API and Graph PowerShell SDK with the cmdlet Convert-MgBetaUserExternalToInternalMemberUser as shown below:
Connect-MgGraph -Scopes "user.readwrite.all" -NoWelcome
$User = get-mguser -UserId <UserPrincipalName>
$NewUPN = “<New UPN>”
$NewPassword = "<New Password>"
$params = @{
userPrincipalName = $NewUPN
passwordProfile = @{
password = $NewPassword
forceChangePasswordNextSignIn = "true"
}
}
Convert-MgBetaUserExternalToInternalMemberUser -UserId $user.Id -Body $params
After Conversion
When the conversion is complete, the user account becomes a standard internal member. Critically for migration scenarios, the migrated account maintains its group memberships and Object ID (Figure 3).
By assigning the account a license after conversion the user can then sign in and access the same Teams / sites / groups that they had access to as an external user.
Considerations
Converting external identities is useful in tenant-to-tenant scenarios but there are some considerations to keep in mind:
In many tenant-to-tenant migration scenarios, the project team will pre-synchronize data to the target account to support a quicker migration process. This involves licensing the user account in the target tenant to create a mailbox, OneDrive account etc.
Unfortunately, licensing the external user in the target tenant before converting to an internal user doesn’t work for prestaging data. While the account is partially set up, it is left in a mixed state which isn’t supported by the standard migration vendors (at least not yet). This means that pre-syncing data for users created using MTOs and cross-tenant synchronization can’t happen until the account is converted. For user accounts with large amounts of data, not syncing data ahead of time can lead to lengthy cutover windows.
Conclusion
Multi-tenant Organizations are useful in tenant migration scenarios and can fit into an overall migration strategy quite well. It’s important to be aware of the limitations around data syncing as lengthy sync windows can often cause major issues during cutovers.
Prestaging of data isn’t really what cross-tenant synchronization is designed for, so this limitation is understandable, particularly in the early days of the feature. As with any component of a tenant-to-tenant migration, detailed planning is needed to incorporate the different tools available and design the right migration path for your organization.
