SAP
In a divestiture or an acquisition, the IT separation plan is priced into the deal
– Sep 10, 2026
The IT separation plan is priced into the deal whether or not anyone has scoped it. Estimates built from different data converge late, and late is expensive; for the seller at the table, for the buyer after closing.
Why the systems end up in the price
A buyer acquires the business, not the systems it has been running on. The ERP (SAP, Dynamics, NetSuite), the interfaces, the reporting layer and the infrastructure beneath them were all built for the parent company: shared with the rest of the group and licensed under a single group-wide agreement. All of it has to be rebuilt for a legal entity that does not yet exist.
Both parties put a number on that work during diligence. The seller allocates historical IT cost to the divested unit in the carve-out financials, usually on a simple basis such as headcount or revenue.
The buyer estimates something different:
what this business will actually pay to license, host and support systems of its own once the shared arrangement ends?
The difference between those two figures is the standalone cost gap, and it gets settled somewhere. In the purchase price, in the transition services agreement, or in the first year of the new entity’s operating budget.
There is no side to take here. A gap discovered late erodes value for the seller at the negotiating table and creates continuity risk for the buyer after closing. Both parties are better served by working from the same technical picture, built early enough to still be useful.
The transition services agreement sets the clock
The transition services agreement, or TSA, is the bridge. The seller keeps providing access to its systems for a defined period, for a fee, while the new entity builds its own. It exists because full separation before closing is almost never realistic.
The difficulty is that TSA terms are usually negotiated before anyone has scoped the technical work. Duration gets set from a plausible assumption rather than an assessment, and neither side has staffed the replacement build at the moment of signing. Some things that consistently help:
| Price and exit each service separately. A single bundled monthly fee removes any incentive to exit fast-moving systems early and chains the whole transition to the slowest one. | Set the duration from an assessment, not a calendar. Data volumes, interface count, custom code and archived documents drive the timeline far more than deal size does. | Define what exit means for each service. Acceptance criteria, who signs, and what happens to the data afterwards. |
| Agree extension terms up front. With a defined price and process. An extension should be a decision, not a dispute. | Address knowledge retention. The people who know the legacy systems are often redeployed or leave during the transition, exactly when the receiving entity needs them most. | Start long-lead items at signing. Licence transfer for the new legal entity, identity and access management, and network circuits all run on external timelines. These are calendar problems, not budget problems. |
Where estimates usually slip
Two patterns come up often enough to be worth planning around.
Rebuilding what exists rather than designing what is needed. The instinct is to copy the parent landscape and remove what does not belong. It is fast to describe and slow to deliver. The new entity inherits an architecture sized for a much larger organisation and carries that cost structure permanently. The copy also contains information the receiving entity has no basis to hold: personal data of employees who never transferred, and commercial data belonging to businesses that were not part of the transaction. Purging it properly is real work with a real duration, and it belongs in the plan from the start.
The distance between workstreams. A separation is at minimum four parallel efforts: data extraction, application and interface work, licensing for the new entity, and the target infrastructure. Capable specialists exist for each. The schedule risk sits in the dependencies between them. Extraction scope has to match licensing scope, which has to match what the environment build assumed. Cutover weekend tests every one of those assumptions at the same time. This is not a question of vendor quality. It is what happens when four good plans are managed as four plans.
What tends to work
01 — Assess before the terms are fixed. Company codes, data volumes, interfaces, custom developments, archived documents. The output is a defensible cost model and a transition period that reflects the work rather than the hope.
────────
02 — Design for the entity being created. The separation is the only moment when the target architecture is genuinely open. It is usually the cheapest opportunity the business will ever have to modernise, and the easiest one to miss.
────────
03 — Run licensing in parallel. A new legal entity needs its own agreements and its own bill of materials. Started late, this becomes a quiet and entirely avoidable cause of a missed go-live date.
────────
04 — Give the programme one owner. Select tools and partners against the scope rather than the other way round and hold them to a single plan under a single accountability. The client should have one point of contact and one party answerable for the result.
oXya works on both sides of these transactions. We run the initial technical assessment, assemble and govern the specialist partners a separation requires, handle licensing and the bill of materials with the vendor for the new entity, and in most cases operate the resulting landscape afterwards. We stay deliberately neutral on tooling and select proven, certified products according to what each landscape actually needs.
If a transaction is on your horizon and the systems question is still open, a technical assessment is the cheapest line item on the deal and, quite often, the one with the best return.
Frequently asked questions
What is a carve-out in IT terms?
The technical separation of a divested business unit’s data, applications and infrastructure out of a shared landscape and into a standalone environment for the new entity.
What is the standalone cost gap?
The difference between the IT costs allocated to a business unit in carve-out financial statements and the actual recurring cost of running that business on its own systems, licences and support arrangements.
How long does a TSA usually run?
Typically, between six and twenty-four months, though the realistic duration depends on data volume, interface complexity and licensing rather than on any standard term.
What are the most common causes of TSA extensions?
Licence transfer negotiations, identity and access management rebuilds, network circuit lead times, and bundled TSA pricing that removes the incentive to exit individual services early.
