Stranded software costs in a carve out, and how buyers recover them.

Stranded software costs in a carve out are the licence fees, minimum commitments and shared platform charges that stay behind when a business unit separates from its parent, draining the new entity from day one while no one is fully using what is being paid for. They are one of the most predictable and most overlooked drains on value in a separation, and they are almost always recoverable once they are measured.

What stranded software costs in a carve out actually are

When a parent company sells or spins out a business unit, the software estate does not divide along the same line as the org chart. Enterprise agreements were negotiated for the whole company. Volume tiers, minimum commitments and bundled entitlements were sized for combined demand. The moment the carved out unit leaves, that sizing is wrong on both sides. The parent keeps paying for capacity that walked out the door. The new entity inherits charges for tools it can no longer access, or pays the parent to keep using them through a transition services agreement. The gap between what is paid and what is used is the stranded cost.

Standard financial diligence rarely isolates this number. Quality of earnings work captures the historical software spend as a single line, not the portion that becomes dead weight after separation. That is why stranded cost lands as a surprise in the first budget cycle after close, when the new finance team reconciles invoices against an estate they do not yet fully understand.

Where the cost hides

Stranded cost is not one item. It is a layer made of several distinct problems, each with its own remedy. The enterprise agreement minimum is the largest and least visible. A parent with a multiyear Microsoft, Oracle or SAP commitment sized that floor against the full headcount and infrastructure of the combined business. When the unit leaves, the parent is still obligated to the floor and the new entity has no contract at all, so it either signs a fresh agreement at list price or pays the parent to sublicense during the TSA. Both routes cost more than the steady state should.

Orphaned seats and instances are the next layer. Named user licences, virtual machines and database options that supported the carved out unit remain provisioned and billed under the parent paper for months after operational control changes hands. Shared platform licensing is the hardest to untangle, because a single Oracle or SAP estate cannot be cut in half without re measuring deployed usage against entitlement on both sides. The publishers know this, and a carve out is a well documented trigger for an audit on either company.

Mapping these sources early is the core of our carve out and TSA separation service. The same discipline underpins the wider carve out and TSA software playbook, which sequences every separation workstream that touches software.

A composite example of stranded cost in practice

Consider a private equity backed buyer acquiring a 900 person software unit carved out of a global manufacturer. On paper the unit software run rate looked modest, because the parent allocated cost on a per head basis. In reality the unit ran on a shared Oracle database estate, a group wide Microsoft enterprise agreement and a SAP instance sized for the parent ten times its size. When the deal closed, three things happened at once. The parent kept paying its enterprise minimums, now oversized for the demand that had left. The new entity began paying TSA pass through fees for the same Oracle and SAP access. And a duplicated set of monitoring and security tools, bought independently by both sides, kept renewing on autopilot.

None of this appeared in the quality of earnings model, which showed a single steady software line. The stranded layer only became visible when the new finance team reconciled the first two quarters of invoices against an estate it could finally see. By then a meaningful share of the spend had already been sunk into tools and commitments serving no live user. The lesson is not that the numbers were wrong, but that the wrong unit of measurement was used. Allocated cost hides stranding. Only a deployment to entitlement reconciliation, run against the carved out unit specifically, exposes it.

The cost framing matters for the investment case too. Stranded software cost behaves like a recurring leak, not a one off charge. Every month it persists, it compounds against the synergy targets underwritten at deal approval. Treating it as recoverable cost with an owner and a date, rather than fixed background spend, is what turns a quiet drain into a measurable contribution to the return.

How buyers quantify and recover it

The recoverable number comes from a deployment to entitlement reconciliation scoped to the separation. We pull the actual deployment data for the carved out unit, match it to the contracts that will govern the new entity, and isolate every charge that supports no live user or system. That figure becomes a recovery target with an owner and a date, not a vague concern. In most rollouts the largest single recovery is renegotiating or reassigning the enterprise agreement minimum, because that is where the parent sizing and the new demand diverge most sharply.

Timing matters. The window to fix stranded cost cheaply is the TSA period, while both sides still have a contractual relationship and the publisher relationships are warm. Once the TSA ends and the new entity is on standalone paper, every correction becomes a fresh negotiation from a weaker position. This is why we treat stranded cost reduction as part of the TSA exit timeline and software critical path, not a cleanup item for later.

Related reading across the cluster includes separating shared software licenses, the risk of double licensing, and re licensing the carved out business from scratch.