Transition Services Agreement (TSA)
How an acquisition buyer turns post-close seller support into a finite operating bridge with named services, owners, costs, and exit tests.
- Whether every service has a defined scope, owner, standard, fee, dependency, and exit date
- Whether the buyer has transition deliverables and access needed to replace each service
- Whether extensions, early termination, service changes, and disputes follow objective procedures
- Whether third-party consents, licenses, data access, and security obligations support the service model
If this clause already feels aggressive in isolation, upload the full contract and see how it combines with payment terms, liabilities, and exit rights.
Analyze My ContractSeller will provide only the Services listed in Schedule 1 through the applicable Exit Date. Each Service will have a named owner, service standard, fee, dependency, transition deliverable, and termination process as stated in that Schedule.
What this clause actually does
Buyer decision first: sign a TSA only after the team can identify which seller-run functions the business cannot replace on day one, who owns each transition, what the service costs, and the event that ends it. The TSA is an operating bridge, not a general promise that the seller will keep helping after close. If the schedule cannot be turned into a weekly exit plan, the scope is not ready.
Why people get burned by this clause
A vague support promise can leave the buyer dependent on the seller for payroll, accounting, systems, customer access, licenses, data, vendors, or key relationships after ownership changes. Cross-check the TSA against the purchase agreement, transition covenants, closing deliverables, employee plan, software and data schedules, third-party consents, customer communications, working-capital mechanics, and any seller employment or consulting agreement.
What should make you slow down
- The services are described as reasonable assistance or support as needed without a service catalog
- No named service owner, service level, transition deliverable, dependency, fee, or exit date
- The seller can change personnel, systems, security practices, or subcontractors without a control process
- Third-party software, data, or vendor access cannot legally or operationally continue after closing
- Fees, pass-through costs, taxes, expense approval, and disputed invoices are not defined
- The TSA renews automatically or can continue because the buyer lacks a workable exit mechanism
- Liability, confidentiality, data security, indemnity, and insurance terms conflict with the purchase agreement
Where you usually see it
- Asset and stock purchase agreement exhibits
- Standalone transition services agreements
- Separation and carve-out transactions
- Seller consulting and employment arrangements
- IT, finance, payroll, customer, and vendor transition schedules
What the platform checks in the live contract
- Whether every service has a defined scope, owner, standard, fee, dependency, and exit date
- Whether the buyer has transition deliverables and access needed to replace each service
- Whether extensions, early termination, service changes, and disputes follow objective procedures
- Whether third-party consents, licenses, data access, and security obligations support the service model
- Whether liability, indemnity, confidentiality, insurance, and force majeure terms align with the purchase agreement
- Whether seller consulting, employment, and restrictive-covenant documents overlap or conflict with the TSA
What to test against your deal
- A service schedule defines the task, owner, inputs, output, service standard, fee, dependency, and exit test
- The buyer can terminate individual services as replacement capability comes online
- Changes and extensions require written approval from named representatives
- Pass-through expenses require documentation and agreed approval thresholds
- Data, security, confidentiality, access, and incident duties match the actual systems used
- The purchase agreement states which TSA obligations survive and how overlapping remedies work
Definitions worth opening next
Clause pages that share the risk pattern
Common questions about this clause
Decide which seller-controlled functions are true closing dependencies and which can be replaced before close. Put the unavoidable dependencies into a service schedule with owners, economics, and exit tests. Ask counsel whether any service, consent, or access right must be a closing condition instead of a post-close promise.
Cross-check the purchase agreement, disclosure schedules, closing checklist, software and vendor contracts, data-processing terms, transition covenant, employee plan, seller consulting agreement, customer notices, and working-capital schedule. A service should not depend on a right the seller cannot transfer or continue.
Ask how TSA claims interact with purchase-agreement indemnity, exclusive-remedy language, caps, waivers, insurance, confidentiality, data incidents, and third-party claims. The answer depends on the transaction documents and governing law, so avoid assuming the purchase-agreement remedy automatically controls.
It is ready when the operating team can run the first day, track each service, approve costs, receive transition deliverables, and end dependencies without relying on unwritten seller cooperation. Legal drafting should reflect that operating plan.
The buyer is not deciding whether seller help sounds useful. The decision is whether every post-close dependency has a controlled bridge and a credible exit. Use the TSA to convert operational uncertainty into scheduled obligations, then have deal counsel align it with the purchase agreement and third-party rights. This guide provides legal information, not legal advice.
See how this clause behaves in the real contract.
The clause library gives you a starting point. Document analysis can surface relevant language, show related sections, and organize risk signals and follow-up questions for review against the source file.