Why identity is the hardest M&A migration problem
Content moves with tools. Mailboxes migrate via BitTitan. SharePoint migrates via AvePoint or ShareGate. OneDrive content migrates via native Microsoft. The tools handle throughput and fidelity automatically once configured. Identity is different. Identity requires architectural design before any tool runs.
The identity decisions are: which coexistence pattern, which UPN strategy, which Conditional Access policy set, how to handle group membership, how to handle license SKUs, how to handle MFA enrollment, how to handle external collaboration. Each decision has long-tail operational consequences that survive the migration. Get them wrong and Day-1 +30 becomes an identity-cleanup project.
Microsoft Entra ID coexistence patterns
Single-tenant absorption: all source-tenant users move into the destination Microsoft Entra ID. Source-tenant accounts are de-provisioned at TSA exit. The simplest pattern. Works when identity scope is well-defined, UPN domains can be unified or coexist, and Conditional Access can be harmonized. Most mid-market M&A integrations end here.
Multi-tenant federation: both tenants remain operational long-term with federation. Microsoft Entra B2B or Cross-Tenant Access Settings handle cross-tenant collaboration. Works when the source-tenant entity retains operational autonomy — joint ventures, holding company structures, regulatory separation requirements, or PE add-on integrations where the platform tenant is the destination but the add-on retains some identity independence.
Cross-Tenant Access Settings (transitional): the transitional pattern when full identity merger takes multiple quarters. Users from both tenants collaborate during transition with controlled cross-tenant access. The final destination is usually single-tenant absorption, but the transition runs through Cross-Tenant Access for months.
Active Directory forest scenarios
AD scenarios range from single-forest absorption to multi-forest hybrid bridges. Single-forest absorption merges the source AD forest into the destination forest, typically using AD migration tooling for SID translation, group consolidation, and trust cleanup. Multi-forest hybrid bridges preserve forest separation with cross-forest trusts and ADFS or Entra Connect cloud sync handling the Microsoft 365 layer.
Quest On Demand Migration leads for complex multi-forest scenarios because its identity engine handles concurrent Active Directory and Microsoft Entra ID merging. The choice between absorption and bridge depends on the legacy AD topology, destination organization size, duration of coexistence, and whether on-premises applications still depend on the source AD.
Hybrid identity bridges during transition
Hybrid identity bridges combine on-premises Active Directory with cloud Microsoft Entra ID. Microsoft Entra Connect (or the newer Microsoft Entra Cloud Sync) synchronizes on-premises AD identities to Entra ID. In M&A, hybrid bridges enable on-premises applications that still depend on AD to keep working while the cloud identity layer transitions.
Bridges run for the duration of the migration and often longer. Many M&A integrations leave hybrid bridges in place for 12-24 months post-cutover because on-premises application migration runs on its own timeline separate from Microsoft 365.
Cross-Tenant Access Settings and Microsoft Entra B2B
Cross-Tenant Access Settings control inbound and outbound collaboration between Entra ID tenants. The settings determine which users from another tenant can access resources, what level of trust is granted (MFA claims, device compliance claims), and which apps are accessible. In M&A, Cross-Tenant Access enables both tenants to work together during transition without full identity merger.
Microsoft Entra B2B is the complementary pattern. B2B invites users from one tenant into another as guest users with controlled access. In M&A, B2B enables specific source-tenant users to access destination-tenant resources during the cutover window. After Day-1, B2B is decommissioned for users who become full destination-tenant accounts, or repurposed for external partner access.
Domain rename and UPN strategies
User Principal Names determine how users sign in. The three options: unify all UPNs under the destination domain (e.g., source.com users become @newco.com), preserve source UPNs alongside destination UPNs (dual-domain coexistence), or transition UPNs in waves over months.
UPN unification is the cleanest end-state but introduces friction at cutover — users have to relearn their login. Dual-domain coexistence preserves user experience but requires both UPN suffixes to be registered in the destination tenant. Wave transition balances both. The choice is documented in an Architecture Decision Record signed by the senior architect.
Conditional Access during coexistence
Source-tenant Conditional Access policies do not transfer automatically. Destination-tenant Conditional Access must be rebuilt for the merged user population. The rebuild covers named locations, device compliance requirements, MFA enforcement, sign-in risk thresholds, and application protection policies.
During coexistence, Conditional Access policies often differentiate by user origin — source-tenant users may have looser policies during transition while their MFA enrollment and device compliance catch up. The policy set is signed by the named senior architect before cutover. Post-Day-1, Conditional Access policies harmonize across the merged user base.
Group membership cleanup
Source-tenant groups carry hidden complexity. Nested groups create cycles. Orphaned members reference deleted users. Dynamic group queries use rules that don't survive migration. License-assignment groups bypass administrative oversight. Cleanup before migration prevents the destination tenant from inheriting these problems.
ShareGate and Quest both surface group cleanup recommendations during migration. The cleanup happens during Build phase, not after Day-1. The cleanup playbook covers: flatten nested groups one level, remove orphaned members, replace dynamic groups with explicit memberships where complexity warrants, and migrate license assignment from groups to direct assignment for critical SKUs.
Common identity coexistence failure modes
The four most common failures: (1) coexistence pattern chosen in Cutover phase instead of Plan phase, leaving no time to validate SSO claims; (2) UPN strategy not communicated to end users, so they can't sign in at Day-1; (3) Conditional Access rebuilt without pilot validation, so MFA requirements break for specific user populations; (4) group membership cleanup skipped, so the destination tenant inherits source-tenant group complexity.
The M&A Microsoft 365 Tenant Migration Playbook prevents all four through staged Plan-phase deliverables, pilot waves in Build phase, and the Go-Live Readiness Assessment gate before cutover. Identity coexistence is the single workstream where shortcuts in Plan or Build phase show up immediately as Day-1 failures.
How to engage EPC Group on identity coexistence
Schedule a discovery call at epcgroup.net/schedule, email contact@epcgroup.net, or call (888) 381-9725. Identity coexistence design is included in every M&A engagement and can also be scoped as a stand-alone advisory engagement when the IT team wants senior-architect review of an existing coexistence plan.