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 consolidation.
• There is still no "split this tenant" button, but Microsoft now names Tenant Move/Split as a supported orchestrator model and ships two native lanes: the orchestrator for per-user content, Cross-Tenant Shared Data Migration for SharePoint sites.
• Mailboxes on any type of hold are blocked from migrating. Find your holds in week one, not week twenty.
• Carve-outs run to a Transitional Service Agreement (TSA) deadline — typically six to eighteen months — and that window is an identity architecture, not a contract.
• The defining challenge is separation, not movement: cross-boundary delegation, mixed-membership Teams, and compliance history that cannot follow the data.

Two directions, and when to pick the harder one

When a company restructures its Microsoft 365 estate, the instinct runs one way: bring everyone into a single tenant. That is consolidation, the pattern after a merger. Moving a business unit out into its own tenant is the opposite — a carve-out, and what a divestiture demands.

The two are not mirror images, and picking the wrong model early is expensive: the divested unit cannot stay inside the parent's identity plane, compliance boundary, and licensing agreement, so pushing its data deeper into a shared tenant creates exactly the entanglement the divestiture exists to undo.

Four conditions push decisively toward a carve-out. Regulatory separation is the strongest — where a regulator or the sale agreement requires two demonstrably separate controllers, a shared tenant with clever permissions does not qualify, because separation you can prove beats separation you can describe. A hard TSA end date is second, since a shared tenant has no natural terminal event. Data residency is third: if the buyer's obligations put data somewhere your tenant does not serve, no policy work inside the parent fixes it. Incompatible security postures is fourth — one Conditional Access estate cannot honour two device-compliance standards without becoming the weaker of them.

Check the cloud boundary before you commit to a date. Cross-cloud tenant-to-tenant migration is not supported — Worldwide to GCC High, DoD, or 21Vianet has no native path at all. If that is your buyer, the carve-out becomes a bespoke export-and-import programme, and you want to discover that in due diligence rather than month four.

Then count the cost honestly. A second tenant is a second Conditional Access estate, a second licensing agreement, a second set of privileged roles, and permanent B2B friction wherever the two organizations still work together. If the "divested" unit is really a rebrand that stays in the group, a carve-out buys nothing but overhead.

What the native tooling actually covers in 2026

A claim worth correcting: Microsoft has no native tenant split. Half true. No operation cleaves one tenant into two, and a carve-out is still a scoped tenant-to-tenant migration of the divested population only. But Microsoft's migration orchestrator documentation now lists Tenant Move/Split — "a subset of users is moved to a new tenant while others remain" — as a supported model, naming divestiture as its driver. Two native lanes exist, licensed and operated separately:

• Migration orchestrator — Exchange mailboxes, OneDrive, Teams chats, Teams meetings. Licensed as Cross-Tenant User Data Migration, a per-user one-time fee assignable on either side. Meetings cannot be selected without chats and mailboxes in the same batch.
• Cross-Tenant Shared Data Migration — SharePoint sites, from SharePoint Online PowerShell. Enterprise Agreement customers only, licensed per 100 GB moved.
• Still no native lane — Teams and channels. The orchestrator states shared data "remains in the source tenant," and the SharePoint lane moves a Teams-connected site's content without the team, its channels, or its structure.

Two properties shape the whole plan. The orchestrator moves content, not identities — you create every target account yourself, and identity mapping is a prerequisite. And SharePoint and OneDrive moves are one-and-done: content moves, a redirect is left behind, and delta passes cannot be performed. There is no "sync now, cut over later" for files.

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

The mechanics match our tenant-to-tenant migration guide. What makes a carve-out different is the scoping and the severing.

The TSA window is an identity architecture

A TSA is the contract under which the seller keeps providing services, IT included, to the divested unit for a limited period. Carve-outs typically need six to eighteen months, and when it expires the separation must be complete. Everything schedules backwards from that date and sequences by business criticality — manufacturing, sales, logistics, and finance must keep running, not merely "email works."

The window is really a three-phase identity design, drawn before day one.

