The transition services agreement keeps the acquired unit running after close. Software is the heart of it, and scoping it well controls both cost and exit.
What is a TSA and how software fits in is the first question every buyer asks when a deal is structured as a carve out, because the transition services agreement is what keeps the acquired unit running on the day after close. A TSA is a contract under which the seller continues to provide named services to the carved out business for a fixed period after the deal completes, in exchange for a fee, so the unit does not go dark the moment it leaves the parent. Software sits at the heart of almost every TSA, because the unit depends on the parent for identity, hosting, core applications, support and data flows that cannot all be rebuilt by day one. Understanding how software fits into the TSA is what lets a buyer control both the cost and the exit.
A transition services agreement exists because separation takes longer than the deal timetable. The parties want to close on a date driven by commercial and financial logic, but the operational work of moving a business unit onto its own systems takes months. The TSA bridges that gap. The parent keeps running the services the unit cannot yet provide for itself, and the unit pays for them, until each service is handed over. Software is the dominant category in that bridge because nearly everything the unit does runs on an application, a directory or an integration that belongs to the parent. Identity, the finance system, the data warehouse, the service desk and the network all tend to sit on the parent side at close, and each one is a TSA line until the new entity can take it over.
For the buyer the TSA is a double edged tool. Used well it removes the risk of a business going dark on day one and buys time to stand up a clean estate. Used badly it becomes an expensive dependence that drags on, with the parent setting the price and the new entity unable to leave. The buyer side discipline is to scope the software in the TSA precisely, price each service, and set a hard exit date for every line, so the bridge is a temporary structure rather than a permanent crutch. This work connects directly to the carve out software licensing playbook, where the TSA scope is stage four.
Software in a TSA tends to fall into five categories. Identity and access covers the directory, single sign on and the accounts every application authenticates against. Hosting and infrastructure covers the data centre, cloud tenancy and network the unit runs on. Core applications cover the ERP, finance and HR systems, usually running on parent licenses that the unit has no standalone right to use. Support and operations cover the service desk, run teams and the runbooks that keep everything alive. Data and reporting cover the warehouse, the integrations and the feeds that produce the unit numbers. The table sets out what the parent provides in each category and what the new entity has to build to replace it.
Each category carries its own lead time and its own licensing trap. Core applications are the most dangerous, because running them under the parent license during the TSA can itself be a licensing breach unless the TSA terms explicitly permit it, and because the new entity has to re license or replace them before exit. Identity carries the longest lead time, because every user and service account has to move to a new tenant before access can be cut over. Scoping each category honestly is what turns the TSA from a vague safety net into a sequenced exit plan, the subject of the TSA exit timeline and software critical path.
Software is what makes a TSA cost more and run longer than buyers expect. The parent prices TSA services to cover its cost and its inconvenience, and software services are labour intensive to provide for a business that is supposed to be leaving. Worse, the parent licenses that the unit runs on during the TSA usually cannot be extended indefinitely, so there is a hard limit on how long the bridge can hold even if the new entity is not ready. And every month the unit spends on parent software is a month in which a publisher could argue the entitlement was never properly transferred, which is why a long TSA quietly raises audit risk. Inherited and unresolved licensing of exactly this kind is what produces post deal publisher claims, the same exposure that lay behind SAP pursuing Anheuser Busch InBev for a reported 600 million dollars, as reported in trade coverage as of 2017.
The buyer answer is to treat the TSA as a countdown, not a comfort. Every software line should have a defined owner, a defined exit date and a defined replacement, so the unit is migrating off parent software from day one rather than settling into it. The faster the exit, the lower the cost and the lower the audit risk. This is why the TSA scope and the new entity standup are planned together, as set out in standing up the new entity software estate.
A well scoped software TSA starts from the dependency map, lists every service the unit needs from the parent, and for each one records the service description, the price, the duration and the exit trigger. Vague descriptions are the enemy, because a line that says hosting can mean anything, and the parent will interpret it narrowly while charging broadly. Each service should be specific enough that both sides know exactly what is provided and when it ends. Pricing should be agreed up front, not left to be negotiated under pressure later, and exit dates should be firm with the option to extend rather than open ended with the hope of leaving. Building the TSA this way is part of our carve out and TSA separation service and the wider carve out playbook.
Software does not only flow from parent to unit. In many carve outs some systems sit inside the business being sold, and the parent still depends on them after close, which produces a reverse TSA in which the new entity provides services back to the parent. This matters to the buyer because providing services to the former parent ties up the new entity own people and licenses, and because the parent use of software that now belongs to the unit has to be covered by a right to use, or it becomes the parent unlicensed use on the unit contracts. Mapping both directions of dependence is part of doing the TSA properly, and missing the reverse flows is a common way a separation runs over time and cost.
Whichever direction a service flows, the principle is the same. Every service needs a description, a price, a duration and an exit, and every use of software across the boundary needs a license right behind it. A TSA built on that discipline gives both sides a clean, time boxed bridge to full independence. A TSA built on vague promises and open ended dates becomes the thing that quietly keeps two separated businesses entangled long after the deal was supposed to have closed.
| Service category | What the parent provides | What the new entity must build |
|---|---|---|
| Identity and access | Directory, single sign on, accounts | Own tenant and migrated users |
| Hosting and infrastructure | Data centre, cloud, network | Own environment or new contracts |
| Core applications | ERP, finance, HR on parent licenses | Re licensed or replaced applications |
| Support and operations | Service desk, run teams, runbooks | Own support model and knowledge |
| Data and reporting | Warehouse, integrations, feeds | Rebuilt interfaces to own systems |
We scope the software inside the TSA line by line so every service has a price, a duration and a firm exit, and the new entity is never trapped on parent systems.
Request a carve out software assessment