Tenant Carve-Out vs. Consolidation: When to Move a Business Unit OUT Instead of Merging Everything In

TL;DR

• A carve-out (divestiture) extracts one business unit's identities and data into its own new tenant — the opposite direction from consolidating everyone into an existing tenant.
• Microsoft offers no native "tenant split" feature; the supported method is a scoped tenant-to-tenant migration of only the divested unit.
• Carve-outs run under Transitional Service Agreement (TSA) boundaries with hard end dates, typically needing six to eighteen months.
• The defining challenge is separation, not just movement: cleanly disentangling shared identities, groups, sites, and licenses.
• Consolidation, carve-out, and rebranding are three different migrations with different risks — choose the pattern that matches the business event.

Two directions, one platform

When a company restructures its Microsoft 365 estate, the instinct is often to think in one direction: bring everyone into a single tenant. That is consolidation — the natural pattern after a merger or acquisition, where the acquired organization is absorbed into the parent (or "sub") tenant.

But there is an equally important and very different scenario: moving a business unit out of an existing tenant into its own. That is a carve-out, and it is what a divestiture demands — when a division is sold, spun off, or separated, its people and data must leave the parent tenant and stand up independently, rather than everything collapsing inward.

Getting the direction right matters because the two are not mirror images. M&A consolidation, carve-out divestiture, and rebranding are three fundamentally different migrations, with distinct risks, timeline pressures, and governance implications. Picking the wrong mental model is one of the most expensive mistakes you can make early.

Why "just consolidate into the subtenant" is often wrong for a divestiture

It is tempting, when a structure already includes a parent and a sub-tenant, to treat every change as "migrate everything into the sub-tenant." For a divestiture, that is backwards. The divested unit is leaving the corporate group — it cannot remain entangled in the parent's identity plane, compliance boundary, and licensing agreement. Forcing its data deeper into a shared tenant creates exactly the entanglement the divestiture exists to undo.

The correct pattern is a carve-out: stand up a new, independent target tenant for the divested unit and perform a scoped tenant-to-tenant migration of only that unit's users and data, then sever the connection. You move out what belongs to the unit, rather than pulling everyone into one place.

There is no native "tenant split"

A crucial constraint: Microsoft does not provide a native "tenant split" feature. You cannot click a button to cleave one tenant into two. The recommended approach is a tenant-to-tenant migration — scoped to the carved-out population — using the same toolset as any T2T project: the native Migration Orchestrator (Exchange mailboxes, OneDrive, Teams chats) plus third-party tools for SharePoint sites and Teams channels.

The difference from a normal migration is the scoping and separation discipline: you migrate a precise subset and you must cleanly disentangle it from everything that stays behind.

flowchart LR
    subgraph Parent[Parent / sub tenant - stays]
      P1[Retained users + data]
      Shared[(Shared groups, sites, licenses)]
    end
    subgraph New[New independent tenant - divested unit]
      N1[Carved-out users]
      N2[Their mailboxes, OneDrive, sites]
    end
    Shared -.must be cleanly separated.-> P1
    Shared -.scoped slice.-> New
    P1 -.sever B2B + sharing.-> New

TSA boundaries and the clock

Divestitures rarely run on a comfortable timeline. Carve-out divestiture projects operate under Transitional Service Agreement (TSA) boundaries and need six to eighteen months with hard end dates. A TSA is the contractual arrangement under which the seller keeps providing services (including IT) to the divested unit for a limited period — and when it expires, the separation must be complete. There is no slipping the date.

That hard deadline reshapes how you plan:

• Work backward from the TSA end date. Everything is scheduled against a fixed finish line.
• Sequence by business criticality. Migrate in waves so the divested unit keeps operating throughout — manufacturing, sales, logistics, and finance must keep running, not merely "email works."
• Build security and compliance in from day one in the new tenant, because there is no time for a cleanup phase before the TSA lapses.

The separation challenge nobody budgets enough for

In a consolidation, the hard problem is collision (two of everything). In a carve-out, the hard problem is separation — untangling assets that were built assuming one shared organization:

• Shared groups and distribution lists spanning retained and divested users.
• SharePoint sites and Teams with mixed membership.
• Shared mailboxes, calendars, and delegated access across the boundary.
• Licensing that must be re-provisioned, not transferred.
• External sharing and B2B links that need to be re-pointed or revoked.
• Data ownership — what legally and operationally belongs to the divested unit, and only that.

Under-scoping this is the classic carve-out failure. The migration tooling moves data competently; deciding what moves, what stays, and how to cut the threads between them is the real project.

A carve-out playbook

1. Confirm the pattern. Is this truly a divestiture (out) or a consolidation (in)? The answer sets the entire direction.
2. Stand up the new independent tenant. Identity, domains, Conditional Access, labels, and licensing for the divested unit.
3. Scope ruthlessly. Define exactly which users, mailboxes, sites, and data belong to the unit — and nothing else.
4. Map the entanglements. Inventory every shared group, site, mailbox, and B2B link crossing the boundary, and decide its fate.
5. Migrate in waves under the TSA clock. Native Orchestrator for mail/OneDrive/chat, third-party tooling for SharePoint/channels, sequenced by criticality.
6. Sever cleanly. Remove cross-tenant sharing, B2B access, and residual permissions so the separation is real.
7. Validate and certify before the TSA ends. Prove the divested unit operates independently with the deadline still ahead of you.

The bottom line

When a business event restructures your Microsoft 365 estate, the first decision is direction: are you pulling everyone into a tenant (consolidation) or moving a unit out into its own (carve-out)? For a divestiture, the answer is almost always carve-out — and forcing everything into the existing sub-tenant is the wrong move. Microsoft gives you no native split, so you run a scoped tenant-to-tenant migration under a hard TSA deadline, and you treat clean separation — not data movement — as the core of the work. Plan it that way and a carve-out becomes a controlled program instead of a deadline emergency.

Further reading

• Microsoft 365 Tenant-to-Tenant Migration: A CIO Framework (Damco)
• Tenant Split (Microsoft Q&A)
• Microsoft 365 tenant-to-tenant migrations (Microsoft Learn)

Image credit: Tony Webster via Wikimedia Commons (CC BY 2.0).