Carve-out Complexities: Why Tech Separations Cost More Than the Deal Model Says
Introduction
$\rm\LARGE{C}$arve-outs are not new. Companies sell divisions all the time, and private equity has built entire playbooks around buying the unloved unit of a large company and running it better on its own.
So why write about them? Because carve-outs of tech businesses are a different animal. In an industrial carve-out, you can at least walk the plant, count the forklifts and draw a line on the floor. In a tech carve-out, the business you are buying runs on servers it does not own, ships code that sits in the parent’s repositories, stores its customers’ data in the parent’s warehouse, and serves customers whose contracts were signed by the parent.
Wait a minute; isn’t a carve-out just the acquisition of a smaller company? Not quite. When you buy a whole company, you buy its back office too: its finance team, its payroll, its security, its ERP, its cloud account. When you carve out a division, none of that comes with it. You are buying the engine without the car.
The public examples are well known. eBay and PayPal separated in 2015. HP split itself into HP Inc. and Hewlett Packard Enterprise the same year. IBM spun off Kyndryl in 2021, with a transition services agreement between the two companies. These were spin-offs, so no buyer priced them, yet each still had to split shared systems, data and contracts. A private equity carve-out has the same problem, plus a buyer who knows less than the seller.
I ask: Why do tech carve-outs take longer and cost more than the deal model assumes?
Claim
My claim is that four complexities explain most of the gap:
i) The standalone cost is estimated by the party that knows the least.
ii) The transition services agreement (TSA) is an incomplete contract, and incomplete contracts invite hold-up.
iii) Code, data and customer contracts are entangled in ways that physical assets are not.
iv) Stranded costs stay with the seller, but they shape the price everyone pays.
In the next section, I will discuss each one in detail.
The Complexities
1. The standalone cost is estimated by the party that knows the least
In diligence, the first number everyone wants is simple to state: what will this business cost to run on its own?
The parent’s books do not answer it. They show allocated costs: a share of IT, HR, finance, legal, security and rent, split by some key such as headcount or revenue. Allocation is accounting. It tells you how the parent divided the bill, and nothing about what the business will need to buy once it leaves. In the standalone cost models I have built in private equity diligence, the gap usually comes from three places:
- Lost volume discounts. The parent negotiated software licenses, cloud commitments and benefits at its own scale. The carved-out business pays list price, or close to it.
- Functions that never existed at the division level. Treasury, tax, internal audit, a board, a security operations center, its own ERP instance. Someone has to build them, and someone has to run them.
- Its own technology stack. Identity and access management, endpoint security, monitoring, backups. These were shared services yesterday; tomorrow they are line items.
In this illustration, a business that costs 100 on the parent’s books costs 137 to run alone, before any one-time separation costs.
Now here is the economics. The seller knows the true cost structure; the buyer sees a data room. This is a textbook information asymmetry problem, and Akerlof’s (1970) market for lemons applies: if buyers cannot tell a cleanly separable business from a tangled one, they discount all of them, and the sellers of clean businesses lose. Sellers respond by producing carve-out financial statements and vendor due diligence. These act as signals in the Spence (1973) sense only when a clean business can produce them more cheaply than a tangled one. In practice that means a standalone cost built bottom-up, function by function, and reconciled to the allocation: a clean business can produce one quickly, and a tangled one cannot do it without exposing the tangle. Scaling the allocation by a percentage and calling it a standalone cost fools nobody who has done this before.
2. The TSA is an incomplete contract
On Day 1, the buyer usually cannot run the business alone, so it rents services back from the parent: hosting, payroll, IT support, sometimes order-to-cash. The vehicle is the transition services agreement, which typically runs for a year or two.
The TSA lists the services. The problem is that nobody can list every service a business consumes from its parent, because half of them are invisible until they stop: a nightly data feed, a shared single sign-on, an internal API that the sales team calls a thousand times a day, a license that was quietly covering both businesses.
Economists have a name for this. Grossman and Hart (1986) and Hart and Moore (1990) showed that when contracts are incomplete, ownership matters, because the owner decides everything the contract left out. Klein, Crawford and Alchian (1978) named the resulting squeeze hold-up. In a TSA, the parent owns the systems, has little reason to give excellent service to a business it has already sold, and knows that the buyer needs an extension far more than the parent needs the fee. Extension pricing tends to reflect that.
It is a bit like moving out of a shared apartment where the Wi-Fi, the electricity and the streaming accounts are all in your former roommate’s name. Everything works on the day you move out. The trouble starts when you need something that was never written down.
The TSA is priced at signing, but the real cost shows up at exit. Buyers should price the exit plan, with likely extensions included.
3. Code, data and contracts do not move like forklifts
An industrial carve-out moves physical assets, and physical assets have a location. A tech carve-out moves things that are shared by design:
- Code. Shared repositories, shared libraries and shared platforms. Who owns the intellectual property in a library both businesses use? Usually the answer is a license-back, and the license terms become one more thing to negotiate.
- Data. Customer data often sits commingled in the parent’s data warehouse. Separating it touches privacy law, customer consents and data retention rules. You cannot simply copy a table and call it done.
- Contracts. Many customer and vendor contracts carry anti-assignment clauses, so moving them needs consent from the other side. Enterprise software licenses are often not transferable at all, and cloud commitments were negotiated at the parent level.
- Certifications. Security attestations such as SOC 2 attach to an environment. A new environment means a new audit, and enterprise customers will ask for it.
- People. The engineers who know how the shared platform works may sit on the parent’s side of the line.
None of these is impossible to solve. Each one takes time, and in a carve-out time is the most expensive input, because every extra month of TSA is a month of paying the parent for services you are trying to replace.
4. Stranded costs stay with the seller, but everyone pays for them
The seller keeps costs that were sized for a bigger company: data center capacity, license tiers, corporate functions that now serve fewer people. These are stranded costs, and on paper they are the seller’s problem.
In practice they leak into the deal. A seller under margin pressure from stranded costs negotiates TSA fees harder, resists long TSAs that tie up its teams, and pushes for a faster separation than the buyer can safely execute. A buyer that ignores the seller’s stranded costs misreads the seller’s incentives, and misreading incentives is how good deals become long negotiations.
What I would do
If I had to compress what carve-out work has taught me into a short list, it would be this:
- Build the standalone cost bottom-up and reconcile it to the allocation. The difference between the two numbers is where the negotiation should start.
- Write the TSA exit plan before signing the TSA. Every service should have an owner, a replacement and a date, and extension pricing should be agreed upfront, while both sides still want the deal.
- Inventory contracts and data early. Consents, non-transferable licenses and privacy constraints are the items most likely to move the closing date.
- Run the separation like a product launch. It has users, dependencies and a release date, and it fails the same way products fail: through the dependency nobody mapped.
Carve-outs sit where corporate finance meets systems engineering. The deal model captures the first half well. The second half is where the money goes.