Transition Services Agreement: What It Covers and How to Scope It

A transition services agreement, or TSA, is a contract under which the seller of a business keeps delivering operational services to that business after closing, typically for 6 to 24 months at a price set in the agreement. It exists because a divested business almost never runs on its own the day the deal closes. Its email, ERP access, payroll processing, and help desk all sit inside the parent. A TSA rents those services back so the deal can close before the separation is finished. The agreements that work are specific: every service named, priced, owned by a person on each side, measured against a standard, and given an exit date. Everything left vague becomes cost with no obvious way to stop it.

Why a TSA exists at all

Deals close on legal and financing timelines. Separation runs on system timelines, and the two are rarely within a year of each other. Signing to close commonly takes 3 to 6 months. Pulling a business unit out of a shared ERP instance, a shared identity directory, and a shared network takes 12 to 36 months, which we cover in detail in our guide to the IT carve-out. Nobody is willing to hold the purchase price hostage to a data migration, so the parties bridge the gap contractually. The seller keeps the lights on for a business it no longer owns, the buyer pays for it, and both sides commit to a date when it ends.

That sequence explains most of what goes wrong later. The TSA is negotiated during the deal by people whose job is to close, and it is lived with afterward by operations people who were not in the room. Whatever was left imprecise at signing turns into an argument in month seven, when the seller's team has been reassigned and the buyer's replacement systems are still in build.

What services a TSA covers

Six functions carry most TSA scope, and IT carries the largest share of it. IT services usually include hosting and infrastructure, network connectivity, email and collaboration, identity and access management, access to the parent's applications, help desk, security monitoring, and backup and recovery. This is the longest workstream and the one that gates the others, because most other functions cannot leave the TSA until their underlying system moves.

Payroll and HR covers payroll processing, benefits administration until the buyer's own plans are live, access to the HR information system, and time and attendance. Payroll deserves separate attention in planning because it is the one service where a failure is visible to every employee on the same morning, and because benefit plan transitions are governed by enrollment calendars that do not move for deal timelines.

Finance and accounting covers accounts payable and receivable processing, general ledger access, treasury and banking connectivity, tax filings and compliance support, and month-end close support. Procurement covers purchasing under the parent's supplier contracts, vendor management, and supplier payments, and it carries a specific trap: many supplier contracts do not assign to the buyer, so the TSA is often the only legal path to continued supply while new agreements are papered. Facilities covers shared sites, subleases, physical security, mail, and environmental and safety services. Customer support covers the contact center, the ticketing platform, phone routing, and warranty and returns handling, all of which are visible to the divested business's customers if they break.

How long TSAs run, and why they overrun

A common structure is a 12-month base term with extension rights in 3 or 6 month increments out to 24 months. Simple separations, where the business already had its own applications and shared only email, identity, and network, run 6 to 9 months. Deeply entangled ones, where a single ERP instance and commingled customer data are involved, run 18 to 36 months and need the extension rights from day one.

Overruns are predictable and have four repeat causes. The term gets set against the legal calendar rather than the separation plan, so a 12-month TSA is signed against an 18-month IT program and both sides know it. Scope gets discovered after close, because the entangled-asset inventory was never built, and newly found services are bought back at extension pricing. The buyer under-resources its replacement build, since the service is still arriving and the urgency is not felt. And the schedule contains no acceptance test, so no one can prove a service is finished and the invoice keeps running. The mechanics of getting off a TSA on schedule are involved enough that we treat them separately in TSA exit planning.

How a TSA gets priced

Two pricing models cover most agreements. Cost passes through the seller's direct cost of delivering the service with no markup, which is common where the seller wants no appearance of profiting from the buyer and where the service is short-lived. Cost-plus adds a markup of roughly 5 to 10 percent for management overhead, and it is the more common structure. Some services, particularly per-seat items like email or help desk, get priced as a fixed monthly fee per unit instead.

The structural point matters more than the model. Price every service on its own line rather than bundling the TSA into a single monthly fee. Under a bundled fee, a buyer who exits four of twelve services pays the same invoice as before, which removes the financial reason to finish anything early. Under service-level pricing, the fee steps down as each service terminates, and the buyer captures the savings from work its own team did. That step-down is what turns the exit plan into something the buyer's finance function will fund and track.

