Consolidating 5 Azure Tenants Into 1: Lessons From a Real Enterprise Merger

When an enterprise acquires four companies over three years, the result is predictable: five Azure AD tenants, five sets of Conditional Access policies, five Exchange Online environments, and an identity landscape that nobody fully understands.

This post documents the consolidation of five Azure tenants into one — what worked, what failed, and what we would do differently. The details are anonymised, but the problems and solutions are real.

The Starting Point

Tenant A (Acquirer): 3,200 users, Azure landing zone with 47 subscriptions, M365 E5, Entra ID P2. Well-governed with Conditional Access and PIM.

Tenant B: 800 users, M365 E3, minimal Conditional Access, on-premises AD sync via Azure AD Connect.

Tenant C: 1,400 users, M365 E5, Azure subscriptions for a SaaS product, complex app registrations.

Tenant D: 200 users, M365 Business Premium, no Azure subscriptions, basic security configuration.

Tenant E: 600 users, M365 E3, hybrid identity with ADFS (not yet migrated to cloud auth).

Total: 6,200 users, 63 Azure subscriptions, approximately 180 enterprise applications, 5 Exchange Online environments.

Phase 1: Discovery (Weeks 1-4)

What We Inventoried

For each tenant:

• Users and groups — Count, types (member, guest), group membership, dynamic groups, licensing assignments
• Applications — Enterprise applications, app registrations, service principals, API permissions, client secrets and certificates (with expiry dates)
• Conditional Access — All policies, named locations, terms of use, authentication strengths
• Azure subscriptions — Resource inventory, RBAC assignments, managed identities
• Exchange Online — Mailboxes, distribution lists, shared mailboxes, mail flow rules, accepted domains
• Teams — Teams and channels, external sharing policies, meeting policies
• Devices — Intune enrolled devices, compliance policies, configuration profiles

Discovery Tools

# Export all enterprise applications from a tenant
Connect-MgGraph -TenantId $tenantId -Scopes "Application.Read.All"
$apps = Get-MgServicePrincipal -All | Select-Object DisplayName, AppId, ServicePrincipalType
$apps | Export-Csv "tenant-b-applications.csv"

# Export Conditional Access policies
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | ConvertTo-Json -Depth 10 | Out-File "tenant-b-ca-policies.json"

# Export RBAC assignments for all subscriptions
az role assignment list --all --output json > "tenant-b-rbac.json"

The Discovery Surprise

Tenant C had 47 app registrations with client secrets, 12 of which were used by production systems that nobody in the current team had documented. Finding the owners of these applications took two weeks of detective work through sign-in logs and code repositories.

Phase 2: Architecture Decision (Week 5)

Consolidation Strategy: Absorb Into Tenant A

We chose to absorb all tenants into Tenant A (the acquirer) rather than creating a new clean tenant. Reasons:

• Tenant A had the most mature governance (Conditional Access, PIM, landing zone)
• 3,200 users already trained on Tenant A processes
• Moving 3,200 users is more disruptive than moving 3,000 across four smaller tenants
• Tenant A's Azure landing zone represented months of architecture work

Migration Order

1. Tenant D first (smallest, simplest -- validates the process)
2. Tenant B second (medium complexity, tests AD Connect decommissioning)
3. Tenant E third (ADFS dependency adds complexity)
4. Tenant C last (most complex -- SaaS product with customer-facing app registrations)

Phase 3: Pilot Migration — Tenant D (Weeks 6-9)

Identity Migration

Since cross-tenant user migration does not preserve UPNs seamlessly, we used this approach:

1. Pre-create users in Tenant A with the target UPN suffix (configured as custom domain)
2. Configure cross-tenant synchronisation for the transition period
3. Migrate mailboxes using cross-tenant mailbox migration (requires Exchange Online plan)
4. Reassign licences in Tenant A
5. Cutover DNS for the email domain
6. Decommission Tenant D accounts after 30-day parallel run

What Broke

OneDrive data migration — Cross-tenant OneDrive migration requires Microsoft support engagement and takes longer than expected. We allocated 1 week; it took 3 weeks for 200 users.

Conditional Access conflicts — Tenant A's strict CA policies (compliant device required) blocked Tenant D users whose devices were enrolled in Tenant D's Intune. Solution: temporary exclusion group with a 2-week re-enrollment window.

Shared mailbox ownership — Shared mailboxes needed manual recreation in Tenant A. Distribution lists with cross-tenant members required special handling.

Phase 4: Subscription Migration

Moving Azure Subscriptions Between Tenants

# Step 1: Document all RBAC assignments (they will be deleted during transfer)
az role assignment list --subscription $subId --all > "rbac-backup-$subId.json"

# Step 2: Transfer subscription to target tenant
az account tenant update --subscription $subId --tenant-id $targetTenantId

# Step 3: Recreate RBAC assignments in target tenant
# Script reads backup JSON and recreates assignments with new principal IDs

Critical warning: Subscription transfer resets ALL RBAC assignments. Every role assignment — from Owner to Reader — is deleted. Managed identities become orphaned. If you do not backup and recreate these, teams lose access to their resources.

Managed Identity Remediation

Managed identities are tenant-scoped. After subscription transfer:

1. Delete old user-assigned managed identities
2. Create new ones in the target tenant
3. Reassign permissions (Key Vault access policies, Storage RBAC, etc.)
4. Update application configurations to use new identity client IDs

Lessons Learned

1. Communication Is 50% of the Work

Technical migration is complex but predictable. User anxiety and confusion are the real challenges. We sent:

• T-30 days: Announcement email explaining what is changing and why
• T-14 days: Detailed instructions with screenshots
• T-7 days: Reminder with FAQ
• T-1 day: Final reminder with support contact
• T+1 day: "How did it go?" survey with quick issue reporting

2. Budget 3× Your Time Estimate for OneDrive/SharePoint

Mailbox migration is well-tooled. OneDrive and SharePoint migration is not. File count, path length limits, special characters in file names, and permission inheritance all cause failures that require manual intervention.

3. Application Inventory Is Never Complete

No matter how thorough the discovery, you will find applications during migration that nobody knew existed. Build slack into the schedule for this.

4. Conditional Access Requires a Unified Policy Before Migration

Do not migrate users into a tenant and then figure out CA policies. Unified CA policy design must happen before the first user moves. Otherwise, you either lock out migrated users or weaken security for existing users.

5. Parallel Run Period Is Non-Negotiable

Run both tenants in parallel for 30 days minimum. This catches authentication issues, application breakage, and gives users a safety net.

Planning a tenant consolidation? Contact us — we have done this for enterprises and know where the hidden complexity lives.