During the window, divested staff still need parent-tenant resources they have no replacement for yet. Model that with cross-tenant access settings in Entra ID: add the new tenant as an organizational configuration on both sides rather than loosening your defaults, scope inbound and outbound access to named groups and applications, and configure trust settings so the parent's Conditional Access accepts MFA, compliant-device, and hybrid-joined claims already satisfied at home. Skip that and you re-prompt hundreds of people for MFA they have just done. Trust settings and per-user scoping need Entra ID P1 in the tenant you configure.

Two details quietly break real projects. Automatic redemption suppresses the consent prompt only when set outbound in the home tenant and inbound in the resource tenant. And if your outbound default blocks all applications, nobody can read mail protected with Office 365 Message Encryption unless you allow app ID 00000012-0000-0000-c000-000000000000.

Mail keeps flowing because of how a mailbox move finishes: the source mailbox is deleted, the source user becomes a MailUser, and its targetAddress is stamped with the routing address in the new tenant. That MailUser is also what you remove, or convert to a contact, when the TSA ends.

Ending the window is a deliberate act, not an expiry. Remove the organizational cross-tenant configuration, revoke residual guests both ways, re-point or delete external sharing links, and use tenant restrictions to stop managed devices signing in to the other tenant with accounts you no longer control. Cross-tenant access settings are protected actions, so gate them behind their own Conditional Access policy and nobody reopens the door later. One trap throughout: Entra sign-in logs are commonly kept for only 30 days, so evidence of who crossed the boundary has to be collected from kick-off.

Identity: the sequence that does not break access

The order of operations is unforgiving: the orchestrator refuses to start when the target object is wrong.

Each in-scope user must exist in the target tenant as a MailUser — mail-enabled, no mailbox — before identity mapping runs, and that holds even when you are not moving mailboxes. On that object you stamp ExchangeGUID, ArchiveGUID where the source has an archive, and the source LegacyExchangeDN as an x500: proxy address, plus every existing x500 address from the source mailbox. Miss those and replies to pre-migration mail fail with a 5.1.1 NDR while Outlook's autocomplete cache stops resolving your own colleagues.

Guest accounts need their own decision. A B2B guest object is an artefact of the tenant that invited it: guests do not migrate, and invitations the parent issued do not follow the divested unit. Inventory every third party the unit works with, decide which relationships transfer, and re-invite them from the new tenant.

The inventory that predicts pain

Data volume is not what makes a carve-out slip. Entanglement is, and most of it is discoverable before day one.

Cross-boundary delegation is the sharpest edge. Cross-tenant mailbox and calendar permissions are not supported; principals and delegates must be batched together so connected mailboxes transition at once. If an assistant stays with the parent and the executive is divested, nothing preserves that relationship. Send-on-behalf rights are worse — they live in the directory, do not move at all, and must be re-stamped on the target with Set-Mailbox -GrantSendOnBehalfTo. Shared mailboxes move, but only their store permissions come with them.

Enumerate it before you scope waves:

# Run in the source tenant; $divested holds the carved-out population's UPNs.
$divested = Get-Content .\divested-users.txt

# 1. Delegation crossing the boundary - each pair needs a verdict.
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    $mbx = $_
    Get-MailboxPermission $mbx.Identity |
        Where-Object { -not $_.IsInherited -and $_.User -notlike 'NT AUTHORITY\*' } |
        Where-Object { ($divested -contains $mbx.PrimarySmtpAddress) -ne ($divested -contains $_.User) }
}

# 2. Holds block the move entirely - count them before promising a date.
Get-Mailbox -ResultSize Unlimited |
    Where-Object { $_.LitigationHoldEnabled -or $_.InPlaceHolds -or $_.ComplianceTagHoldApplied } |
    Select-Object PrimarySmtpAddress, LitigationHoldEnabled, InPlaceHolds

The rest follows the same pattern — find what spans the boundary:

