Microsoft 365 Tenant-to-Tenant Migration: Licensing, Costs, and What Microsoft Won't Tell You

What a Tenant-to-Tenant Migration Actually Involves

A Microsoft 365 tenant-to-tenant (T2T) migration is the process of moving users, data, and workloads from one Microsoft 365 tenant (source) to another (target). It is most commonly triggered by mergers and acquisitions, corporate demergers, group reorganisations, or the decision to consolidate multiple historically separate Microsoft tenants into a single environment.

Unlike a migration from on-premises Exchange to Exchange Online — which Microsoft has extensively tooled and documented — a T2T migration is deliberately under-resourced by Microsoft in terms of native tooling. Microsoft does not offer a native T2T migration tool for email. The Microsoft 365 tenant structure is designed to be persistent and durable, not easily transferable. This creates a dependency on third-party migration platforms (BitTitan MigrationWiz, Quest Migration Manager, Avepoint, Veeam, and others) that adds cost and complexity to every T2T migration project.

Common T2T Migration Triggers and Their Licensing Implications

Licensing During the Coexistence Period

The coexistence period — the time between when a migration begins and when the source tenant is fully decommissioned — is the most commercially expensive phase of a T2T migration from a licensing perspective. During coexistence, many users require active licences in both the source and target tenant simultaneously: they need access to their legacy mailbox and historical data in the source while working in the new target environment.

Microsoft does not provide a standard mechanism for "migration mode" licensing that reduces the per-seat cost during coexistence. Users in the source tenant continue to consume their full M365 licence allocation until their accounts are deprovisioned. The coexistence period therefore directly translates to dual licensing cost. For a migration that runs 6–9 months (typical for organisations of 3,000–8,000 users with complex Intune, SharePoint, and Teams dependencies), a 4,000-user population migrating from E3 source to E3 target will incur approximately £252,000–£378,000 in coexistence licensing overhead (2 × £31.50/user/month × 4,000 users × 2–3 months of partial overlap, assuming a phased migration).

Minimising the coexistence licensing cost requires a deliberate migration velocity strategy: moving users quickly through the migration waves rather than running a long, slow migration that keeps the coexistence period open for an extended period. The temptation to run a slow, "low-risk" migration that keeps the source tenant running as a fallback for 9–12 months is commercially expensive. A well-run T2T migration should target complete decommissioning of the source tenant within 6 months of first migration wave go-live.

Licence Reduction in the Source Tenant

As users are migrated from the source to the target tenant, their licences in the source tenant should be removed. This sounds obvious but is frequently mismanaged. Source tenant licences are often held under an EA with an annual true-up mechanism — reducing the licence count mid-year does not immediately reduce cost unless the EA specifically includes a mid-year licence reduction provision.

Before starting a T2T migration, organisations should review the source tenant's EA terms to understand: whether mid-year licence reductions are permitted; what the minimum notice period is for licence count adjustments; and whether the true-up mechanism allows downward revision at the annual anniversary. For EAs that do not permit mid-year reductions, the source tenant EA cost will continue until the next annual anniversary regardless of how quickly users are migrated. This is a material cost that should be factored into the migration business case and, where possible, negotiated into the EA terms before migration begins.

What Migrates and What Does Not

One of the most frequently misunderstood aspects of T2T migrations is that Microsoft 365 data objects do not natively transfer between tenants in their original form. Understanding what migrates, what requires re-configuration, and what is permanently lost is critical for accurate scoping and cost estimation.

What Third-Party Tools Can Migrate

• Exchange Online mailbox content: Emails, calendar items, contacts, tasks, and notes can be migrated using third-party tools. Historical email is generally migrated faithfully, though mailbox archive data (in-place archives) requires careful handling and may incur additional licence costs during migration.
• OneDrive for Business: Files and folder structure can be migrated, preserving file content but typically not sharing permissions (which must be re-established post-migration).
• SharePoint Online: Site collections, document libraries, and list content can be migrated. Complex SharePoint customisations, workflows, and permission structures require manual remediation. SPO migration is typically the most complex and time-consuming workload.
• Teams chat history: Direct messages and channel conversation history can be migrated using specialist tooling, but the migration fidelity is lower than email — attachments, reactions, and some message types may not transfer cleanly.

