The TSA software catalog lists every service the parent provides after close. Here is how to itemise, rebase and price it on the buyer side.
A TSA software service catalog and pricing schedule is the part of a transition services agreement that lists every software service the parent will provide to the carved out business after close, with a unit of charge against each, and it is one of the most negotiable and most overlooked documents in the deal. The TSA software service catalog and pricing determines what the new entity pays for borrowed access to applications, licenses, support and infrastructure during the transition, how fast those charges can be turned off, and how much margin the parent earns while the new entity migrates to standalone.
Every software service in the catalog exists because a dependency could not be severed by day one. The catalog is therefore a direct mirror of the dependency map, and its total cost is a function of how much the new entity still relies on the parent. Two pricing risks sit inside it. The first is that the charges are sized for the combined business, so a seat count, a capacity tier or a license band reflects the old scale rather than standalone demand, and the new entity pays for more than it uses. The second is that the catalog is bundled, so a high cost service the new entity wants to exit early is tied to a low cost service it still needs, and the bundle prevents a clean reduction. A catalog that is itemised, rebased and structured to allow early exit protects the buyer on both counts.
Pricing also shapes behaviour. A parent that earns a healthy margin on the catalog has little incentive to help the new entity leave quickly, while a buyer that has negotiated reducing charges and exit credits has a parent aligned to a clean and timely exit. The catalog is where that alignment is built or lost, which is why it deserves the same scrutiny as the purchase price.
A well built catalog separates four service categories, each with its own unit of charge. Application hosting and run is charged per application per month, so the new entity can exit applications one by one as it migrates. License pass through is charged at the parent unit cost, ideally without a margin, because the parent is simply extending its own entitlement. End user support is charged per seat per month, rebased to the standalone headcount rather than the combined one. Infrastructure and platform is charged per unit of capacity, sized for standalone load. The diagram shows how these build to a total, and the table sets out the watch point on each line. A catalog that mixes these into a single monthly fee hides exactly the levers a buyer needs to pull.
Several levers turn a catalog from a parent friendly schedule into a balanced one. Itemisation is the first, because a buyer cannot manage what it cannot see, and a per service price is the precondition for early exit. Exit flexibility is the second, the right to turn off any service on reasonable notice and stop paying for it, ideally with a defined exit credit. Margin transparency is the third, because license pass through should be at cost and any uplift on hosting or support should be visible and justified. Rebasing is the fourth, so that seat counts, capacity and license bands reflect standalone demand from day one. A duration and step down schedule is the fifth, where charges fall as the new entity migrates, which keeps the parent aligned to a prompt exit. These levers connect directly to the TSA exit timeline and software critical path and the cost discipline in stranded software costs.
The license pass through line is where catalog pricing meets audit risk. When the parent extends its own licenses to the new entity through the TSA, the parent must hold valid entitlement for that extended use, or the arrangement itself can create an exposure for both parties. A buyer should require the parent to warrant valid licensing for any software in the pass through, which links the catalog to the broader carve out software audit risk for both sides. Building the catalog well is part of our carve out and TSA separation service and the wider carve out and TSA software playbook. As always, the catalog is a commercial document, and interpretation of its legal terms belongs with the buyer own counsel.
Several catalog errors recur, and each carries a price. The most common is accepting a single blended monthly fee, which feels simple but removes every lever the buyer needs and leaves the new entity paying full freight until the last service ends. The second is signing up to a minimum term with no early exit, which ties the new entity to charges it cannot reduce even after it has migrated off a service. The third is allowing open ended time and materials rates for project and exit assistance, which can quietly become one of the largest lines on the bill as the parent supports the very migration that ends its revenue. The fourth is failing to define what happens at the end of each service, leaving data extraction, knowledge transfer and final cutover support undefined, which the parent can then charge for or decline.
Each of these has a counter that costs nothing to negotiate before signing and a great deal to fix afterward. Insist on a per service price, a notice based exit on every line, capped or fixed rates for exit assistance, and a defined end of service deliverable for each application that names the data the new entity receives and the support it can expect through cutover. A buyer should also build a charge down schedule into the catalog from the start, so the total falls automatically as services are exited, rather than relying on a renegotiation each time the new entity wants to reduce its bill.
It helps to model the catalog over its expected life rather than reading it as a monthly figure. Multiply each line by the months the new entity realistically needs it, layer in the migration cost of replacing it, and the true cost of the transition becomes visible. That model frequently shows that a slightly higher one time investment to exit a service early is cheaper than carrying its monthly charge for the full TSA, which is the kind of insight that only a fully itemised catalog can deliver.
| Service line | Unit of charge | Watch point for the buyer |
|---|---|---|
| Application hosting and run | Per application per month | Bundled apps that hide a low usage candidate to exit early |
| License pass through | Parent unit cost plus margin | Margin or uplift charged on top of the license fee |
| End user support | Per seat per month | Seat count not rebased to the standalone headcount |
| Infrastructure and platform | Per unit of capacity | Capacity sized for combined load, not standalone |
| Project and exit assistance | Time and materials | Open ended rates with no cap on the migration help |
We itemise, rebase and pressure test the catalog so the new entity pays standalone prices and can exit each service cleanly as it migrates.
Request a carve out software assessment