I am often involved in scenarios where the IAM architecture is being modernized because of a transition to a hybrid or full Public Cloud model. Particularly during organizational merges or acquisitions, questions arises whether tenants should be merged or not. In addition, some organizations consider whether or not to subdivide business units or departments into separate tenants.

In this post I will explain most of the considerations to take in account before deciding to follow the single or multiple tenant path. Keep in mind that this implies a business decision, which will have a major impact on user experience and identity management, and therefore should be considered with care.

In fact, I have a first solid advice for you:

Always aim to use a single tenant, unless there is no other way around.

Already convinced? Stop reading :-). Not really convinced yet, or just curious why? Then keep reading!

Common reasons for having multiple tenants

Okay you’re still with my so I assume you would like to know more about the multiple tenant approach, right?

Let us first kick-off with the multiple tenant approach. These are a few common scenarios that I came across from my experience:

  • “We require to maintain administrative autonomy of each business unit.”
  • “Our business units are using different licensing providers across the globe.”
  • “We have a business strategy that may require to easily detach a division from our organization in the future.”
  • “Each division across the glove must have its data stored in a local datacenter region.”
  • “We require a tenant-wide setting which significantly differs from the primary tenant.”

Have you noticed the words in bold? Most of these are related to organizational, licensing or compliance arguments.
Honestly, I won’t deny that some of these challenges can be solved by introducing multiple tenants, however, keep in mind that there could be alternative solutions.

In example, when the organization requires the data to be stored in a regional datacenter, it can leverage the Multi-Geo capabilities of Office 365. However, this is currently limited to a few geo regions and it’ll require a tenant with a minimum of 2500 Office 365 licenses – mind you.


Before exampling the technical considerations, let’s first understand the basics of identity management in the (Microsoft) Public Cloud. Whether you are provisioning users via synchronization (i.e. via AAD Connect) or just creating them as Cloud-only, please remember there’s always one basic rule of thumb:

The foundation of each Cloud solution (like the Office 365 suite) is identity.
In fact, identity is the new control plane.

It’s centered between data, people and devices, and provides control over security, costs and productivity.
It provides a login to each user and controls role based access to (Cloud) applications and services.

Identity is the new control plane
Identity is the new control plane

Azure AD is a Microsoft’s service for delivering directory services and access management. A directory is also known as a tenant. Keep in mind that an Office 365 tenant is the same thing as an Azure AD tenant, since both terms are often used interchangeably on the internet.

To learn more about Azure AD fundamentals I recommend to read the following webpage:

Technical considerations

Before diving into the numerous considerations, make sure you understand that inter-tenant users are always treated as B2B guests. Since a B2B guest is “not really” a full user, but a reference object, there will be limitations in user experience and capabilities when the user collaborates cross-tenant.

That being said, below you will find the most common detailed facts:

Identity synchronization

  • You cannot synchronize a single (on-prem AD) identity object to multiple tenants using a supported method, with AAD Connect.
  • Each user is member of only one tenant and is considered as a B2B Guest “object” in any other tenant (after being invited).
  • Azure AD only supports one AAD Connect instance per tenant. If you have multiple AD forests to sync, you will need to authorize the AAD Connect server across all of the forests. To learn more about the supported topologies, I highly recommend to read and understand the following webpage: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies.

Domains and DNS

  • A common misconception about domains: “I need multiple tenants because we use multiple public DNS domains”. Fortunately that’s not true. You can add and manage multiple domains (up to 900) in a single tenant.
  • In case of having multiple tenants, you can use subdomains to divide your public domain across multiple tenants. For example: europe.domain.com, northamerica.domain.com etc.


  • Exchange Hybrid only supports single tenancy scenarios. You can only select one tenant which will benefit from all of the hybrid features. Every other tenant will not.
  • Each tenant maintains its own GAL.
  • In case of having multiple tenants:
    • You will need to sync the GALs which can be straightforward, however it still has implications on mail flow.
    • Out-of-office external replies will be triggered on users from another tenant.
    • Each public DNS domain can only be assigned to a single tenant. If users in different tenants need to send mail through the same (shared) public domain, you will have to route the mail through the on-prem Exchange Hybrid farm.
    • Public folders and shared mailboxes cannot be shared across tenants, and would need forwarding rules as a workaround.
    • Users cannot book a meeting room or resource across tenants.

OneDrive and SharePoint

In case of having multiple tenants:

  • External guest access needs to be enabled at tenant level and each site collection.
  • Sharing between users which are spread across tenants is treated the same as external guests. This may confuse users when they use security features like “Share with everyone except external users“.
  • SharePoint Search and Term Store resides within the tenant itself. There is no way to search across tenants. The same goes for Delve and Microsoft Search.
  • Each tenant holds one main site collection which cannot be set as default for all other tenants which will require users to save URLs.
  • Users from another tenant can only be added to an Office 365 Group using Outlook Web App, instead of SharePoint itself


In case of having multiple tenants:

  • Users will have to switch between tenants when collaborating with users from another tenant. A user cannot chat with multiple users which are spread across tenants at the same time.
  • Presence of users can be interrupted because of the switching between tenants.
  • Teams search will not integrate across tenants.
  • Full overview of guest limitations: https://docs.microsoft.com/en-us/microsoftteams/guest-experience

Other Office 365 services

In case of having multiple tenants:

  • Forms: by default only users within the same tenant can answer forms. The form needs to be public to be shared across tenants.
  • Flow: users from another tenant needs to be invited as guest users in able to control a flow.
  • PowerApps: users from another tenant do not have access, however, this feature will be introduced by the end of the current fiscal year at Microsoft.
  • Office 365 Groups: cannot be discovered by users across tenants.


There are numerous reasons to be required to merge tenants. In this scenario it’s important to know and evaluate which workloads are being used at each individual tenant. Logically, the most easy path is to migrate the tenant which has the least amount of workload, for example only uses Exchange Online. The more workloads it contains, the more complex your migration journey will look like.

Final thoughts

Despite the future changes in Office 365 and Azure AD, keep in mind that the user experience with multiple tenants will always be degraded in comparison with a single tenant approach since cross-tenant users are treated as external B2B guests.

In my opinion, each and every organization should always consider to implement and maintain a single tenant, unless there is a strong argument as mentioned above. Finally it all comes down to a trade-off between user experience and business separation.

I hope this was informative for you and it will support your approach in modernizing your (Cloud) identity management. If you have any questions or thoughts regarding to my blogpost, please feel free to drop a comment.

Thanks for reading!