Microsoft 365 Divestiture and Carve-Out Tenant Separation

You get the program layer: read-only discovery across the source tenant, the separation register that says what leaves and what stays with a signature against each line, the target and domain design, the Day-1 identity and licensing plan, the coexistence design and its teardown, the sequenced wave plan, cutover coordination across both tenants, the parent-side de-provisioning runbook and its execution evidence, and the TSA-exit evidence pack. Quoted on top: each per-workload migration at its published price, the target tenant build, any third-party migrator, and Microsoft's own licences. From $7,500 is the floor for a single-source, single-target carve-out of about 100-2,000 seats; you get a fixed written quote before work starts.

No. There is no operation that divides a Microsoft 365 tenant — the job people still search for as an Office 365 tenant separation or a tenant split — and there is no way to detach a business unit with its data intact. A carve-out is always: stand up or extend a target tenant, move the objects that belong to the divested business through the cross-tenant mechanisms each workload supports, re-create the configuration that cannot move, and then remove the access that should no longer exist in the parent. The program layer exists because those steps have dependencies on each other and on dates you do not control.

A custom domain can be verified in only one Microsoft 365 tenant at a time, so it has to be removed from the source tenant before it can be verified in the target — which means every object in the source that references it has to be dealt with first, and the cutover is a dated event the rest of the plan sequences around. Mail continuity through that window is designed explicitly: routing from the source side while mailboxes still live there, spooling where inbound mail must never bounce, and the target's mail flow verified before the switch. If the divested business is rebranding instead, the new namespace is stood up in advance and the old addresses keep receiving for as long as the TSA requires.

They stop, until counsel decides. Microsoft's documentation states that mailboxes on any type of hold are not migrated and the move is blocked, and that OneDrive accounts with a hold policy applied are blocked too — the documented path is to remove the hold, migrate, and reapply it on the target. In a divestiture that is a legal decision with a preservation obligation attached, and it is usually the parent's counsel who owns it while the buyer wants the data. We inventory every held object in week one, put the options in writing — release and move, retain in the parent and grant access under the TSA, export for the buyer, or exclude from scope — and the wave plan waits for the instruction rather than working around it.

Native cross-tenant mailbox and OneDrive moves need the Cross-Tenant User Data Migration add-on: a one-time, per-user licence that can be assigned on either the source or the target user object and that covers both workloads. Microsoft's documentation states plainly that migrations fail without it and that no exceptions are made. Native cross-tenant SharePoint site migration is licensed separately, per 100 GB of data moved. Coexistence through cross-tenant synchronization or a multitenant organization requires Microsoft Entra ID P1. All of it is bought by you — we quantify it, tell you the lead time, and can quote and provision it as your CSP, but it is billed to you and it is not inside this fee.

Sometimes. Microsoft's cross-tenant SharePoint site migration documentation states that the Cross-Tenant Shared Data Migration feature and its licences are currently available to Enterprise Agreement customers, and that the feature does not migrate Teams content, channels or their structure — a Teams-connected site moves as SharePoint content only. So even where the native path is open to you, Teams itself needs another answer. In practice most CSP estates move SharePoint and Teams on a third-party migrator, which also buys you delta passes that the native one-shot moves do not offer. We confirm what your agreement can actually buy during discovery and price the plan on the answer, not on the assumption.

That is what the coexistence design is for, and it is temporary on purpose. Mail keeps following people because a migrated user's source mailbox converts to a mail user stamped with a routing address; free/busy works across the boundary through an Exchange organization relationship; the other side stays visible in the directory through B2B collaboration or Microsoft Entra cross-tenant synchronization; Teams external access or shared channels cover chat and meetings. Each of those is a live link between two companies that are separating, so each one is built with a removal date, an owner and the evidence to be captured before it goes.