Extension pricing runs the other direction. Escalators of 10 to 25 percent per extension period are standard, and they exist because the seller wants its own teams to stop running two companies. Two other pricing items are worth settling at signing rather than later: any one-time exit assistance fee, such as data extraction or migration support, which is priced badly when the buyer requests it under deadline, and whether the seller may recover any of its stranded cost through the TSA rate, which is a separate negotiation and should be named as one.

What belongs in a service schedule

The schedules are where TSAs succeed or fail. The master agreement is largely standard and gets drafted in a few weeks. The schedules take months, get the least senior attention, and determine what actually happens after close.

Each service needs seven things: a description written at the level of the work performed, a named owner on the seller side and a named counterpart on the buyer side, a service level with a measurable standard, a price, a term with a specific exit date, an acceptance test that defines what finished means, and a list of the dependencies that must be resolved before exit is possible. Granularity should follow exit independence. One line per service that can be terminated on its own. Listing "payroll" as a single line is wrong when US payroll can move in month 6 and the UK entity needs 14 months, because the two exits get chained to the slower one.

A schedule becomes useless in four specific ways, and all four show up in real agreements. Services are described so vaguely that nobody can tell when one is complete, as with a line that reads "IT support" and nothing else. There is no acceptance test, so exit becomes a matter of opinion between two parties with opposite incentives. There is no named owner on either side, so questions route to whoever answers email. And there is no exit date, which converts a bridge into an open-ended subscription. A schedule with those four defects is a recurring invoice with no defined end.

Reverse TSAs

A reverse TSA runs the other way: the buyer provides services back to the seller. It applies whenever the divested business held capability the parent still needs, and that is more common than deal teams expect. A plant inside the carve-out perimeter may manufacture a component the parent still sells. A shared service center staffed by the divested business may process transactions for the retained business. A regulated entity going with the buyer may hold the license the parent still operates under in that country. Software written by the divested engineering team may run in the parent's environment.

Reverse services are usually discovered after close, which means the buyer negotiates them at a moment when the seller has already been paid and the buyer has nothing left to trade. Build the reverse schedule on the same calendar as the forward one, using the same seven fields, and price it the same way.

Governance and dispute handling

Name a service manager on each side for each functional area, hold a monthly operating review per function, and stand up a joint steering committee that meets at least monthly with authority to approve changes. Set an escalation ladder with time limits at each rung: service managers first, then the steering committee, then named executive sponsors, then formal dispute resolution. Without time limits, escalation becomes a way to stall.

Most TSA disputes are about two questions: whether something is in scope, and whether the fee covers this much of it. Handle both with a written change request process that prices the change before work begins, and require the seller to give notice before performing out-of-scope work rather than surfacing it on an invoice 60 days later. Give the buyer termination for convenience on a per-service basis with 30 to 60 days' notice, so finishing early is actually possible, and give the seller a defined remedy if the buyer terminates a service and then asks for it back.

What to nail down before you sign

The following items are cheap to settle during negotiation and expensive to settle after close.

• A complete service inventory. Built from the entangled-asset list, not from a template. Services discovered after close are bought at the seller's price.
• A term set by the separation plan. The CIO's estimate, not the closing calendar, should drive the base term and the extension rights.
• Service-level pricing with a step-down. The invoice must fall as services terminate, or nothing terminates.
• An acceptance test per service. Written so exit is provable rather than argued.
• Named owners on both sides. One person accountable per service per side, in the schedule, by name and role.
• Exit assistance priced now. Data extraction, migration support, and parallel-run periods, quoted before the buyer needs them.
• Buyer termination for convenience. Per service, with a short notice period.
• The reverse schedule. Everything the buyer will owe the seller after close, on the same terms.

Where BD Emerson fits

We build TSA scope and schedules on the sell side and pressure-test them on the buy side through our transition services agreement advisory practice, as part of broader carve-out advisory work. The first deliverable is always the same: an inventory of what the two businesses actually share, service by service, because every credible term, price, and exit date is derived from it. Get that built before the schedules are drafted, and the TSA becomes a plan with an end date instead of a bill that keeps arriving.