Why Tenant Consolidation Is the Central M&A Licensing Challenge
Every Microsoft 365 user belongs to exactly one tenant. In a post-acquisition world where two organisations operate separate tenants, a user can effectively only be fully functional in one of them at a time — yet both tenants are incurring licence cost simultaneously. This is the fundamental commercial reality of tenant consolidation: the longer two tenants co-exist, the more you pay for the privilege of having not yet completed the integration.
The operational stakes are equally high. Two separate tenants mean two separate identity stores, two separate email domains, two separate Teams environments, two separate SharePoint hierarchies, and two separate security and governance configurations. Until consolidation is complete, the combined organisation cannot achieve unified collaboration, centralised security monitoring, or a single governance posture. The Microsoft 365 tenant is not just an IT system — it is the identity and productivity backbone of the modern enterprise, and operating two of them simultaneously after an acquisition creates friction at every level of the combined organisation.
Understanding the full scope of tenant consolidation — the technical phases, the cost drivers, the commercial levers, and the tooling options — is essential for any enterprise IT leader or procurement function managing a Microsoft-heavy M&A integration.
Phase 1: Pre-Migration Audit and Assessment (Weeks 1–8)
The pre-migration phase is the most important part of the entire consolidation process, yet it is routinely compressed or skipped when integration teams are under pressure to show Day 1 operational results. The consequences of a poor pre-migration assessment emerge mid-project when hidden dependencies surface at the worst possible time — after migration tooling has been procured, cutover schedules have been communicated to users, and there is no budget or runway to respond to the unexpected.
Identity Mapping
The first task is mapping user identities between the two tenants. This is not simply a headcount exercise — it requires correlating user accounts across both Azure Active Directory instances, identifying shared email aliases, resolving name conflicts (two people named John Smith, one in each company), and documenting any users who already have guest access in both tenants from prior collaboration. The identity map becomes the master reference document for the entire migration; every subsequent phase depends on its accuracy.
Content and Data Assessment
The content assessment covers three primary workloads: Exchange Online mailboxes and calendars, SharePoint Online sites and document libraries, and Teams teams and channels. Each workload has different migration complexity, different tooling requirements, and different user-impact profiles. Mailbox migration is well-understood and largely automated; SharePoint migration requires careful site-by-site assessment, particularly for sites with custom web parts, Power Platform integrations, or external sharing configurations; Teams migration is the most complex, as Teams data includes not just chat history and files but also associated apps, bots, connectors, and governance settings that cannot be migrated through standard tooling.
Data volume is a key driver of migration duration and cost. An acquired entity with 1,000 users and an average mailbox size of 20GB carries 20TB of email data alone — before SharePoint and Teams content. Migration tooling throughput, typically measured in GB per hour per parallel stream, determines the minimum calendar time required to migrate that volume. Organisations that skip the data assessment phase often discover mid-project that their migration timeline is physically unachievable with the tooling budget they have allocated.
SaaS Application Dependency Mapping
The most underestimated element of the pre-migration assessment is the SaaS application dependency map. Most enterprise organisations have dozens — sometimes hundreds — of SaaS applications whose user authentication is tied to their Microsoft 365 tenant identity. Salesforce, ServiceNow, Workday, Slack, Zoom, GitHub, and hundreds of line-of-business applications authenticate via Azure AD. When users migrate from the acquired tenant to the acquiring tenant, every one of these application integrations must be re-established in the target tenant before those users can resume work.
Undocumented SaaS applications surface regularly during tenant migrations and are responsible for the majority of post-migration productivity disruptions. An effective pre-migration assessment includes scanning both tenants' Azure AD application registrations, surveying business units for applications managed outside IT, and cross-referencing with the acquirer's IT asset management records. Applications that cannot be re-integrated in the target tenant before user cutover create hard blockers that force rollback or temporary workarounds — both of which extend the migration window and increase double-licensing cost.
Phase 2: Migration Strategy and Tooling Selection (Weeks 4–8)
With the pre-migration assessment complete, the migration strategy decision can be made. The core decision is whether to run a simultaneous multi-workload migration (move email, SharePoint, and Teams for each user cohort at the same time) or a sequential workload migration (move all mailboxes first, then SharePoint, then Teams). Simultaneous migration is faster and reduces the double-tenant period; sequential migration is lower risk but extends the window during which users operate in a split environment.
For most enterprise consolidations involving 1,000–5,000 users, a hybrid approach is optimal: migrate email simultaneously with identity (Azure AD user provisioning in the target tenant), then follow with SharePoint in parallel cohorts, then Teams as the final phase. This sequencing reflects the operational priority order — email and identity are the most disruptive to delay, SharePoint content can tolerate a brief parallel-access period, and Teams migration can be phased over a longer period without significant user impact since most Teams content is read-accessible in both tenants during the transition window.
Tooling Options
Microsoft provides native migration tooling through the SharePoint Migration Tool (SPMT) and the Exchange Admin Center migration dashboard. These native tools are adequate for smaller migrations (under 500 users) but lack the parallelism, monitoring capabilities, and workload breadth required for large enterprise consolidations. Third-party migration platforms including Quest On Demand Migration, BitTitan MigrationWiz, and AvePoint significantly increase migration throughput, provide detailed progress reporting, and support all three primary workloads within a single platform. The cost of third-party tooling — typically £15–50 per user for a full-suite licence — is almost always justified by the reduction in migration duration and the associated reduction in double-licensing cost.
For a 2,000-user migration at £50,000 per month in double-licensing cost, a third-party tooling investment of £80,000 that reduces the migration from six months to four months saves £100,000 net — a 1.25x return on the tooling investment in direct licensing savings alone, before any productivity or risk benefit is counted.
Phase 3: Phased User Cutover (Weeks 8–24+)
User cutover — the process of moving users from the acquired tenant to the acquiring tenant — should be executed in cohorts, not as a single big-bang migration. Cohort-based migration allows the team to learn from early waves, refine the process, and manage support capacity rather than overwhelming the helpdesk with the full user population simultaneously.
Cohort sequencing should be driven by two factors: SaaS dependency complexity (simpler users first, complex power-users last) and business criticality (non-essential functions first, revenue-critical teams last). A typical cohort structure for a 2,000-user migration might be: Wave 1 (200 users, low SaaS dependency, non-revenue-critical) → Wave 2 (500 users, moderate SaaS dependency) → Wave 3 (800 users, higher dependency) → Wave 4 (500 users, highest complexity including C-suite, sales, and operations). The cadence between waves should be 2–3 weeks, sufficient to resolve issues from the previous wave before adding more users.
Deactivating Acquired Tenant Licences During Migration
The critical commercial discipline during the cutover phase is deactivating licences in the acquired tenant for each user cohort as soon as that cohort's migration is validated. Many organisations leave acquired-tenant licences active until the subscription end date as an administrative convenience or as a rollback safety net. This is expensive. Once a migration wave is validated (users can access all workloads and SaaS applications in the target tenant), the corresponding acquired-tenant licences should be deactivated within 5–10 business days. At 500 users per wave at £25 per user per month, 10 days of unnecessary dual-activation costs approximately £4,100. Multiply that across four waves and the total unnecessary cost reaches £16,000 — a meaningful saving that requires only procedural discipline, not budget.
Phase 4: Post-Migration and Tenant Decommission
The final phase of tenant consolidation is the decommission of the acquired tenant. This phase begins when the last user cohort has been migrated and validated. It involves deprovisioning all user accounts in the acquired tenant, revoking SaaS application integrations, archiving any remaining mailbox or SharePoint content that was not migrated (typically regulatory holds or litigation hold data), and formally cancelling or allowing to expire the acquired tenant's Microsoft 365 subscriptions.
The decommission phase has a specific commercial importance: it is the point at which the double-licensing cost definitively ends. The acquired tenant's subscriptions are typically in one of two states — active subscriptions that must be actively cancelled (NCE annual or monthly), or subscriptions that can simply be allowed to expire at the end of their term. For NCE annual subscriptions with significant remaining term, active cancellation may incur early termination fees. The financial model for decommission should calculate whether early termination fees are lower than the cost of continuing to pay for the remaining subscription term — in most cases, the break-even point for cancelling versus waiting favours cancellation within two months of the last user migration.
Commercial Strategy: Negotiating the Migration Credit
Microsoft will sometimes provide a migration credit — a partial offset to the double-licensing cost during the tenant consolidation window — for customers who request it explicitly and can demonstrate documented migration progress. This credit is not widely advertised and is not offered proactively by Microsoft's account teams. It exists because Microsoft's commercial interest is in completing the consolidation (resulting in a single, larger EA customer) rather than extracting maximum short-term subscription revenue from a parallel-run period.
The credit negotiation should be initiated within 30 days of deal close, framed as a request for commercial support for the integration process. Provide your account team with the integration timeline, the estimated user count for each migration wave, and a projected completion date. Microsoft's standard position is to offer a credit of 60–90 days of parallel-licencing cost for users who are actively mid-migration — not for the full migration period, but for the completion phase. This credit is typically structured as a subscription extension or a future credit note, not a direct invoice reduction, which means it requires tracking and should be documented in writing to ensure it is applied.
The migration credit discussion is also an opportunity to surface the consolidated EA renewal discussion. As with all Microsoft commercial negotiations, early engagement with a specific ask and documented commitment produces better outcomes than waiting until the migration is complete and approaching renewal without a clear commercial narrative. The Microsoft EA advisory specialists at Redress Compliance manage this commercial track in parallel with the technical migration workstream, ensuring the licensing cost of the integration is minimised while the renewed EA terms reflect the combined entity's scale and leverage.
Managing an M365 tenant consolidation following an acquisition?
We manage both the commercial licensing track — migration credit, double-licensing cost, EA renewal — and advise on the technical migration strategy. 100% buyer-side.