Microsoft 365 Tenant Consolidation: A Step-by-Step Migration Guide

If your organisation has acquired another company — or simply accumulated multiple Microsoft 365 tenants through organic growth — you are sitting on a consolidation problem that gets more expensive every month. Duplicate licenses, fragmented collaboration, inconsistent security policies, and confused end users are the daily reality of a multi-tenant estate.

This guide walks through the end-to-end process of consolidating Microsoft 365 tenants into a single, well-governed environment. It is based on dozens of tenant migrations CC Conceptualise has delivered across DACH and the wider EU.

When Tenant Consolidation Makes Sense

Not every multi-tenant situation requires consolidation. Consider it when:

Collaboration friction is high: Users cannot see free/busy, share files, or find colleagues across tenants
License costs are duplicated: Two E5 licenses for the same person, or paying for overlapping add-ons
Security posture is inconsistent: Different conditional access policies, different MFA requirements, different retention rules
Regulatory or audit pressure: Auditors want a single identity plane and unified DLP controls

Reality check: Tenant consolidation is a 3–9 month programme for most mid-market organisations. Plan accordingly and do not promise a "quick merge."

Phase 1: Discovery and Planning (Weeks 1–4)

Inventory Both Tenants

For each tenant, document:

Licensing: SKU counts, assignment method (group-based or direct), add-ons (Phone System, Power BI Pro, Defender plans)
Mail flow: Hybrid Exchange or Exchange Online only? Custom transport rules, connectors, shared mailboxes, distribution lists, mail-enabled public folders
SharePoint and OneDrive: Total data volume, number of site collections, external sharing settings, custom workflows (Power Automate, legacy SharePoint Designer)
Teams: Team count, channel structure, third-party app integrations, calling/meeting policies, direct routing or Operator Connect configuration
Security and compliance: Conditional access policies, DLP policies, sensitivity labels, retention policies, eDiscovery cases, litigation holds
Third-party integrations: SAML/OIDC apps registered in Entra ID, API permissions granted, service principals

Define the Target State

Decide which tenant becomes the target (surviving) tenant. Typically this is the acquiring company's tenant because it has more established governance, more users, or specific regulatory configurations that are harder to rebuild.

Create a mapping document:

Source UPN → Target UPN (handle domain conflicts early)
Source mailbox → Target mailbox (note: shared mailboxes, room mailboxes, and equipment mailboxes need separate treatment)
Source SharePoint sites → Target sites (some may merge, some may archive)

Phase 2: Pre-Migration Coexistence (Weeks 3–6)

Before migrating a single mailbox, establish coexistence so users can collaborate across tenants without disruption.

Cross-Tenant Mail Flow

Add the source tenant's accepted domains to the target tenant as internal relay domains (or configure mail flow via a shared mail gateway)
Set up cross-tenant mail routing using Exchange Online connectors so that mail between tenants routes internally, not via the internet
Configure free/busy sharing via organisation relationships in Exchange Online

Cross-Tenant Identity

Enable Entra ID cross-tenant synchronisation to project source users into the target tenant as external members
Configure cross-tenant access settings to allow B2B collaboration, Teams chat, and shared channels between both tenants
Deploy Entra ID access packages so source users can request access to target-tenant resources during the transition

Shared Namespace (Optional but Recommended)

If both companies will operate under a single brand, configure the target tenant with all required domains. During coexistence, use mail forwarding or dual delivery so messages reach users regardless of which tenant their mailbox currently lives in.

Phase 3: Mailbox Migration (Weeks 5–12)

Choose Your Migration Tool

Tool	Best For	Limitations
Microsoft native cross-tenant migration	Exchange Online-to-Exchange Online	Requires Entra ID cross-tenant sync; limited SharePoint support
BitTitan MigrationWiz	Broad workload support, hybrid scenarios	License cost per mailbox; throttling at scale
Quest On Demand Migration	Large enterprises, complex environments	Higher cost, more setup
ShareGate	SharePoint-heavy migrations	Less suited for mail

For pure Exchange Online-to-Exchange Online scenarios, Microsoft's native cross-tenant mailbox migration is now mature enough for production use. It preserves mail, calendar, contacts, and folder structure.

Migration Execution

