The Divestiture Playbook: Carving Out a Business Unit Without Breaking the Remainder

A divestiture is the reverse of an acquisition — and harder in the ways that matter.

In an acquisition, you want to consolidate everything you can. In a divestiture, you need to separate things that were built to work together. The shared Active Directory forest. The joint Exchange organization. The applications that both entities depend on. The regulatory obligations that are entangled across both organizations.

The question isn’t what you want to take — it’s what the buyer needs and what must stay behind.

This is the story of a healthcare technology company that had to carve out a 12,000-employee business unit — containing NHS-facing clinical systems — while keeping the remaining company’s NHS vendor contracts intact.

The Setup

The parent company: a UK-based healthcare technology provider with two divisions.

• Division A (remainder): 8,200 employees, NHS contracts, clinical software, regulated by the CQC and NHS England
• Division B (divested): 12,400 employees, health administration software, European operations

The seller: wanted Division B separated and sold to a PE firm within 16 weeks. The constraint: Division B ran shared infrastructure on the parent company’s Azure tenant and Active Directory forest. Separating them meant extracting Division B from systems they co-owned.

Why Divestitures Break

Divestitures fail in predictable ways:

Shared identity: Division B’s 12,400 identities lived in the same AD forest as Division A. Every user had permissions to shared applications. Splitting the forest without breaking Division A’s NHS audit trail was the central challenge.

Data residency: Division B’s European operations generated personal data under GDPR. Division A’s NHS contracts required that patient data remain in UK data centres. The carve-out couldn’t mix those data sets.

Application entanglement: Division B used 6 applications that were licensed to the parent company and hosted on shared infrastructure. Those licenses needed to transfer to the buyer without disrupting Division A’s operations.

Timeline: 16 weeks. NHS contract reviews take 8-12 weeks. Infrastructure separation takes 6-10 weeks. There was no overlap.

The Discovery Sprint: What ACQI Found

ACQI ran across all parent company infrastructure in Week 1. Parallel discovery across Azure, Active Directory, M365, and on-premises.

Key findings:

The Identity Web

Division B had 12,847 identities across three locations:

• 12,400 employee accounts (active)
• 312 service accounts
• 135 application identities

But 2,847 of those employee accounts were shared accounts — accounts used by multiple people at the same time, a practice the NHS had flagged as a compliance concern during the previous audit.

More critically: 47 of Division B’s service accounts had permissions to Division A’s clinical systems — systems that held NHS patient data. If those service accounts were simply deprovisioned during the carve-out, Division A would lose access to clinical systems it needed to maintain NHS contracts.

The Data Residency Map

Discovery identified 6 Azure data services and 4 M365 workloads that contained Division B personal data alongside Division A operational data. Simply migrating Division B’s VMs to a new subscription wouldn’t clean the data — the underlying storage had to be partitioned.

Three EU-hosted Azure services were found to be processing UK patient record metadata. This was a GDPR violation waiting to happen — the MHRA had been notified of a similar issue at another NHS supplier the previous year.

The License Tangled Web

Six applications shared between both divisions:

• 3 SaaS applications licensed to the parent company, used by both divisions
• 2 on-premises applications hosted on parent company infrastructure
• 1 ERP system running on a shared Azure VM cluster

The license agreements didn’t have assignment provisions. The carve-out team had to negotiate new licenses with vendors while the clock ran.

The Separation Architecture

The integration team used discovery data to design a three-phase separation.

Phase 1: Identity Triage (Weeks 1-4)

Step 1: Provision new Entra ID tenant for Division B ACQI’s Entra ID modules mapped every application registration, service principal, and OAuth grant. The new tenant was provisioned with the correct application registrations pre-created, matching Division B’s actual usage — not a generic migration template.

Step 2: Identity mapping and remediation

For each of the 47 service accounts with cross-division permissions:

• 18 were decommissioned (the application was migrated to Division B)
• 22 were migrated with new credentials scoped to Division A’s systems
• 7 were identified as genuine shared services and retained with proper SLA documentation

For the 2,847 shared accounts: every shared account was converted to a named account or decommissioned. NHS auditors received documentation of the conversion — this became a compliance asset rather than a liability.

Step 3: OU restructuring in the source forest

Division B’s OU structure was carved out of the parent AD forest into a new forest design. ACQI’s AD modules mapped every GPO link, every permission delegation, and every trust relationship so the new forest’s GPOs could be designed before cutover.

Phase 2: Data Separation (Weeks 5-10)

Azure storage partitioning

For each of the 6 Azure data services:

• Data classification scan: which storage blobs contained Division B personal data vs. Division A operational data
• Export of Division B data to new storage accounts in Division B’s Azure subscription
• Verification of remaining Division A data integrity
• Deletion certification for Division B data from Division A storage

Three Azure services required vendor involvement to complete data separation without downtime. Those vendors were engaged in Week 3, before the data separation window — avoiding the last-minute vendor escalation that kills divestiture timelines.

M365 workspace separation

Division B’s M365 tenant was provisioned in Week 5 using ACQI’s M365 discovery data. The team didn’t use Microsoft’s standard tenant-to-tenant migration tools — those tools don’t handle the complexity of shared licensing, cross-tenant mailbox delegates, and Power Platform environment dependencies that ACQI’s discovery uncovered.

Instead, ACQI’s migration views handled the sequence:

• SharePoint sites migrated in dependency order (8 sites, 4 waves)
• Teams migrated with full channel history and settings
• Mailboxes migrated with calendar and delegate permissions preserved
• OneDrive migrated with external sharing links updated to point to new tenant

Phase 3: Cutover and Separation (Weeks 11-14)

The cutover window

Division B’s cutover happened over a single weekend — Friday 11pm to Monday 6am. The window was chosen because:

• NHS systems had lowest utilization on Saturday
• The PE buyer’s financing was contingent on clean separation confirmed by Monday morning
• The parent’s IT team was available for the full window

Division B’s final state at Monday 6am:

• 12,847 identities migrated to new tenant and new AD forest
• All M365 workloads live in Division B’s tenant
• All Azure services migrated to Division B’s subscription
• Zero Division B data remaining in Division A’s infrastructure
• Zero disruption to Division A’s NHS contract systems

Division A’s state at Monday 6am:

• All clinical systems operational
• All NHS audit trails intact
• 8,200 employee identities unchanged
• 18 former shared service accounts decommissioned and replaced

The Results

What Made It Work

Discovery first, architecture second

Most carve-out teams design the separation architecture before they know what they’re separating. The separation architecture for this project was designed after ACQI’s discovery showed exactly what was shared, what was entangled, and what was truly independent. The architecture matched reality because it was built from real data.

Compliance constraints identified in Week 1

The NHS contract implications of shared service accounts were identified in Week 1. This gave the team 13 weeks to design a clean separation before the constraint became a crisis. The previous NHS supplier that had a similar issue discovered it at Week 14 — with no time left to fix it.

Vendor engagement early

Discovery data was shared with the 3 impacted vendors in Week 3, not Week 12. Vendors had time to review, escalate internally, and deliver solutions that actually worked.

ACQI runs full infrastructure discovery in weeks, not months. For divestitures with hard deadlines, that speed is a strategic advantage. Request a demo →