IT Carve-Outs: Separating Technology in a Divestiture

An IT carve-out is the work of separating a divested business's technology from its parent so it can operate on its own systems: applications, infrastructure, identity, data, and the contracts behind them. In almost every divestiture it is the longest and most expensive separation workstream, and it is the one that sets the length of the transition services agreement. Legal can close a deal in months. Pulling a business unit out of a shared ERP, a shared identity directory, and a shared network takes one to three years, costs more than the deal model assumed, and fails in ways customers notice. Buyers price this work, sellers underestimate it, and TSAs exist because neither side can finish it by close.

The TSA clock

A transition services agreement obligates the seller to keep providing services to the divested business after close: email, ERP access, help desk, hosting, security monitoring, payroll processing. TSAs typically run 6 to 24 months, and pricing is designed to expire. A common structure is cost or cost-plus for the base term, then escalators of 10 to 25 percent per extension period, because the seller wants its IT team to stop running two companies.

IT is the long pole for a structural reason: most TSA services are IT services, and the other functions exit the TSA only when their systems do. Payroll leaves the TSA when the HR system separates. Finance leaves when the ERP does. Customer support leaves when the ticketing platform and phone routing move. In practice, the exit plan for the whole TSA is the IT separation plan, which is why the CIO's estimate, not the lawyers' preference, should drive the TSA term. A TSA signed at 12 months against an 18-month separation buys the buyer two extension negotiations from a weak position.

Start with the entangled-asset inventory

Scoping begins with a list of everything the divested business shares with the parent. Five categories dominate the work:

• Shared ERP. The business's orders, inventory, and financials live as company codes and cost centers inside the parent's SAP or Oracle instance. Extraction means a new instance or tenant, a data migration, and a cutover weekend that everyone remembers.
• Identity. Every employee authenticates against the parent's directory and single sign-on. Day 1 requires a new tenant, new accounts, new device enrollment, and re-integration of every application that trusted the old directory.
• Network. Sites sit on the parent's WAN, share firewalls, and route through parent data centers. Separation means new circuits, a new perimeter, and new monitoring, with circuit lead times of 90 to 180 days that land on the critical path.
• Licenses. Enterprise agreements cover both companies on one signature, and most do not transfer. The carved-out business needs its own Microsoft, Salesforce, and database agreements, usually at worse unit pricing than the parent's volume tier.
• Data. Shared warehouses, shared file stores, commingled customer records. Someone must decide what conveys, what stays, what gets copied, and what has to be deleted under customer contracts or privacy law.

The inventory is where deals get repriced, because it converts a one-line "IT separation" assumption into a costed workplan. The same entanglements are what a buyer's technology due diligence team hunts for, so a seller who builds the inventory before the process starts negotiates from its own numbers instead of the buyer's.

Three separation patterns

Clone and go. Copy the parent's environment wholesale, hand the copy to the divested business, then delete what does not convey. It is the fastest path to independence and works when the divested business is a large share of the parent, since the clone is not grossly oversized. The cost comes later: the new company inherits the parent's complexity and license footprint, and the deletion obligation for the data that stayed behind is real legal exposure, not cleanup.

Lift and shift to standalone. Stand up a right-sized environment for the carved-out business and migrate applications and data into it, changing as little as possible about how they work. This is the default pattern for private equity buyers creating a standalone company. It costs more planning than a clone but produces a company sized to itself, with its own contracts and a defensible run-rate cost.

Greenfield build. Build the target environment new, usually cloud-native, and treat separation as forced modernization. It produces the best end state and the longest timeline, so it fits businesses whose legacy estate was the problem, and it needs a TSA long enough to cover the build. The honest framing for a board: greenfield is a transformation program with a divestiture deadline attached.

A strategic acquirer often skips the standalone question entirely and migrates the business straight into its own systems, which turns the carve-out into an integration program. That path has its own discipline, covered by our merger integration practice.

Day 1 versus Day 2

Day 1 scope is what must work the morning after close: people get paid, orders ship, email flows, the business can invoice and collect. Most of Day 1 is delivered by the TSA rather than by actual separation, plus a thin layer of new build items such as the legal entity's payroll, banking connectivity, and branding. Day 2 is the real separation: ERP extraction, identity migration, network cutover, license repapering, data separation. Teams that load modernization into Day 1 miss close dates; teams that treat Day 2 casually live on TSA extensions at escalating rates. The scope line between the two is the single most valuable document in the program.

The seller's stranded cost problem

When the business leaves, its share of IT cost does not leave with it. Data center capacity, enterprise agreements sized to the old headcount, a support organization scaled for both companies: all of it keeps billing the parent. Stranded costs commonly run 20 to 40 percent of the IT cost that had been allocated to the divested business, and they hit the seller's P&L in full when TSA revenue stops. The sellers who avoid the write-down plan the cost takeout as a parallel workstream, renegotiating agreements at the next true-up, consolidating capacity, and resizing the support organization on the same calendar as the separation. Waiting until the TSA ends means paying for a ghost company for another budget cycle.

Timelines by entanglement depth

Ranges that hold up in practice. A lightly entangled business, with its own applications and only shared identity, email, and network, separates in 6 to 9 months. Moderate entanglement, with shared ERP company codes and shared infrastructure but its own product systems, runs 12 to 18 months. Deep entanglement, meaning one ERP instance, shared manufacturing or logistics execution, and commingled customer data, runs 18 to 36 months, and the 24-month TSA with extension rights exists for exactly this case. Three drivers move a deal inside those ranges: how hard the ERP extraction is, how much data separation is a legal obligation rather than housekeeping, and how many enterprise agreements must be renegotiated under deadline, which is when vendors price best against you.

Where deals go wrong

The failure modes repeat. TSA scope gets defined before the asset inventory exists, so services are discovered after close and bought back at extension pricing. Day 1 scope creeps until the close date moves. License transfer has no owner until the first true-up arrives with a seven-figure surprise. Data deletion obligations surface when a customer contract demands proof the seller cannot produce. And the quiet one: the separation is staffed as a side project of the parent's IT team, which is simultaneously losing budget, headcount, and the people who understand the systems being separated. Every one of these is cheaper to prevent in diligence than to fix in month nine.

The financial statements are a different problem

One adjacent workstream gets confused with this one. Carve-out financial statements restate the divested business's history as if it had stood alone, so buyers can price it. That is an accounting and allocation exercise, and we cover it separately in our guide to carve-out financial statements. The IT carve-out is the operational counterpart: the financials describe a standalone company on paper, and the separation program is what makes that company real after close.

Where BD Emerson fits

We run IT separation inside our divestiture consulting practice: entangled-asset inventory, pattern selection, TSA scoping and exit planning, Day 1 readiness, and the stranded cost takeout on the seller side. For buyers evaluating a carve-out target, our technology due diligence work sizes the separation before the price is set, which is when the number still matters. Either way, the first deliverable is the same: an inventory of what is actually shared, because every credible timeline and every TSA term starts there.