Divestitures are M&A in reverse. Instead of putting two things together, you’re taking one thing apart.
The IT challenge is the same complexity as an integration — but with a tighter deadline and higher consequences. In an integration, users can tolerate some disruption. In a separation, the divested entity needs a fully functional, fully independent IT environment on Day 1 — with no shared infrastructure to the parent.
This is harder than it sounds. Most companies that undergo divestiture have had years to interweave their IT infrastructure. The systems that support the divested entity are embedded in the parent company’s AD, Azure AD, M365 tenant, network, and applications.
The IT Carve-Out Discovery Framework
Before you can plan the separation, you need to know what needs to be separated.
Phase 1: Discovery — What Belongs to the Divested Entity?
The first question in any carve-out: what assets, systems, and people are being transferred? The IT answer requires:
Application ownership mapping: Which applications does the divested entity’s employees use? Which are owned by the parent, which are owned by the divested entity, which are shared? The ACQI SaaS discovery module answers this — it observes what applications the divested entity’s users actually authenticate to, not what the org chart says they use.
Data residency: Where does the divested entity’s data live? In shared databases? In shared SaaS applications? In shared file servers? The data has to be identified before it can be separated.
Network dependencies: Does the divested entity’s network have any dependencies on the parent’s network? VPNs, DNS resolution, DHCP, internal web applications? These dependencies need to be eliminated before Day 1 — not discovered on Day 1.
Phase 2: Separation Architecture — What Does the Divested Entity Need?
A fully functional IT environment for the divested entity requires:
Identity: A new AD forest (or at minimum, a new Azure AD tenant). Users can’t remain in the parent’s Azure AD — that creates data security and compliance issues.
Productivity: A new M365 tenant (or equivalent). The divested entity needs its own email, Teams, SharePoint.
Applications: Each application needs to be either:
- (a) Migrated to a standalone instance owned by the divested entity
- (b) Replaced with a functionally equivalent application owned by the divested entity
- (c) Decommissioned and replaced with a different tool
Network: The divested entity needs its own internet connection, DNS, DHCP, and internal network — fully independent from the parent.
The 5 Hardest Carve-Out Problems
Problem 1: Shared SaaS Applications
The parent company uses Salesforce for CRM. The divested entity also uses Salesforce — they’re on the same Salesforce org, with different business units as the segmentation. The data is shared.
On Day 1, the divested entity needs their data extracted from Salesforce, their users moved to a new Salesforce org, and their integrations rebuilt in the new org.
This takes 60-90 days minimum. It requires a Salesforce data extraction specialist, a sandbox for the data extract, and a migration of the data to the new org.
ACQI’s contribution: Identifies which SaaS applications are shared and estimates the data volume and complexity of the extraction. This becomes the SaaS migration timeline.
Problem 2: The Domain Name Problem
The divested entity’s email domain is a subdomain of the parent’s domain (e.g., division.parent.com). After separation, they need their own domain. This means:
- New email domain
- Updated DNS for all web properties
- Updated SSO configurations for all SaaS applications
- User training on the new domain
Problem 3: The Service Account Problem
Every internal application in the divested entity uses service accounts in the parent’s AD. These service accounts are being decommissioned on Day 1. The divested entity’s applications need new service accounts, with new credentials, in the new AD environment.
If the application was built internally by the parent, the source code needs to be modified to use the new credentials. If it’s a vendor application, the vendor needs to reconfigure the application in their system.
Problem 4: The Contract Problem
Vendor contracts for the divested entity’s IT infrastructure are in the parent’s name. The parent is legally responsible to the vendor. The divested entity needs to either:
- Be added as a party to the existing contract (if the vendor allows it)
- Negotiate a new contract with the vendor (60-90 day sales cycle typically)
- Use a different vendor
Most IT carve-outs have at least 3-4 vendor contracts that need to be transferred or replaced — and each one is a 60-90 day process.
Problem 5: The Regulatory Problem
If the divested entity is in a regulated industry (financial services, healthcare, defense), the separation creates new regulatory obligations. The divested entity needs its own regulatory compliance posture — which means its own audits, its own certifications, and its own compliance documentation.
This is the most time-consuming part of any regulated carve-out. A financial services carve-out that doesn’t account for 12-18 months of regulatory separation work is setting false expectations.
The IT Carve-Out Timeline
Pre-Signing (Due Diligence Phase):
- Discovery scan of the divested entity’s IT environment (ACQI, full 89 modules)
- Separation architecture design
- Contract inventory and transfer plan
- Regulatory separation assessment
Signing to Day 1 (60-120 days):
- Build new IT environment for the divested entity
- Migrate applications and data
- Set up new vendor relationships
- User cutover preparation and testing
Day 1:
- Cut over to new environment
- Verify all systems functional
- Monitor for 72 hours for issues
Day 30 to Day 180:
- Decommission shared infrastructure from the parent’s environment
- Monitor for any remaining dependencies
- Complete data migration verification
Day 180 to Year 1:
- Complete regulatory separation
- Finalize vendor contract transfers
- Optimization and toolchain simplification
The Carve-Out IT Checklist
Discovery (pre-signing)
- Full ACQI discovery scan of the divested entity’s IT estate
- Application ownership map: parent vs. divested entity vs. shared
- Data residency map: where the divested entity’s data lives
- Network dependency map: any network connections to parent’s environment
- Contract inventory: all IT vendor contracts, which party they are with
Architecture (pre-signing)
- Design the divested entity’s standalone IT environment
- Plan the identity migration: new AD, new Azure AD tenant, new M365 tenant
- Identify applications that must be migrated vs. replaced
Execution (post-signing)
- Build new IT environment (typically 60-90 days)
- Migrate users and data
- Set up new vendor relationships
- Run parallel operations: both environments running simultaneously until Day 1
Day 1
- Cut over: disconnect from parent’s IT environment
- Verify: all systems functional in the divested entity’s new environment
- Monitor: 72-hour critical systems watch
Post-Day 1
- Decommission: remove divested entity’s access from parent’s IT systems
- Verify: confirm no shared infrastructure remaining
- Finalize: all vendor contracts transferred to divested entity