What Does Not Transfer Between Tenants

• Microsoft Entra ID objects in original form: User accounts, groups, and security principals exist as new objects in the target tenant. Membership and permissions must be re-established.
• Conditional Access and Intune policies: Device compliance policies, Conditional Access configurations, and app protection policies are tenant-specific and must be rebuilt in the target. Devices must be re-enrolled in Intune.
• Azure AD App Registrations: Applications registered in the source tenant (including third-party SaaS integrations using Entra ID for SSO) must be re-registered in the target tenant and reconnected to upstream applications.
• Teams channel recordings (in Azure Media Services): Older Teams recordings stored in Azure Media Services (pre-Stream on SharePoint migration) may not be migrable through standard tooling.
• Power Platform environments and flows: Power Apps, Power Automate flows, and Dataverse environments are tenant-bound. These must be exported, recreated, and reconnected in the target tenant — a substantial remediation effort for organisations with extensive Power Platform investments.
• Microsoft 365 Groups settings and memberships: While content can be migrated, Groups configuration must be recreated.

EA Negotiation Opportunities Created by T2T Migrations

A T2T migration is a significant Microsoft commercial event — and like all significant commercial events, it creates negotiation leverage that most organisations fail to exploit. Microsoft's commercial team is aware that a T2T migration represents a long-term commitment to the target tenant and a renewed dependency on Microsoft's ecosystem. This creates several leverage points.

Volume Consolidation Leverage

When two separate Microsoft tenants are consolidated, the combined seat count in the target tenant is higher than either entity previously had independently. If the combined seat count crosses a Microsoft pricing tier threshold — particularly the transitions at 500, 1,000, 2,500, and 10,000+ seats — the consolidation creates a legitimate basis for renegotiating the EA pricing downward. Microsoft's standard position is that pricing tiers are applied at the time of the next EA renewal, but a consolidation event provides grounds to request an immediate pricing adjustment on the basis that the new combined volume was not present when the current EA was priced.

This argument requires preparation: a formal commercial position documenting the combined seat count, the applicable pricing tier, and the requested adjustment should be presented to Microsoft before the migration project enters final sign-off. Waiting until after migration completes removes the leverage entirely. The full approach to EA consolidation negotiation applies directly here.

Migration as Renewal Timing Leverage

If the source tenant's EA has a renewal date that falls within 18 months of the planned migration completion, the migration creates an opportunity to co-terminate the source EA and negotiate a single consolidated EA that starts at migration completion rather than renewing the source EA on its existing cycle. This alignment eliminates the risk of a source EA renewal that commits to ongoing cost for a tenant that will be decommissioned.

Achieving this requires early engagement with Microsoft's commercial team — typically 12 months before the source EA would otherwise renew. The EA co-terming strategy is directly applicable, with the additional context that the source tenant represents genuine walk-away leverage: an organisation that is already committed to decommissioning the source tenant has a credible and documented reason to refuse a source EA renewal.

SKU Rationalisation at Migration

A T2T migration is the correct moment to rationalise the licence mix across the consolidated estate. Organisations that have acquired companies with different M365 licence tiers — for example, an acquirer on M365 E3 and a target company on Microsoft 365 Business Premium — must harmonise to a single SKU in the consolidated tenant. This harmonisation decision should be made based on actual usage and requirements, not on which licence tier is cheaper or which is already in the acquirer's EA.

The most common mistake is defaulting to the acquirer's existing tier without assessing whether a different tier would be more appropriate for the combined organisation. A thorough E3 vs E5 comparison at the point of migration, incorporating the security posture and compliance requirements of the combined entity, often yields a different conclusion than the pre-migration tier choice suggests. This is particularly relevant in acquisitions where the acquired company operated in a regulated sector and had E5 or higher security capabilities that the acquirer did not.

Identity Architecture Decisions That Affect Licensing

The Entra ID (Azure AD) architecture of the target tenant affects licensing costs in ways that are not immediately obvious. The most significant licensing cost driver in the identity layer is the choice of hybrid identity model: password hash sync, passthrough authentication, or AD FS. Each has different infrastructure requirements that affect Azure and Windows Server licensing.

