Divestiture Email Migration: Carving Out a Business Unit

A divestiture compresses two years of normal IT planning into the window between deal signing and closing. The business unit being carved out needs its own email tenant, its own identity provider, and a clean break from the parent's data — all while still operating as part of the parent right up until the closing date. Get it wrong and you delay the deal, breach the purchase agreement, or accidentally ship privileged data across the wall. This is how to scope and execute a divestiture email migration without producing a litigation event.

What makes a divestiture different from a normal tenant move#

A standard tenant-to-tenant migration is hard but bounded. You own both sides, you control the timeline, and the worst case is a delayed cutover.

A divestiture adds four constraints that change every decision:

A closing date that doesn't move. The deal closes when the lawyers say it closes. Mail must be in a working state on day one for the carved-out business. You don't get to slip a weekend.

Two legal entities with different counsel. Decisions that look operational often have legal implications. Which legal holds transfer? Who owns mail sent during the diligence period? Both legal teams need to agree, and they often don't.

An information barrier during the deal. Until closing, the buyer cannot see seller data they shouldn't. Until closing, the seller's IT can't grant the buyer's IT direct access. Most of the prep work happens in parallel without the two teams sharing infrastructure.

A Transition Services Agreement. Almost every deal includes a TSA where the seller continues providing IT services (often including email) for some months after closing. The migration becomes a two-phase project: prepare for day one operation under TSA, then cut to standalone before the TSA expires.

The first 30 days: scoping and segmentation#

Once the deal is announced internally and a clean team is formed, the email work has 30 days to produce a defensible scope. That output drives staffing, licensing, and the TSA negotiation.

Build the in-scope user list#

The deal team gives you a list of employees moving with the divested business. You join that list against your directory and produce a master spreadsheet with these columns per user: employee ID, current UPN, current primary SMTP, mailbox size, last login, archive size, mobile devices, shared mailbox memberships, distribution group memberships, delegated permissions held, delegated permissions granted, group memberships in Microsoft 365 groups and Teams, OneDrive size, and an in-scope flag.

That spreadsheet becomes the source of truth for everything downstream. The mistake people make is keeping it in their head or scattering it across emails. Pin one spreadsheet, version it, and make every change traceable.

Inventory shared and functional mailboxes#

Shared mailboxes are where divestitures get messy. A support@oldco.com mailbox might have been used by both the retained and divested teams. A legal@ mailbox almost certainly has content that belongs only with the seller. A sales@ mailbox might be the lifeblood of the divested business.

For each shared mailbox, decide one of four outcomes:

• Goes entirely with the buyer (copied or moved, then deprovisioned from the seller)
• Stays entirely with the seller (no transfer)
• Splits by date or content (legal review required)
• Cloned with read-only export to the buyer (most common compromise)

Inventory data classification#

The mail you migrate to the buyer must be in scope under the purchase agreement. Mail that belongs to retained business — board minutes, M&A pipeline, retained-customer relationships — must not be transferred. Most agreements include a representation that the seller will not transfer "Excluded Assets," and personally addressed mail can fall into that category.

In practice this means you do not migrate the seller's CEO's mailbox to the buyer, even if the CEO is technically "moving" with the business. You migrate only the role-based content that belongs to the divested entity. The deal documents should specify what's in scope; if they don't, escalate.

Identity: the hardest part#

In a normal migration, identity is a coordination problem. In a divestiture, it is a forensic problem. You are splitting a single directory into two directories whose members must never overlap and whose history must remain auditable.

The clean-room directory build#

The buyer's tenant gets a fresh directory built from the in-scope user list. UPNs use the new domain (which the buyer has registered as part of the deal). Group memberships are recreated from the source, but only the in-scope groups. Conditional access policies are rewritten from scratch — copying the seller's CA policies often pulls in references to retained-side groups and creates ghost dependencies.

The seller-side cleanup#

In the seller's tenant, the divested users are eventually disabled (not deleted — see legal hold considerations below). Group memberships are stripped. Shared mailbox permissions are revoked. License is reclaimed. This happens at cutover, not before.

Federation during the TSA#

If the deal has a TSA where users continue using the seller's tenant after closing, you create a clear technical boundary. Common patterns:

• The divested users move into a separate OU or tenant within the seller's organization with restricted policies.
• Conditional access blocks the divested users from accessing retained-side resources.
• Information barriers (in Microsoft 365) prevent the divested and retained populations from messaging each other in Teams.
• Email continues to flow but with the new domain stamped on outbound messages.

The TSA defines how long this state lasts. During the TSA, you build the buyer's standalone tenant. At TSA expiry, you cut from the seller's tenant to the buyer's.

Data segmentation: the rules of the road#

The migration team needs unambiguous rules for what data crosses the wall and what doesn't.

What goes with the buyer#

• Mailbox content of in-scope users, scoped to mail relevant to the divested business
• Shared mailboxes designated for the divested business
• Distribution lists used by the divested business
• Teams and channels associated with the divested business
• OneDrive content of in-scope users, subject to the same scope rules