• Teams with mixed membership. Nothing native moves a team, so each is a keep, rebuild, or export decision — the inventory in our Teams and Groups sprawl playbook is the one you wish you had built two years ago.
• SharePoint sites with cross-entity permissions. Users and groups must be pre-created in the target and mapped or permissions do not survive, so start from a real permissions picture. Sites carry hard ceilings too: 5 TB or 1 million items each, a 400-character limit on the new path, and no pre-existing target site.
• Encryption and labelling blockers. Purview Customer Key on the source tenant fails a SharePoint migration outright, and sites holding sensitivity labels with user-defined permissions cannot migrate until those labels are stripped.
• Licence re-provisioning, not transfer. Licences do not move between tenants; the new tenant needs its own agreement and assignments before cutover, plus the per-user migration licence on one side.
• Mailbox quota and archives. Mailboxes near quota fail mid-move, and auto-expanding archives are supported only to 12 auxiliary archives — one provisioned during the move fails that user.

What does not move — be honest about it early

Put this list in front of legal and compliance in week one — several items are policy decisions, not technical ones.

• Mailboxes on any type of hold are blocked. Litigation hold, In-Place Hold, or a retention label hold stops the move, and Microsoft's guidance is to engage engineering first. Releasing a hold to unblock a migration is a legal decision, never an IT convenience.
• Compliance and audit history stays behind, then evaporates. After a mailbox migrates, the source tenant cannot run eDiscovery against it — there is no mailbox left to search. If the seller needs a copy, it must be moved to an alternate mailbox before migration. A pre-day-one decision with a deadline.
• Retention hold provenance does not travel. The new tenant starts with a clean compliance ledger; policies, labels, and their history are re-created, not inherited — the gap our backup and retention guide covers for ordinary operations, with no earlier state to fall back on.
• Teams chat history is copied, not moved. Chats migrate while the original remains in the source, possibly edited, with participant lists changed and duplicate threads on both sides. Chat messages are never deleted from the source tenant — a data-remanence question for the sale agreement, not a migration detail.
• Label protection, workflows, and the small stuff. Protection attached to a sensitivity label is gone after a SharePoint move; 2010/2013 workflows must be republished, Power Apps and Power Automate flows rebuilt, cross-site web parts reworked. The Teams chat folder inside the mailbox, mailbox signatures, and Outbox items do not migrate either.

A phased carve-out sequence

Before day one, decide: which cloud the buyer operates in; what happens to every mailbox on hold; whether the seller keeps a pre-migration copy of any mailbox for eDiscovery; who owns each mixed-membership Team and site; and what the TSA end date obliges you to have finished.

1. Confirm the pattern. Divestiture (out) or consolidation (in)? That sets everything else.
2. Stand up the target tenant. Domains, Conditional Access, labels, retention, licensing — configured before data lands, from a tenant hardening baseline rather than invented under deadline.
3. Scope, then inventory the boundary. Delegation pairs, holds, mixed Teams, cross-entity site permissions, external sharing, B2B relationships — every crossing gets an owner and a verdict.
4. Design the TSA window. Cross-tenant access settings, trust settings, automatic redemption both ways, mail routing — each with a written plan for switching it off.
5. Pre-create identities and map them. MailUser objects carrying the GUIDs and x500 addresses; users and groups pre-created for SharePoint identity mapping.
6. Migrate in waves by criticality. Batches of no more than roughly 2,000 mailboxes, submitted well ahead of cutover, with all of a user's workloads together.
7. Sever deliberately. Remove the cross-tenant configuration, revoke guests, retire source MailUsers, apply tenant restrictions, gate the settings behind protected actions.
8. Certify before the TSA ends, with the deadline still ahead of you and evidence to hand the other side.

The bottom line

The first decision is direction: pulling everyone into a tenant, or moving a unit out into its own. For a divestiture the answer is almost always carve-out, and Microsoft now supports that shape explicitly. But the tooling only moves what it moves. Holds block mailboxes, Teams and channels have no native path, compliance history does not follow the data, and the TSA window is an identity architecture you design and then dismantle on purpose. Do that work in due diligence and a carve-out is a controlled programme; leave it to month four and the deadline runs the project.

Further reading

• Migration orchestrator overview (Microsoft Learn)
• Cross-tenant mailbox migration (Microsoft Learn)
• Cross-tenant SharePoint site migration overview (Microsoft Learn)
• Cross-tenant access overview (Microsoft Entra External ID)
• Plan a Microsoft 365 tenant-to-tenant migration (Microsoft Learn)

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