The problem nobody scopes early enough
In a company sale, the technology comes with the company. In a carve-out it frequently does not, because the division's product sits on a platform the group built and several other products also use.
Buyers understand this. What they will not accept is discovering the extent of it in week six of diligence, after a price has been agreed on the assumption that the technology transfers cleanly.
Four degrees of entanglement
Fully separate. Own repository, own infrastructure account, own team. Rare, and worth a great deal, it widens the buyer field to financial sponsors who cannot absorb technical complexity.
Separate product, shared platform services. The application is distinct but calls group-owned authentication, billing, data pipelines or observability. Workable through transition services plus a defined replacement plan.
Shared monorepo. Code physically intermingled. Separation means an extraction project with real engineering cost, and it needs to be scoped and priced before the process, not during it.
Shared team. Engineers who work across the division and the retained business. This is the hardest of the four, because it is not a technical problem, it is a people problem with a technical consequence.
Scoping the separation
Produce a written separation plan during preparation. It should say, for each dependency: what it is, who owns it, whether it transfers, whether it is replicated, or whether it is provided under a TSA and for how long, with an estimate of the engineering effort and cost for each.
The estimate does not need to be precise. It needs to exist, to be defensible, and to be produced by someone who has looked at the code rather than at an architecture diagram. A buyer's technical diligence will build their own version, and the gap between the two is what gets negotiated.
The infrastructure detail that surprises people
Cloud accounts, DNS, certificates, CI/CD pipelines, secrets management, monitoring, and the dozens of third-party SaaS tools with group-level contracts. Individually trivial; collectively a multi-month workstream that nobody owns until someone is made to own it.
Third-party licences deserve particular attention. Enterprise agreements negotiated at group scale rarely transfer, and the divested business will be re-pricing them as a much smaller customer. That belongs in the standalone cost base.
People: the part that actually decides outcomes
Allocating a shared engineer to one side of a separation is a decision about a person's job, and they will find out. The sequencing matters enormously, decided too early and it leaks; too late and the buyer is presented with an unresolved question about who they are actually acquiring.
The workable pattern is to identify the critical individuals early and confidentially, agree retention arrangements before the process reaches a stage where disclosure is unavoidable, and be able to tell a buyer clearly which named people transfer and what has been done to keep them.
Buyers price this directly. A carve-out where the engineering team is defined and retained is a materially different asset from one where the answer is "we will work that out."
What good preparation buys
Two things. It removes the largest single cause of post-LOI re-trading in technology carve-outs. And it broadens the buyer field, because financial sponsors who would otherwise pass on separation risk can underwrite a plan that is already written.
Both of those show up in the price.
Costing the separation
A buyer will not accept an assertion that separation is straightforward. They will want a plan with numbers.
For each dependency: what it is, who owns it, and whether it transfers, is replicated, or is provided under transition services and for how long. Then an engineering estimate for each, produced by someone who has looked at the code rather than at an architecture diagram.
The estimate does not have to be precise. It has to exist, be defensible, and be built from the actual repository. A buyer's technical diligence will produce their own version, and the difference between the two is what gets negotiated.
Common shape for a division at this size: three to nine months of engineering effort for a shared platform separation, longer where the repository is deeply intermingled. Budget for the work to be done by people who also have a product roadmap, because that is the real constraint.
The infrastructure list nobody writes down
Cloud accounts and billing. DNS and certificates. CI and deployment pipelines. Secrets management. Monitoring and alerting. Error tracking. Analytics. The identity provider. Every third-party service with an API key that exists in one person's account.
Individually trivial. Collectively a multi-month workstream with no owner until somebody is made the owner.
Third-party licences deserve their own line. Enterprise agreements negotiated at group scale rarely transfer, and the divested business re-prices as a much smaller customer. That belongs in the standalone cost model rather than appearing as a surprise in month two.
Sequencing the people decision
Identify the critical individuals early and confidentially. Agree retention before the process reaches a stage where disclosure is unavoidable. Be able to tell a buyer clearly which named people transfer and what has been done to keep them.
The order matters more than the generosity. A well-funded retention package offered after someone has heard a rumour is worth less than a modest one offered by their own manager before they heard anything.
Where an engineer truly splits across both sides, decide which side they go to and accept that the other side needs a plan for the gap. Attempting to share a person across two companies after completion works for about a quarter and then stops working.
Editorial Team · Published for orientation, not as advice on a specific transaction. Any figure cited is orientation, not a valuation. See market notes.