For organisations that have historically used AD FS for federation (common in legacy source tenants), the T2T migration is an opportunity to migrate to password hash sync or passthrough authentication, eliminating the ongoing infrastructure cost of AD FS servers. The Entra P1 licence included in M365 E3 and above supports both password hash sync and passthrough authentication natively — the AD FS infrastructure is redundant for cloud-managed identity scenarios. This simplification can reduce Windows Server and SQL Server licence costs by eliminating the AD FS and WAP server estate.

Third-Party Migration Tool Licensing: What to Negotiate

The third-party migration tool selection is a separate procurement decision that organisations frequently approach as a commodity purchase. It is not. The major migration platforms have substantially different pricing models, and the per-seat or per-GB cost models can vary by 3–5x for the same migration scope. Key negotiation points in migration tool procurement include:

• Per-seat versus per-GB pricing: For mailbox-heavy migrations, per-GB pricing is typically more expensive. For organisations with large SharePoint libraries and relatively small mailboxes, per-seat pricing may be less favourable. Model both approaches against your actual data profile before committing.
• Licence stacking versus concurrent usage: Some tools price per migration pass (each time a mailbox is synchronised counts as a migration consumption), while others provide unlimited synchronisation within a licence period. For phased migrations with multiple pre-cutover synchronisation runs, unlimited sync licences are materially cheaper in practice despite higher headline pricing.
• Teams migration add-ons: Teams chat history migration is typically a premium add-on in most tooling platforms. The cost is often difficult to justify relative to the business value of migrating historical Teams messages — organisations should make a deliberate decision about whether Teams history is a requirement rather than accepting it as a default migration scope item.
• Competitive tension: BitTitan, Quest, Avepoint, and Veeam compete actively for T2T migration contracts at enterprise scale. Running a competitive RFP process — even a simplified one — typically yields 15–25% price reduction versus an unsolicited quote from any single vendor.

Decommissioning the Source Tenant: The Often-Missed Final Step

The source tenant decommission is the final — and frequently delayed — step of a T2T migration. Many organisations declare migration "complete" when 95% of users have been moved, but leave the remaining 5% (typically the most complex cases: executives, shared mailboxes, distribution groups, resource calendars, and service accounts) in the source tenant for months or years. Every day the source tenant remains partially populated is a day of unnecessary licensing cost.

The correct approach is to schedule source tenant decommissioning as a hard project milestone — not a "when we get around to it" task. Assign explicit ownership, set a date 30–60 days after the final user migration wave, and work through the complex residual cases with that deadline in mind. The cost of maintaining a source tenant with 200 residual users for an additional 12 months because decommissioning was deprioritised is approximately £75,600 at E3 pricing — a cost that could have funded meaningful additional security or productivity capability in the target environment.

Frequently Asked Questions

Can Microsoft help with T2T migrations directly?

Microsoft provides limited native tooling for T2T migrations — primarily the SharePoint Migration Tool (SPMT) and some Entra ID configuration guidance. For mailbox migration, Teams data migration, and complex SharePoint scenarios, third-party tooling is required. Microsoft FastTrack may provide advisory support for qualifying organisations, but FastTrack does not cover the full migration execution scope and should be treated as a supplementary resource rather than a primary migration delivery mechanism.

Do we pay for licences in both tenants during migration?

Yes, unless you negotiate specific terms otherwise. During the coexistence period, users who need access to both source and target environments require active licences in both tenants. The source tenant licences continue under the existing EA terms until accounts are deprovisioned. This coexistence licensing cost is a real and quantifiable expense that should be included in the migration business case from day one.

Can we use the migration to get out of our EA early?

In most cases, no — Enterprise Agreements are binding for their term and do not include an early termination right for mergers or migrations. However, if the source EA has a renewal due within 12–18 months of the planned migration completion, you can decline to renew and plan the migration to complete before the source EA renewal date. This is the preferred commercial approach for avoiding a "wasted" EA renewal on a tenant that is about to be decommissioned.

What happens to our SharePoint Online customisations in the migration?

SharePoint Online customisations — including SharePoint Framework (SPFx) solutions, custom web parts, list customisations, and workflow automations — are tenant-specific and must be redeployed in the target tenant. Content can be migrated by third-party tools, but custom code must be re-packaged and deployed through the target tenant's App Catalog. This is a material effort item that requires developer involvement and is frequently underestimated in migration project scoping.