Migrate in waves of 50–200 mailboxes, grouped by department or location to keep team collaboration intact
Schedule migrations over weekends or during low-activity periods. Mailbox migrations can take 2–24 hours depending on size
Pre-stage large mailboxes (>50 GB) by starting the migration sync days before the cutover date
Update mail routing (MX records, connectors, transport rules) after each wave
Validate: send/receive test, calendar delegation, shared mailbox access, Outlook profile re-creation

Post-Migration Mailbox Validation Checklist

User can send and receive email on the new UPN
Calendar items, including recurring meetings, are intact
Shared mailbox and delegate access works
Auto-replies and mail rules migrated correctly
Mobile devices (Outlook, native mail) reconnected

Phase 4: SharePoint and OneDrive Migration (Weeks 6–14)

SharePoint is often the most data-intensive workload. Plan for longer migration windows.

Strategy

OneDrive: Use Microsoft's cross-tenant OneDrive migration (preview/GA depending on timing) or a third-party tool. Each user's OneDrive data migrates with their identity
SharePoint team sites: Map source sites to target sites. Decide whether to merge content, archive it, or create new sites
SharePoint communication sites: Evaluate whether to rebuild (different branding/templates) or migrate as-is
Permissions: Re-map source groups and users to target groups. This is where thorough identity work in Phase 2 pays off

Data Volumes and Throttling

Microsoft throttles migration throughput. Expect:

OneDrive: 1–2 TB per 24 hours per migration slot (varies by tenant size and Microsoft's current throttle settings)
SharePoint: Similar, but large file counts (millions of items) slow things down more than raw data volume

Plan a two-pass approach: initial sync (bulk copy), then a delta sync just before cutover.

Pro tip: Identify and clean up ROT data (Redundant, Obsolete, Trivial) before migration. Migrating 5 TB of data nobody uses is a waste of time and license capacity.

Phase 5: Teams Consolidation (Weeks 8–14)

Teams consolidation is often the most disruptive workload for end users because it changes their daily work interface.

Migration Approach

Teams chat history: Native cross-tenant migration now supports 1:1 and group chat history. Verify this capability is available in your tenant
Teams and channels: Recreate the team structure in the target tenant. Migrate underlying SharePoint content. Re-add members from the unified identity directory
Shared channels: If you used B2B shared channels during coexistence, convert them to standard channels post-migration
Third-party apps: Re-install Teams apps (bots, connectors, tabs) in the target tenant. Test integrations thoroughly
Calling and meetings: If using Teams Phone (Direct Routing or Operator Connect), migrate SBC configurations, dial plans, and number assignments

User Communication

Teams migration is highly visible. Prepare:

A step-by-step guide for end users (with screenshots) covering: new sign-in, Teams cache clearing, re-pinning channels
A known issues list updated daily during migration waves
Dedicated support (Teams channel + help desk queue) for the first two weeks post-migration

Phase 6: License Optimization (Weeks 10–16)

Once migration is complete, optimise licensing to capture cost synergies.

Quick Wins

Remove duplicate licenses. Users who had licenses in both tenants now need only one
Right-size SKUs. Not everyone needs E5. Segment users into E5 (power users, compliance-heavy roles), E3 (standard), and F3 (frontline workers)
Consolidate add-ons. Two Defender for Office 365 Plan 2 subscriptions become one. Same for Power BI Pro, Visio, Project

Long-Term Optimization

Implement group-based licensing in Entra ID to automate license assignment based on role or department
Use Microsoft 365 usage reports and Viva Insights to identify under-utilised licenses
Negotiate with Microsoft: a consolidated tenant with a larger seat count gives you leverage for volume discounts

Common Pitfalls

Underestimating mail-enabled public folders: These are hard to migrate and often critical for finance teams. Discover them early
Forgetting conditional access policies: A user migrated into a tenant with stricter CA policies may be locked out on Day 1 if their device is not compliant
Ignoring Power Platform: Power Apps and Power Automate flows tied to the source tenant will break. Inventory and re-create them
Not testing Outlook profiles: Outlook often requires a new profile after cross-tenant migration. Automate this via script or Intune

How CC Conceptualise Helps

We run tenant consolidation programmes end to end — from discovery through to licence true-up. Our approach minimises user disruption by getting coexistence right before moving a single mailbox.