Transition Services Agreement (TSA) Management

Executive summary

A transition services agreement (TSA) is the contract under which a seller keeps providing services, such as payroll, IT hosting, finance and procurement, to the business you bought until you can provide them yourself. Good TSA management means one thing: every service has a named owner on your side, an exit date you chose by working backward from what it takes to stand up the replacement, and a monthly fee line you can see falling.

The cost of a TSA is rarely the monthly fee alone. It is the fee multiplied by months of slippage, the extension premiums written into the contract, the people you cannot reassign because they are managing the seller, and the synergies you cannot start while two sets of systems run. Each month a service stays on the TSA costs its monthly fee, plus whatever uplift applies after the base term.

This guide gives you a service register, an exit-plan method, a governance cadence, and a worked example. The first move is to turn the TSA schedule into a spreadsheet with one row per service, then assign an owner and an exit date to every row before Day 1. This is a management guide, not legal advice. Your TSA's actual terms, termination rights and service standards come from the signed agreement, and your counsel should interpret them.

When to use this

Use this guide when:

• You are closing a carve-out or a divisional purchase and the seller will provide shared services after close.
• You are the seller and will provide services, and want the exit to be orderly rather than a series of renewals.
• A TSA already exists and the monthly invoices have become routine, with no one asking when each line ends.
• Your PMI playbook lists standing up your own finance, IT or HR functions and you need an exit schedule that fits it.

Do not use this as a substitute for negotiating the agreement. Service definitions, fee basis, extension rights and termination notice periods are set before signing. After signing, management works inside what the document allows. If the schedule is missing a service you actually depend on, escalate it to counsel and the deal team early, because the remedy depends on the agreement's wording.

Diagnostic questions

Answer these in the first week after signing, from the TSA schedules and your own operating data.

1. Does every service in the schedule have a written description, a service level, a fee basis (fixed, usage-based or cost-plus) and a term?
2. Which services are missing from the schedule but were actually performed by the seller for this business before close? How do you know?
3. For each service, who on your side is the named owner, and who on the seller's side is the named contact?
4. What are the termination and extension terms for each service: minimum term, notice period, extension length and any price uplift on extension?
5. Are any services bundled so that you cannot exit one without paying for all of them?
6. What does each service depend on, such as a system, a data feed, a license or a person, and does the dependency need a third-party consent?
7. What is the build-or-buy plan for each service, and what is the realistic lead time, including procurement, hiring and data migration?
8. Which services touch regulated data, customer payments or financial close, where a failed cutover would be visible externally?
9. How are fees invoiced and reviewed, and who compares invoices with the schedule?
10. What data will the seller need to retain or return at exit, and where is that written down?
11. Which services can be exited early without penalty, and which cannot?
12. Which services does the seller also depend on you for (reverse TSA), and are those priced?

If question 2 shows a gap, fix that first. A missing service is a risk you find on Day 1 when something stops working, and it usually becomes the most expensive line item.

The framework: inventory, plan, govern, exit

The central idea is that the exit date is a result, not a hope. You derive it from the longest path in the replacement: if payroll needs a vendor selected, contracted, configured, tested with a parallel run and then cut over at a pay-period boundary, that sequence sets the date. Write the sequence down per service.

Step-by-step process

1. Build the service register. One row per service from the TSA schedule, plus any services you discover are missing. Owner: integration lead. Output: register with fee, term, owner, dependencies. Time-box: first week.
2. Name two owners per service. One on your side accountable for the exit, one at the seller accountable for delivery. Owner: integration lead. Output: owner columns completed. A service with no owner on your side will not exit on time.
3. Classify each service. Tag as run-as-is, replace, absorb into an existing function, or retire. Owner: service owner with the functional head. Output: classification and a one-line rationale.
4. Work backward from replacement lead time. For each replace or absorb service, list the steps (selection, contract, configuration, data migration, testing, parallel run, cutover) with durations from your own vendors and past projects. Owner: service owner. Output: exit date and milestone list.
5. Compare exit dates with contract terms. Check minimum terms, notice periods and extension prices. If a service must end before the contract allows, or cannot end before the base term does, flag it for counsel and the deal team. Owner: integration lead with counsel. Output: a list of mismatches.
6. Sequence exits to protect the close and customers. Avoid cutting over finance, payroll and billing in the same month. Owner: IMO. Output: sequenced calendar.
7. Set the fee baseline. Compute monthly TSA fees by service and the cumulative cost if every service exits on plan. Owner: finance. Output: baseline cost curve.
8. Run the weekly TSA review. Status by service, red items, decisions needed. Owner: TSA manager. Output: updated register and issue log.
9. Reconcile invoices monthly. Compare each invoice line with the schedule's fee basis, usage and term. Owner: controller. Output: disputed items and credits requested through the contract's process.
10. Give notice early and in the form the contract requires. Calendar every notice deadline. Owner: service owner with counsel. Output: notice sent and acknowledged.
11. Execute cutover with a rollback plan. Define the point of no return and who decides. Owner: service owner. Output: signed cutover checklist.
12. Close out. Confirm data return or deletion, final invoice, access removal and lessons learned. Owner: service owner. Output: closed row in the register.

Templates

Service register (copy into a spreadsheet)

Exit milestone plan (one per service)

Weekly TSA review agenda

1. Services exiting in the next 60 days: status against milestones (10 min).
2. Red items and decisions needed from sponsors (10 min).
3. Service-level misses and escalations with the seller (5 min).
4. Fee changes and invoice issues (5 min).
5. Notice deadlines in the next 30 days (5 min).

Metrics and KPIs

