When a deal closes, leadership wants one company by Monday. Employees from both sides should be able to find each other, email each other, meet, share files, and use the same core applications. In the Microsoft world, that request usually lands on the identity team as "merge the tenants."
Merging tenants is a migration project that touches every user, mailbox, file, device, application registration, and Azure subscription in the acquired organization. Done in a hurry, it causes outages, security gaps, and a long tail of broken integrations nobody remembers until they fail. Done carefully, it takes months. Meanwhile, the business still wants people working together on Monday.
The way out is to separate the two problems. Day 1 needs collaboration: people finding each other, meeting, and reaching shared applications. That can be delivered across two tenants in days with the cross-tenant features Microsoft has built into Entra and Microsoft 365. The question of whether to consolidate tenants, and how, can then be answered deliberately, with real information, by around Day 100.
This post covers why tenant consolidation is harder than it looks, how to connect tenants safely for Day 1, the criteria for the Day 100 decision, when to never merge, and how to run a consolidation if you decide to do one.
Why Tenant Consolidation Is Harder Than It Looks
A Microsoft Entra tenant is a security boundary, a data boundary, and an administrative boundary all at once. Almost everything the acquired organization runs in Microsoft's cloud is anchored to it, and very little of it moves cleanly.
Domains are the first constraint. A verified domain can only exist in one tenant at a time. If the acquired company's users sign in and receive email as @acquired.com, that domain has to be removed from their tenant before it can be added to yours. Everything that depends on it, including sign-in names, email addresses, and SharePoint and Teams URLs in some cases, moves at that moment. Domain cutover is usually the single riskiest event in a consolidation.
User objects do not transfer. Each user in the target tenant is a new object with a new object ID. Permissions, group memberships, and application assignments tied to the old object have to be recreated.
Mailboxes, OneDrive, SharePoint sites, and Teams content all need migration. Microsoft provides native cross-tenant migration for mailboxes and OneDrive, licensed per user as an add-on. SharePoint sites, Teams chats, and some Teams content have historically required third-party tools, each with its own fidelity limits.
Application registrations and service principals do not move. Every custom application registered in the acquired tenant has to be re-registered in the target, with new client IDs and credentials, and every system that authenticates with those IDs has to be updated. Enterprise applications set up for single sign-on have to be reconfigured, often with the vendor's involvement.
Azure subscriptions can be transferred between directories, but the transfer removes role assignments and breaks managed identities and anything else tied to the old directory. Key Vault access policies, service connections, and automation accounts all need attention. A subscription transfer that looks like one click in the portal can take days to recover from.
Devices managed by Intune have to be re-enrolled into the new tenant, and Autopilot registrations moved. For a large, distributed workforce, that means touching every laptop.
Security configuration does not transfer either. Conditional Access policies, authentication methods, PIM settings, and Defender configuration all have to be rebuilt in the target tenant or reconciled with what is already there.
Licensing has to be reconciled as well. The acquired company's Microsoft agreements, CSP relationships, and add-on licenses may not align with yours, and some may not be transferable.
All of it can be done, but over months, and the business wants collaboration on Monday.
What Day 1 Actually Requires
Strip the Day 1 request down to what employees need in the first weeks, and the list is shorter than "merge everything":
- Find people in the other company in Outlook and Teams.
- Send email to each other without it being treated as external.
- See free/busy information and schedule meetings across both organizations.
- Chat and meet in Teams without guest-account friction.
- Access a small number of shared applications, usually the acquirer's HR system, intranet, and a few collaboration sites.
- Share files on specific projects.
All of this can be delivered with the two tenants still separate.
The Tools for Connecting Tenants
Microsoft has spent several years building cross-tenant capabilities into Entra and Microsoft 365, largely for this scenario. The main pieces work together.
Cross-Tenant Access Settings
Cross-tenant access settings are the policy layer. For each partner tenant, you configure inbound and outbound rules that determine which users can collaborate in which direction, and which applications they can reach.
The most important settings in an acquisition are the trust settings. You can configure your tenant to trust multi-factor authentication claims, compliant device claims, and Microsoft Entra hybrid joined device claims from the other tenant. When those are trusted, a user from the acquired company who completed MFA in their home tenant does not get prompted again when accessing your resources, and your Conditional Access policies can evaluate their device state.
Those trust settings are convenient and should be earned. Trusting another tenant's MFA claims means trusting how that tenant enforces MFA. If the acquired company allows SMS as a second factor, has large MFA exclusion groups, or still permits legacy authentication, trusting their claims imports those weaknesses into your environment. Assess before trusting.
B2B Collaboration and B2B Direct Connect
B2B collaboration represents users from the other tenant as external user objects in your directory. Those objects can be assigned to applications, added to groups, and granted access to SharePoint and Teams like any other user. Authentication still happens in their home tenant.
B2B direct connect is a lighter model used mainly for Teams shared channels. Users from the other tenant access shared channels without an external user object being created in your tenant. It works well for project-based collaboration and needs explicit configuration on both sides.
Traditional B2B invitations, where someone sends an invite and the recipient redeems it, do not scale to an acquisition. Nobody should be inviting thousands of colleagues one by one.
Cross-Tenant Synchronization
Cross-tenant synchronization automates the creation, update, and removal of B2B users from one tenant into another. It works like a provisioning connector between two directories. You scope which users sync, choose which attributes flow, and the service keeps the target tenant's representation current. When someone leaves the acquired company and their account is disabled or deleted in the source tenant, the synced account in the target is updated to match.
Users are provisioned without invitation emails or consent prompts, and their accounts can be created with user type Member rather than Guest. Member-type accounts appear in the global address list and in people search, and they get a Microsoft 365 experience much closer to an internal user's.
Microsoft is explicit that cross-tenant synchronization is intended for tenants within the same organization, not for partners, because it grants broad access. An acquisition is exactly the case it was built for.
Group synchronization has been the missing piece. Cross-tenant security group synchronization, which Microsoft scheduled for general availability by the end of May 2026, lets groups flow between tenants so that access can be managed centrally instead of rebuilt group by group. It requires Entra ID Governance or Entra Suite licensing.
Multitenant Organizations in Microsoft 365
The multitenant organization feature builds on cross-tenant synchronization. Tenants that join a multitenant organization get improvements in Teams and in Microsoft 365 people search that make cross-tenant collaboration feel closer to single-tenant collaboration. Setup involves one tenant creating the organization and the others joining, with synchronization configured between them.
Exchange and Calendar
Email between the two organizations works over normal mail routing from the start. The improvements come from making it feel internal: configuring organization relationships for free/busy lookups, making sure synced users appear in the address list, and adjusting transport and anti-spam rules so traffic between the two companies is not treated as suspicious external mail.
Choosing a Topology
Microsoft documents three topologies for cross-tenant synchronization, and the right one depends on where the users and applications live.
In a hub-and-spoke application hub, the acquirer's tenant hosts the shared applications, and users from each acquired tenant are synced into it. Microsoft's own guidance uses an acquisition as the example: the acquirer provisions the acquired company's users into its tenant as an application hub, giving them access to shared applications from the first day while their accounts stay managed in their original tenant. This is the most common pattern for acquisitions.
In a hub-and-spoke user hub, all users live in one central tenant and are provisioned into spoke tenants where resources are managed. This suits organizations that want central identity but have resources spread across tenants for regulatory or operational reasons.
In a mesh, peer tenants sync directly with each other. This fits organizations made up of several acquisitions of similar weight, where no single tenant is naturally the center. Meshes get complicated quickly, and each additional tenant adds more relationships to manage.
For a single acquisition by a larger company, the application hub is almost always the starting point. It delivers Day 1 collaboration, keeps the acquired company's identity management intact while you learn what is in it, and does not commit you to any particular long-term answer.
Security Before Connectivity
Connecting two tenants connects two security postures. The acquired company's tenant may have been run well, or it may have unreviewed global administrators, forgotten service principals with broad permissions, no Conditional Access, and legacy authentication still enabled. You will not know until you look, and you should look before anything is trusted.
Treat the acquired tenant as untrusted until it has been assessed. Before or immediately after close, depending on what the deal terms allow, review:
- Every account with a privileged directory role, including external and guest accounts with admin rights.
- Every service principal and app registration with high-privilege Microsoft Graph application permissions, and every OAuth consent grant to third-party applications.
- MFA coverage and the methods allowed, including exclusions.
- Conditional Access policies, and whether legacy authentication is blocked.
- Existing B2B guests and cross-tenant access settings with other organizations.
- Sign-in and audit logs for signs of compromise, including risky users and risky sign-ins.
- Hybrid identity configuration, including Entra Connect servers, federation servers, and on-premises AD health.
Many acquired companies have been breached without knowing it. An acquisition is also a well-known moment for attackers, because communications are confusing, new domains and senders appear, and people expect unusual requests. Phishing that impersonates the acquirer's IT or HR teams is common in the weeks after an announcement.
Pre-close work has its own constraints. Until the deal closes, the companies are legally separate, and competition law limits how much operational integration and information sharing can happen. Work with counsel on what can be reviewed before close, and plan for the full security assessment to happen in the first days after.
Configure cross-tenant access in stages. Start with synchronization scoped to a pilot group, without trusting MFA or device claims. Require your own MFA for the acquired users when they reach your resources. Once the acquired tenant's MFA enforcement has been verified and any gaps closed, turn on MFA trust. Device claim trust should follow device compliance policy being confirmed on their side.
Apply your own Conditional Access to synced users from the start. They are accessing your resources, so your policies decide what they can reach and from where. Use a dedicated group for synced users so policy can target them explicitly.
This connects back to the broader model in my Identity Management as a Tapestry post. An acquisition adds a whole second set of threads to the weave at once, and any weak one is now attached to yours.
The Day 100 Decision
After a few months of running connected tenants, you know a great deal more than you did at close. You have seen the acquired tenant's real configuration, how people actually collaborate across the boundary, what applications they depend on, and how the business intends to integrate the company. That is the right time to decide whether to consolidate.
The decision rests on a handful of questions.
How deeply is the business being integrated? A full absorption, where the acquired brand disappears and teams are merged into the acquirer's structure, points toward consolidation. A holding structure, where the acquired company keeps operating independently, points toward staying multi-tenant.
Is a divestiture possible? If there is any realistic chance the acquired business will be sold, spun off, or carved out within a few years, consolidating now means separating again later. Separation is at least as hard as consolidation.
Are there regulatory or sovereignty constraints? Tenants in different Microsoft clouds cannot be merged. A tenant in a US government cloud, in Microsoft 365 operated by 21Vianet in China, or in another sovereign cloud stays separate by definition. Some regulated subsidiaries also need a separate tenant as a compliance boundary.
What does running two tenants cost? Duplicate licensing for security tooling, duplicate administration, duplicate policy maintenance, and the friction users still feel across the boundary all add up. For a small acquisition folded into a large acquirer, the ongoing cost of a second tenant usually exceeds the one-time cost of consolidating it.
How large is the acquired tenant relative to the acquirer? Consolidating a 200-person company into a 20,000-person tenant is a contained project. Two organizations of similar size are a different matter, and sometimes the answer is to consolidate both into the tenant that is better configured, regardless of which company was the buyer.
How healthy is the acquired tenant? A tenant with serious security debt is a reason to consolidate, because you get to rebuild the users into a well-run environment. It is also a reason to go slowly and clean up first, so the migration does not carry the problems across.
| Factor | Points Toward Consolidating | Points Toward Staying Multi-Tenant |
|---|---|---|
| Integration model | Full absorption, brand retired | Holding structure, independent operation |
| Future of the business | Permanent part of the acquirer | Possible sale, spin-off, or carve-out |
| Cloud and regulation | Same Microsoft cloud, no separate compliance boundary needed | Different sovereign cloud, or regulated boundary required |
| Relative size | Small acquisition into large acquirer | Similar-sized organizations |
| Ongoing cost | High duplicate licensing and admin effort | Low overhead, stable collaboration needs |
| Tenant health | Serious security debt worth rebuilding away | Well-run tenant with mature controls |
| Collaboration intensity | Heavy daily cross-company work | Limited, project-based collaboration |
When to Never Merge
A few situations call for keeping tenants separate regardless of how much friction the second tenant causes.
Keep them separate when the acquired business is in a different Microsoft cloud. There is no merge path between sovereign clouds, and a migration into a different cloud raises data residency and regulatory questions well beyond identity.
Keep them separate when a divestiture is planned or likely. Carving users, data, and applications back out of a consolidated tenant is expensive, slow, and error-prone.
Keep them separate for joint ventures. The partners have separate interests, the venture may be dissolved, and cross-tenant collaboration with scoped access fits the relationship better than shared identity.
Keep them separate when the acquired company operates under a regulatory regime that requires a distinct control boundary, such as certain financial, defense, or healthcare subsidiaries. Talk to compliance before planning any consolidation for these.
Keep them separate, at least temporarily, when the seller is providing services under a transition services agreement. If the acquired business still depends on the seller's systems for months after close, those dependencies usually need to be unwound before any tenant consolidation starts.
The Reverse Case: Divestitures
Acquisitions get most of the attention, but divestitures raise the same identity questions in reverse, usually under tighter deadlines. The buyer wants the business separated by a fixed date, and the seller has to extract users, data, and applications from a tenant that was never designed to be split.
The same tools apply. A new tenant for the divested business can be connected to the parent through cross-tenant synchronization during the transition, so users keep access to the parent's systems under the transition services agreement while their accounts, mailboxes, and files move. When the agreement ends, synchronization is removed and cross-tenant access is closed.
Organizations that acquire frequently should design for this possibility from the start. Keeping acquired business units in clearly defined administrative units, groups, and naming conventions, even after consolidation, makes a later separation far less painful. The External Identity Strategies with Azure AD B2C post covers related ground on separating customer and partner identity from workforce identity, which becomes relevant when a divested business has its own customer-facing applications.
Running a Consolidation
If the Day 100 decision is to consolidate, the cross-tenant setup you built for Day 1 becomes the foundation for the migration.
Plan the Identity Model First
Decide what each migrated user becomes in the target tenant: their user principal name, email addresses, group memberships, licenses, and administrative roles. Decide whether acquired-company email addresses will be kept as aliases after the domain moves. Most organizations keep them for a long period, because customers and partners will keep using them.
Users synced through cross-tenant synchronization already exist in the target tenant as external members. Entra supports converting external users into internal members, which keeps the object and its existing access in place rather than creating a new account and rebuilding permissions. Where that conversion fits your design, it can remove a large amount of rework. Test it thoroughly with a pilot group first.
Handle On-Premises Identity
If the acquired company runs Active Directory synchronized to its tenant, the on-premises side needs its own plan. Options include migrating users and devices into the acquirer's forest, establishing a forest trust as an interim step, or retiring the acquired forest entirely if the company is cloud-first enough. The synchronization tooling has to be reconfigured so each identity has one authoritative source feeding the target tenant. This is often the longest workstream and the one most dependent on on-premises application dependencies nobody documented.
Migrate Content in Waves
Move mailboxes and OneDrive with Microsoft's native cross-tenant migration or a third-party tool, in waves organized by team, so people who work together move together. Pre-stage content well before each wave's cutover so the final sync is small. SharePoint sites and Teams need more planning, because site structures, permissions, and links embedded in documents all have to survive the move.
Cut Over the Domain
The domain cutover is the point of no return. Mail flow, sign-in names, and anything referencing the domain all switch at once. Schedule it for a low-activity window, lower DNS TTLs in advance, have a detailed runbook with timings, and staff the helpdesk for the following days. Communicate clearly to users what will change, including new sign-in prompts, re-authentication on mobile devices, and Outlook profile changes.
Move Devices
Re-enroll devices into the target tenant's Intune, and move Autopilot registrations. For remote workers, this usually means a guided self-service process or a device refresh timed to the migration. Plan for devices that are offline, lost, or in the hands of people on leave.
Rebuild Applications and Azure Resources
Re-register custom applications in the target tenant and update every system that uses the old client IDs and credentials. Reconfigure single sign-on for SaaS applications, coordinating with vendors where needed. For Azure subscriptions, plan the directory transfer as a project: export role assignments before the move, recreate them afterward, and rebuild managed identities, Key Vault access, and service connections. Some teams prefer to redeploy workloads into new subscriptions in the target tenant through infrastructure as code rather than transfer subscriptions at all.
Decommission the Old Tenant
After all users, content, devices, and applications have moved, and after a retention period for anything that must be kept for legal or compliance reasons, decommission the old tenant. Remove cross-tenant access settings and synchronization, revoke any remaining app consents, and document what was kept and where.
The Operating Model
Whether you consolidate or stay multi-tenant, connected tenants need ownership.
Someone has to own cross-tenant access settings. Changes to trust settings, synchronization scope, and inbound and outbound rules should go through change control, because a single setting can open access for thousands of users.
Someone has to own the lifecycle of synced users. Synchronization handles creation and removal automatically, but only for users in scope. Watch for accounts that fall out of scope without being removed, and include synced users in access reviews. Cross-tenant accounts are exactly the kind of identity that drifts, because each side assumes the other is watching.
Someone has to monitor the connection. Alert on changes to cross-tenant access settings, on new synchronization configurations, and on sign-in anomalies from synced accounts. A compromised account in one tenant now has a route into the other.
If the organization acquires regularly, turn all of this into a playbook: a standard assessment checklist, a standard Day 1 configuration, a standard Day 100 decision template, and standard consolidation runbooks. Each deal should get faster and safer than the last.
Common Failure Modes
Acquisition identity work tends to go wrong in predictable ways.
Teams attempt a tenant merge in the first weeks because leadership asked for "one company." The rush produces broken mail flow, lost permissions, and weeks of cleanup, when cross-tenant collaboration would have met the actual need.
They turn on MFA and device trust for the acquired tenant immediately, without checking how that tenant enforces either. The acquirer ends up accepting weaker authentication than its own policies require.
They connect the tenants before assessing the acquired one, and inherit an existing compromise along with the users.
They use one-by-one B2B invitations for thousands of users, producing a mess of guest accounts with inconsistent attributes and no lifecycle management.
They consolidate a business that is sold two years later, and spend a second project separating what the first one merged.
They move users and mailboxes and forget application registrations, service principals, and Azure role assignments, then discover the gaps one production incident at a time.
They leave cross-tenant synchronization and access settings in place long after consolidation, keeping a connection open to a tenant nobody is watching anymore.
Most of these come from treating the tenant as the goal, when the goal is people working together securely, and the tenant structure is one way to get there.
A Practical Sequence
Before Close
Within what the deal terms and counsel allow, gather information about the acquired company's tenant: size, licensing, domains, hybrid identity setup, major applications, and any known security issues. Draft the Day 1 configuration and the security assessment plan so both can start the moment the deal closes.
Days 1 to 30
Run the security assessment on the acquired tenant and fix critical findings, especially privileged accounts, risky service principals, and gaps in MFA. Configure cross-tenant access settings without MFA or device trust. Set up cross-tenant synchronization into an application hub, starting with a pilot group and expanding. Enable free/busy sharing and address list visibility. Give synced users access to the handful of shared applications the business needs first.
Days 31 to 100
Turn on MFA and device claim trust once the acquired tenant's controls are verified. Expand synchronization to all in-scope users, and add group synchronization where licensing allows. Join the tenants into a multitenant organization for the improved Teams and people search experience. Collect the information the Day 100 decision needs: integration plans, regulatory constraints, collaboration patterns, costs, and the acquired tenant's full application and resource inventory.
Day 100 and After
Make the consolidation decision and document the reasoning. If staying multi-tenant, formalize ownership of cross-tenant settings and include synced users in regular access reviews. If consolidating, plan the waves, the domain cutover, device moves, and application rebuilds, and run them using the connected tenants as the bridge.
Wrapping Up
On Day 1, the business needs people collaborating across two companies, and cross-tenant synchronization into an application hub delivers that in days, after a security assessment and without trusting the acquired tenant's MFA or devices until they have been checked. Whether to merge tenants gets decided around Day 100 against specific criteria: integration depth, divestiture risk, sovereign cloud and regulatory boundaries, relative size, and the cost of running two tenants. If the answer is consolidation, the Day 1 connection becomes the bridge for the migration, and the old tenant gets decommissioned only after every domain, device, application, and subscription has moved.