What left, what stayed, and who lost access — with dates. Concretely: the separation register in its final state with every disposition and signature; per-wave migration records with counts and completion dates; the retained list with the reason each item stayed; the access-removal record showing when divested identities were disabled or deleted, when guest and cross-tenant access settings were cleaned up, when the organization relationship and migration endpoints were removed, when credentials were rotated and devices unenrolled; licence reclamation and domain release evidence; and the open-items list with an owner and a date against each. It is written to be handed to your counsel, the buyer's diligence team or an auditor without translation.

About eight weeks is typical for 100-2,000 seats with one source tenant and one target: roughly two weeks of discovery, one to two on the register and the target design, one on coexistence and the wave plan, two to three of waves and cutovers, and the final week on de-provisioning and the evidence pack. The variables that actually move the date are how long the separation decisions take to sign, whether held data has a ruling, when the migration licences arrive, and how much of SharePoint and Teams needs a third-party tool. Your plan is anchored to your close and TSA-exit dates, and if those dates do not fit the scope we say so before we start.

Both are normal and the choice belongs in week three, not week seven. A new tenant gives the divested business a clean identity boundary, its own agreements and no inherited configuration — at the cost of building everything and running it from Day 1. Landing in an acquirer's tenant means the target already has identity, security baselines and a service desk, but the incoming users inherit policies designed for someone else, naming and licensing have to be reconciled, and the acquirer's compliance posture now covers the incoming data. We design for whichever you pick and write down the consequences either way.

The register makes it a decision instead of an argument. The options are: it goes and the parent keeps a copy, it stays and the divested business gets a copy or TSA-period access, it is split by folder or library before the move, or it is exported to the buyer as a dataset rather than a live site. Which one is available depends on the content, on retention and hold, and on what the sale agreement says the buyer is entitled to — so the technical options come from us and the choice comes from your counsel and the business owner, recorded with both signatures.

Channel content and files travel with the Teams migration scope; private and group chats are a separate move with real, documented limits, which is why we scope them explicitly rather than promising them. Two things to plan for at program level: Microsoft documents that Teams chat folder content is not carried by a cross-tenant mailbox move, and that Teams meeting URLs are not updated when items move, so recurring meetings have to be re-created in the target. Users are told that before their wave, not after it.

Entra ID app registrations and enterprise applications are tenant objects — they do not move. Each in-scope application gets a line in the register: re-registered in the target with fresh credentials and consent, re-pointed at the target tenant by its vendor, split because both sides use it, or retired. Client secrets and certificates are re-issued rather than copied, and the parent rotates anything the divested side knew. The re-integration work itself — rebuilding SAML or OpenID Connect trust, splitting a shared SaaS tenant, novating a vendor contract — is named here and quoted separately, because it is application work rather than tenant work.

A new sign-in, and some rebuilding. They authenticate with their new identity in the target tenant; where the domain has not moved with them, their primary address changes and Microsoft's documentation notes that Outlook profiles have to be rebuilt against the new address with the local cache re-downloaded — which is a network-capacity question when a wave lands, and it is in the plan. Signatures are re-created, Teams meetings they own are re-created, and links to files that moved keep working through the redirects the cross-tenant tooling leaves behind at the source until the source tenant is deprovisioned. The communications pack tells them all of this the week before, in plain language.

No, and this one surprises people. Microsoft's documentation states that after a successful cross-tenant mailbox migration the source mailbox is deleted and is not available, discoverable or accessible in the source tenant, and that eDiscovery against that user in the source no longer works because there is no mailbox there to search. If the parent has an obligation to retain that content — and in a regulated industry it usually does — the copy or export happens before the wave, on counsel's instruction. It is the single most common reason a carve-out plan gets re-sequenced late, which is why it is a week-one question here.

Yes — the program is the same discipline whichever side of the transaction engages us, and it works equally when the target is your existing tenant. What changes is where the leverage sits: as the buyer you usually control the target and the deadline but not the source tenant, so the register, the access to run discovery and the hold rulings all depend on the seller's cooperation under the TSA. We say that plainly in the plan and build the dependency into the wave gates. If you are consolidating an acquired tenant into yours rather than receiving a carve-out, that is Microsoft 365 Mergers and Acquisitions Tenant Consolidation.