Setting targets without invented benchmarks. Do not borrow a typical TSA duration from an article or a deal database. Set each exit target from the three anchors you control: the replacement lead time you derived bottom-up, the contractual base term (your floor for planning, and your ceiling to avoid paying extension terms), and the longest similar cutover your own team has completed. Where your team has no precedent, ask your vendor for their reference timelines in writing and add contingency you can justify.

Common mistakes

1. Treating the TSA schedule as complete. Symptom: something stops working in week two and no one knows who provides it. Reconcile the schedule against what the seller actually did for the business before close.
2. Setting exit dates equal to the contract end. Symptom: every service ends in month 12 and the team is overloaded in month 11. Stagger exits and plan each from its own lead time.
3. No named owner on the buyer side. Symptom: invoices are paid by AP and nobody asks what the service delivers. Give each service an owner.
4. Starting the replacement late. Symptom: extension premiums. Start vendor selection for long-lead items, such as ERP and payroll, in the first month.
5. Letting service levels drift. Symptom: workarounds and rework. Log misses and raise them through the contract's escalation process.
6. Ignoring the data exit. Symptom: you cannot get history out of the seller's systems at the end. Define data return format and date before cutover.
7. Forgetting the reverse TSA. Symptom: the seller depends on you for services and no one is pricing them or tracking them.
8. Missing notice windows. Symptom: you pay another full term for a service you had already replaced. Calendar every notice date.

Worked example (Illustrative)

The numbers below are made up to show the method. They are not benchmarks, and the contract terms are invented.

A buyer carves a division out of a larger company. The TSA runs 12 months and covers five services at fixed monthly fees. After the base term, any extension is priced at 110% of the monthly fee.

If all five services ran the full 12 months, the cost would be $116,000 × 12 = $1,392,000. The staggered plan costs $1,124,000, which is $268,000 lower. That difference is the value of exit planning, and it only exists if the dates are met.

Now suppose IT hosting slips two months beyond the base term. Extension is at 110%, so each extra month costs $42,000 × 1.10 = $46,200, and two months cost $92,400. That is on top of the $504,000 already planned. The slippage also postpones any synergy that depends on the hosting move, which the synergy tracking model should capture as a delayed start.

What the operator does with this: the finance exit in month 10 is the biggest controllable item at $350,000, and it also shares a month-end with IT cutover planning, so the IMO moves the finance cutover to a quarter boundary and keeps the IT cutover separate. The invoice for each month is reconciled against the $116,000 declining schedule, and any month where the invoice does not step down on plan triggers a question to the seller.

AI prompt assistance

Use AI to organize documents and draft status materials. Do not use it to interpret contract rights; counsel does that.

1. Build the service register from the schedule.

I will paste the service schedules from a TSA. For each service, extract: service name, description, fee basis, monthly fee, term, notice period, extension terms, and any named dependency. Return a table. Quote the clause number for every extracted term, and list any service where a field is missing or ambiguous.

Check: verify five rows against the source document and ask counsel to confirm any ambiguity flagged.

2. Draft an exit milestone plan.

Given this service description and our replacement approach (paste both), draft a milestone plan with steps from requirements to cutover and data return. Show assumptions for durations as ranges, and list the three steps most likely to be on the critical path.

Check: replace every duration with your own vendor or team estimate before using it.

3. Reconcile an invoice.

Here is the month's TSA invoice and the fee schedule (paste both). List each invoice line, the matching schedule line, the expected amount, the invoiced amount and the variance. Highlight lines with no matching schedule entry.

Check: recompute the invoice total by hand and tie it to the AP posting.

Implementation guide

Governance: a sponsor on the buyer side owns the overall TSA cost curve, the TSA manager runs the weekly review, and counsel owns interpretation of contract terms. Report cumulative TSA cost against the baseline in the monthly integration update.

What to expect: the first month is usually discovery, with services missing from the schedule and owners unclear. The steady state is a shrinking invoice and a short weekly meeting. A TSA that has no exit milestones in the register by month two is on its way to extension.

Downloadable assets

The service register, exit milestone plan and weekly agenda above are designed to be copied into a spreadsheet.

Related resources

• Post-merger integration hub: all integration guides in one place.
• PMI playbook: Day 1 to Day 365: where TSA exits fit in the full plan.
• Day 1 readiness checklist: confirming the services you need are covered at close.
• Synergy tracking: from model to realized EBITDA: connecting TSA exit dates to when savings can start.

Frequently asked questions

What is a transition services agreement?

A transition services agreement is a contract in which the seller keeps providing specified services to the divested business for a defined period after closing. Typical services include payroll, IT hosting, finance and procurement. It exists so the business keeps running while the buyer builds or buys its own capability.

How long should a TSA last?

A TSA should last as long as the longest replacement path for each service, and no longer. Work backward from vendor selection, configuration, migration, testing and cutover for each service, then compare the result with the contract's base term. Your counsel advises on extension rights and notice periods under the signed agreement.

How do you reduce TSA costs?

You reduce TSA costs by exiting services on or before the planned date, reconciling every invoice to the fee schedule, and starting long-lead replacements early. Stagger exits so the team is not overloaded in one month. Each month of slippage costs the monthly fee plus any extension uplift in your contract.

Who should own the TSA after closing?

Each service needs a named owner on the buyer side accountable for its exit, and one person, often in the integration management office, should run the weekly review and track total cost. Finance reconciles invoices, and counsel interprets contract terms such as termination and extension rights.

What is a reverse TSA?

A reverse TSA is an arrangement in which the buyer provides services back to the seller, usually because the divested business supplied something the seller still needs. It should be inventoried, priced and tracked like the main TSA, with its own owner and exit date, so it does not become an unplanned burden on your teams.

How this works in a System of Performance

A TSA is a set of promises with dates and prices, and the useful question each week is whether the work behind each promise is moving. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see which services in your own schedule have no owner or exit date, bring it to us as a launch partner.