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

Carve-outs are harder than acquisitions. Not because the technology is more complex — it’s usually the opposite. But because the buyer needs a clean separation while the seller needs to make sure the remainder of the organisation keeps working exactly as it did before.

A UK healthcare system discovered this the hard way when they began preparing a 12,000-employee subsidiary for sale. The carve-out had been announced, the LOI signed, and the integration team was under instructions to deliver a clean separation in 14 weeks. Nobody had told them how much infrastructure the two organisations shared.

The Problem Nobody Mapped

The subsidiary had been part of the parent NHS Trust for eleven years. In that time, it had accumulated all the usual dependencies: a shared Active Directory, shared NHSmail accounts, shared clinical systems on a shared network, shared Azure infrastructure, and — critically — shared data residency obligations under NHS DSP Toolkit requirements.

The buyer’s legal team required a complete inventory of all shared infrastructure, all data flows, all system dependencies, and confirmation that patient data residency requirements would be maintained post-separation. The seller’s IT team had three weeks to produce this before the next legal review.

They didn’t have the data. They had a few network diagrams from 2018 and a whiteboard.

What ACQI Found in the First 48 Hours

ACQI was deployed on Monday morning. By Wednesday, the discovery scan had surfaced:

Identity: 14,200 accounts across the shared AD forest, of which 9,400 belonged to the subsidiary and 4,800 belonged to the parent trust. Group memberships were entangled — subsidiary staff were members of 340 parent-trust security groups, including groups that controlled access to shared clinical systems. Simply de-provisioning the subsidiary accounts would have broken parent-trust access to three production systems.

Application dependencies: 47 applications in the subsidiary’s Azure tenant that depended on shared infrastructure in the parent’s Azure tenant. 12 of those were clinical systems that both organisations used simultaneously. Breaking the shared infrastructure without a migration path would have caused a patient safety incident.

Network: Three direct Azure ExpressRoute connections from the subsidiary’s Azure tenant to the parent’s on-premises data centres. The subsidiary’s production workloads ran on shared vNets. The subsidiary’s disaster recovery was hosted in the parent’s secondary data centre.

Licensing: Microsoft 365 licences assigned to subsidiary staff that were paid for by the parent organisation. SaaS applications (including a radiology management system and a laboratory information system) subscribed to under the parent’s enterprise agreements.

The Seven-Week Separation Plan

The discovery data was handed to the integration team on Thursday morning. What followed was a structured separation that ACQI’s governance layer tracked week by week.

Weeks 1–2: Complete infrastructure mapping. Every shared dependency catalogued, classified by criticality, and assessed for separation complexity. The 12 shared clinical systems were identified as the critical path — they couldn’t be migrated, only remediated with credential changes and network segmentation.

Weeks 3–4: Parallel workstream execution. Active Directory split into two forests using a domain carve-out approach. Azure infrastructure cloned rather than moved — the subsidiary’s production workloads were replicated into a new Azure tenant before the cutover, leaving the parent’s environment untouched. This was the decision that made the 14-week timeline achievable.

Weeks 5–8: Credential and access migration. All subsidiary user accounts migrated to the new forest. Microsoft 365 licences transferred to the new tenant. The 12 shared clinical systems received new credentials scoped exclusively to the subsidiary. Network segmentation enforced at the Azure vNet level.

Weeks 9–12: Testing and validation. Every subsidiary system tested in isolation. Access from the parent organisation explicitly revoked and tested. NHS DSP Toolkit compliance re-attested for the new infrastructure. DR infrastructure rebuilt in a separate Azure region from the parent.

Weeks 13–14: Cutover and separation. The final cutover was a weekend migration. No parent-trust systems were touched. Subsidiary staff arrived Monday morning to a fully functional, fully independent IT environment. All 12,000 staff had their credentials, applications, and access working correctly by 09:00 on Day 1 of independence.

The Three Decisions That Almost Went Wrong

1. The AD Forest Split

The integration team’s initial plan was to use a full domain separation — migrating all subsidiary users to a new forest and leaving the parent untouched. This is the standard approach. It also would have taken 20 weeks.

ACQI’s discovery data showed that the subsidiary’s user accounts had accumulated 11 years of technical debt — duplicate SPNs, circular group memberships, and stale accounts that hadn’t been deprovisioned properly. A full migration would have migrated all of that into the new forest.

The decision was made to do a clean-room AD build — create fresh accounts for all 9,400 subsidiary users, map them to their correct entitlements using ACQI’s group membership data, and run both environments in parallel for two weeks. Risky, but it eliminated 11 years of AD debt in one migration.

2. The Clinical Systems Problem

Two of the 12 shared clinical systems couldn’t be migrated or replicated — they were SaaS applications hosted by third-party NHS suppliers who had only one tenant and no migration path. The only option was credential and network scoping: new credentials for the subsidiary, network-level isolation to prevent the parent from accessing the subsidiary’s data instances.

This required the clinical systems team to work with three separate NHS-approved SaaS suppliers simultaneously to change authentication configurations and verify data isolation. ACQI tracked the status of all three vendor engagements in the governance layer alongside the infrastructure migration.

3. The DSP Toolkit Clock

NHS DSP Toolkit compliance requires organisations to attest to data processing controls annually. The carve-out had created a situation where the new standalone entity needed to attest by a specific deadline — 16 weeks from the announcement. The previous attestation had covered the shared infrastructure.

With 14 weeks for the carve-out and a 16-week compliance deadline, there was a two-week buffer. That buffer disappeared when one of the clinical system vendors pushed their credential migration by two weeks.

ACQI’s governance layer flagged this as an amber risk in week 8. The integration team had two weeks to escalate to the NHS Digital team and request an extension on the DSP Toolkit attestation timeline. The extension was granted with 48 hours to spare.

What Made This Different

Most carve-out failures happen because the separation is planned from the seller’s perspective. The seller’s IT team builds a plan that keeps the remainder working, then tries to figure out how to give the buyer something functional.

This carve-out worked because the discovery data was available on day one. The integration team could see exactly what was shared, exactly how entangled it was, and exactly what the minimum viable separation looked like. The buyer received a clean environment. The seller kept everything they needed.

The 14-week timeline was aggressive. The ACQI discovery scan made it achievable.

ACQI is the M&A Discovery, Migration, and Governance platform. 124 modules. Complete clarity before you separate. Learn more →