What stays with the seller#

• Mail of retained employees, even where it references the divested business
• Records subject to seller-side legal holds (a copy may go to buyer; the hold stays)
• Mail with privileged communications from seller's counsel
• Board, executive, and M&A pipeline content
• Audit logs of the seller's tenant (a scoped export for the buyer is possible)

What gets cloned with restrictions#

• Shared mailboxes used by both sides, with the seller retaining the source of truth
• Distribution lists with mixed membership (recreated on each side with relevant members)
• Vendor and partner contact lists, where appropriate

Legal hold preservation: the part you cannot get wrong#

Legal holds are court orders or administrative orders requiring you to preserve specific data. They follow strict rules and survive any IT transformation. In a divestiture they create real complexity because the data may need to be in two places at once.

The default rule: the legal hold stays where the obligation lives. If the seller is under a hold related to litigation that affects the divested business, the hold stays on the seller's side. The seller preserves the data in place (Exchange Online inactive mailbox, retention policy, or third-party archive). A working copy of the mail can still move to the buyer for operational continuity.

Document the chain of custody. Every migration job that touches held data needs a record of when it ran, what was copied, what was excluded, and where the original lives. Treat that documentation as part of the deliverable to legal.

For the broader picture of how compliance plays into any migration, the email migration compliance guide covers retention, hold, and audit log requirements in detail.

The cutover sequence#

Most divestiture cutovers are staged: closing day, TSA period, then standalone cutover.

Closing day (T-0)#

The deal closes. The divested business is legally separate. From an IT perspective:

• Information barriers go into effect inside the seller's tenant if you are using TSA
• The new legal entity name is added to email signatures
• Outbound mail begins stamping the new domain (if owned by buyer at closing)
• External-facing systems display the new brand
• Mail continues to flow on existing infrastructure under the TSA

Closing day is intentionally quiet from a technical perspective. The big moves happen later.

TSA build phase#

During the TSA, the buyer's team builds their tenant. Mailbox migration runs in waves from the seller's tenant to the buyer's. Identity is rebuilt. SaaS apps are re-provisioned against the new tenant. The buyer's team validates each wave before approving the next.

Standalone cutover#

When the buyer is ready and the TSA permits, you flip:

1. Final delta migration of any mail since the last sync
2. MX cutover of the new domain from seller's inbound to buyer's inbound
3. SPF, DKIM, and DMARC updates pointing to the buyer's tenant
4. Disabling of seller-side user accounts for divested employees
5. Revocation of shared mailbox and resource access
6. Closing of inbound mail flow from seller to buyer

The cutover window is typically 24 to 48 hours. Plan it across a weekend, with a Sunday-night go/no-go review.

Working under deal pressure#

A divestiture timeline is set by lawyers and bankers. They do not care that your migration tool needs a maintenance window or that Microsoft has throttling limits. Three patterns help you absorb the pressure.

Run waves in parallel where you can. Don't wait for wave 1 to finish before starting wave 2 prep. Build a pipeline where mailbox extraction, transformation, and loading happen continuously, with quality gates between stages.

Pre-stage everything you can before closing. The buyer's tenant can be fully built before the deal closes. Identity can be staged with disabled accounts. DNS can be pre-published with low TTLs. The closing day itself becomes a flip of a few switches, not a full build.

Have a "minimum viable" definition of done. Day one for the divested business needs inbound mail working, outbound mail working, and calendar working. Archive search, mobile autoconfig polish, and Teams chat history are nice-to-haves that can land later. Negotiate this with the business explicitly.

If the divestiture is paired with a separate rebrand of the carved-out entity, the domain change email migration runbook covers the DNS and identity sequencing for that piece.

The first 90 days after cutover#

The divested business is live. The work continues:

• Daily monitoring of bounce rates and DMARC reports for the new domain
• Resolution of vendor allowlist issues as they emerge
• Continued mail forwarding from seller to buyer for any user who was missed
• Closeout of the TSA, with documented sign-off on every category of service
• Final audit of the seller's tenant to confirm divested-business data is either preserved under hold or deleted per policy
• Handover of documentation to the buyer's ongoing IT team

The complete email migration guide covers the operational aftermath of any migration; a divestiture adds the layer of legal documentation that auditors and the deal team will eventually ask for.

What to put in the runbook before closing day#

A divestiture runbook is read by lawyers, by the deal team, and by IT operators at 2 AM. It needs to satisfy all three audiences.

The essentials:

• Master in-scope user list, version controlled
• Data segmentation rules, signed off by both legal teams
• Migration tool configuration with throttle limits and concurrency settings
• Rollback criteria and rollback procedures
• TSA scope and termination criteria
• Legal hold inventory with chain-of-custody documentation
• Per-wave success criteria
• Contact list for closing-day escalations on both sides

Build it during the 30-day scoping window and update it weekly. The buyer's IT team will inherit it on day one, and it becomes their reference until the TSA closes.