A transition services agreement (TSA) is a fixed-term contract where a seller keeps providing operational support, like IT, payroll, or finance, to the divested business after closing. The single biggest drafting priority is building granular, service-by-service schedules with clear end dates tied to a realistic migration timeline, not a vague blanket promise to “help out” post-close. Get that right, and pricing, liability, and governance tend to fall into place. Templates and a full drafting checklist follow below.
TL;DR:
- Building detailed, service-specific schedules during diligence ensures enforceability, accurate pricing, and clear end dates aligned with migration timelines.
- Staggering service end dates and including early termination rights allow buyers to reduce dependence gradually and avoid paying for unnecessary support.
- Pricing models should be tailored to each service, with invoice dispute processes and audit rights clearly outlined to prevent billing conflicts.
- Defining measurable KPIs for high-risk services and establishing governance structures enhances enforceability and minimizes disputes over service levels.
- Identifying third-party software licenses, data security measures, and IP rights upfront mitigates post-close risks and prevents vendor hold-ups or legal breaches.
Table of Contents
- Why Transition Services Agreements Matter in Carve-Outs and Divestitures
- How Do You Build a Complete TSA Service Schedule?
- How Long Should a Transition Services Agreement Last?
- How Are Transition Services Priced and Invoiced?
- How Do You Set Service Levels and Enforce Them?
- How Is Liability Allocated in a Transition Services Agreement?
- What Third-Party Consents and Software Risks Should You Check First?
- What Data Security and IP Protections Belong in a TSA?
- TSA Drafting Checklist and Sample Clause Reference
- How Should Buyers and Sellers Negotiate a TSA?
- How Captyx Supports TSA and Post-Close Transition Planning
- What Deal Teams Should Actually Prioritize
- How Captyx Helps You Plan Your Transition Services Agreement
- Sources
- FAQ
Why Transition Services Agreements Matter in Carve-Outs and Divestitures
A carve-out sale rarely hands the buyer a self-sufficient business on day one. Corporate parents often retain the payroll system, the ERP license, the shared IT help desk, or the accounting function that the divested unit was never built to run alone. Without a bridge, operations stall the moment the deal closes. That bridge is the transition services agreement.
TSAs show up most often in three scenarios: divestitures of a business unit from a larger parent, carve-out private equity acquisitions where the target shared back-office infrastructure with a corporate seller, and post-merger integrations where two IT stacks or two finance teams need time to consolidate. In each case, the seller’s systems keep the lights on while the buyer builds or migrates its own capability.
Weak TSA drafting creates real financial exposure, not just administrative headaches. A well-crafted TSA coordinates pricing, term, and exit mechanics so the buyer can actually finish migration while the seller avoids being stuck supporting a former subsidiary indefinitely. When that coordination is missing, buyers face unplanned costs from stranded systems, seller IT teams that deprioritize a business they no longer own, and disputes over what counts as “in scope” once something breaks.
TSA terms also shape competitive positioning in an auction. A bidder who shows up with a narrow, short-duration TSA ask signals operational readiness and lower ongoing entanglement risk. That matters more than most buyers realize during a competitive process, because:
- Sellers generally prefer buyers who need less long-term hand-holding, since it reduces their own post-close obligations and legal exposure.
- A buyer that can articulate exactly which services it needs, for how long, and why, looks more credible during diligence than one asking for a blanket six-month “TBD” period.
- Overly broad TSA requests can quietly signal to a seller that the buyer’s integration planning is thin, which erodes negotiating leverage on price.
Sellers and buyers who treat the TSA as an afterthought, something to sort out after the letter of intent, routinely lose value they didn’t need to give up.
How Do You Build a Complete TSA Service Schedule?
The service schedule is the actual engine of the agreement. Everything else, pricing, term, liability, hangs off of it. A TSA that describes services in a paragraph or two (“Seller shall provide IT support as reasonably requested”) is functionally unenforceable, because neither side can point to what was promised when a dispute arises.
Building a real schedule starts with function-level mapping, not legal drafting. Before lawyers touch the document, someone from each functional area, IT, HR, finance, procurement, facilities, needs to sit down and inventory exactly what the target business currently consumes from the parent. That means pulling in department heads, not just the deal team, because the people running payroll or the help desk know details that a corporate development analyst never will.
For each service line, the schedule should document:
- The system or platform involved (which ERP module, which payroll provider, which shared drive).
- The specific output or deliverable (monthly close reports, biweekly payroll runs, tier-1 help desk tickets).
- Frequency and volume expectations (daily, weekly, per-transaction, with rough volume benchmarks from historical usage).
- The named owner on each side (who at the seller performs it, who at the buyer receives and validates it).
- The individual end date or termination trigger for that specific service, not a single global end date for the whole TSA.
A service schedule that reads like an actual operating manual, with dates, outputs, systems, and named owners, cuts down post-close disputes far more effectively than a document full of high-level category descriptions.
Pro Tip: Run the service-mapping exercise during diligence, not after signing. Waiting until the definitive agreement is drafted almost guarantees the schedule gets built from memory instead of from actual system logs and usage records, which is exactly how omitted services slip through.
That’s where the omitted-services clause earns its keep. No mapping exercise catches everything, so the TSA needs a mechanism for services discovered after signing that were part of ordinary operations but didn’t make the schedule. A well-drafted clause lets either party invoke it within a defined window (typically 60 to 90 days post-close), triggers a good-faith obligation to negotiate pricing for the added service, and caps how long that addition can run without renegotiation. Without this clause, the seller has no obligation to help with anything it didn’t explicitly agree to, and the buyer discovers gaps at the worst possible moment.
How Long Should a Transition Services Agreement Last?
Most TSAs run six to eighteen months, and the right duration depends entirely on how complex the buyer’s migration plan actually is. A simple payroll cutover might wrap in ninety days. A full ERP migration for a manufacturing carve-out can realistically take the better part of a year, sometimes longer if custom integrations are involved.

The mistake many buyers make is setting a single blanket end date for the entire agreement. That approach ignores the reality that different services have wildly different migration timelines, IT infrastructure might take twelve months while accounts payable processing could transition in sixty days.
Staggering end dates by service line, matched to each function’s actual migration plan, is the better structure. It lets the buyer wind down dependency incrementally instead of facing a cliff where every service terminates simultaneously regardless of readiness.
A few structural elements matter beyond the base term:
- Notice periods for early termination. Buyers should retain the right to drop individual services early, with 30 to 60 days’ notice, once their internal capability is ready, rather than paying for services they no longer need.
- Extension rights with escalating pricing. Nearly every well-negotiated TSA includes the option to extend specific services past the initial term, but at a higher rate. Experienced negotiators build these as scheduled percentage or fixed-dollar step increases tied to defined windows (say, a 15% bump at month 13, another 15% at month 16), which turns the extension into a predictable financial lever rather than an open-ended negotiation.
- Stranded cost allocation on early termination. If the buyer terminates a service early, the agreement needs language addressing who absorbs any fixed costs the seller already committed to (a software license renewal, a staffing contract) on the buyer’s behalf.
The escalating-rate structure does double duty. It compensates the seller fairly for continuing to run infrastructure it no longer needs long-term, and it gives the buyer a real financial incentive to finish migrating instead of treating the TSA as a permanent crutch.
How Are Transition Services Priced and Invoiced?
TSA pricing usually follows one of four models, and mixing them across different service lines within a single agreement is common and often smart.
Cost pricing passes through the seller’s actual expense with no markup, typically used for simple pass-through items like software license fees the seller pays on the buyer’s behalf. Cost-plus pricing adds a markup, usually in the 5% to 15% range, to compensate the seller for administrative burden and opportunity cost of dedicating staff time to a business it no longer owns. Fixed-fee pricing sets a flat monthly rate regardless of actual usage, which works best for predictable, stable services like a shared office lease. Pass-through items, third-party software fees, telecom contracts, insurance premiums, get billed at cost with supporting documentation attached.
Invoicing mechanics deserve as much attention as the pricing model itself:
- Set a defined invoicing cycle, monthly is standard, with itemized detail by service line rather than a lump sum.
- Build in a dispute window, commonly 15 to 30 days, during which the buyer can challenge a specific line item without withholding payment on the entire invoice.
- Grant the buyer reasonable audit rights over cost-based and cost-plus charges, since without them there’s no way to verify the seller isn’t inflating pass-through expenses.
Sample language for a dispute clause often reads something like: “Recipient shall notify Provider in writing of any disputed charge within thirty (30) days of invoice receipt; undisputed amounts shall be paid in full, and disputed amounts shall be resolved through good-faith negotiation before escalation to the steering committee.”
Third-party consent fees and sales or use tax allocation are where a lot of TSAs get sloppy. If a software vendor charges a fee to consent to continued use post-close, the TSA should state upfront whether that cost sits with the buyer, the seller, or gets split, rather than leaving it to be fought over later. Sales tax treatment on services rendered across state lines varies by jurisdiction, so the agreement should specify which party bears responsibility for calculating and remitting any applicable tax on the TSA fees themselves.
How Do You Set Service Levels and Enforce Them?
The default standard most TSAs use is “historical performance,” meaning the seller must deliver services at the same quality, timeliness, and priority level it maintained before closing. That standard is easy to agree to in principle and notoriously hard to enforce in practice, because “the same as before” is subjective unless it’s backed by actual metrics.
The stronger approach layers specific, measurable KPIs on top of the historical-performance baseline for any service where failure would meaningfully hurt the buyer’s operations. Building that structure takes a few concrete steps:
- Identify the two or three services where failure creates the most business risk (usually payroll processing, order fulfillment systems, or customer-facing IT) and prioritize KPI drafting there first.
- Set numeric thresholds tied to historical data, such as “help desk tickets resolved within an agreed reasonable time frame the vast majority of the time,” pulled from the seller’s own performance logs over the trailing twelve months.
- Attach a remedy to each KPI, typically a service credit, a percentage reduction in that month’s fee for the affected service, rather than a right to terminate the whole agreement over one missed metric.
- Build a governance structure, not just metrics on paper. Most functioning TSAs designate a service manager on each side per major function, require monthly reporting against the KPIs, and set up a steering committee with representatives from both companies that meets on a defined cadence to resolve escalations before they become disputes.
Pro Tip: Don’t over-engineer KPIs for low-risk services. A TSA with forty tracked metrics across every minor function creates more administrative burden than value. Reserve granular service-level drafting for the handful of services where a failure would actually damage the business, and let the historical-performance standard cover the rest.
The escalation ladder matters more than most buyers budget time for during negotiation. A three-tier structure, service manager resolves day-to-day issues, steering committee handles unresolved escalations monthly, executive sponsors step in only for material breaches, keeps small problems from becoming contract disputes.

How Is Liability Allocated in a Transition Services Agreement?
Liability caps in TSAs are generally tied to fees paid under the agreement rather than the broader deal value. A typical structure caps aggregate seller liability at an amount related to several months of fees paid for the specific service that failed, with narrow carve-outs for gross negligence, willful misconduct, and data breaches that remove the cap entirely for those specific failure modes.
This structure exists because sellers generally aren’t willing to accept open-ended liability for running someone else’s business at a modest markup. Buyers, meanwhile, need enough teeth in the agreement that a seller has real financial incentive to perform, not just a symbolic promise.
A few points that consistently come up in negotiation:
- Liability caps tied to fees paid, rather than a flat dollar figure, automatically scale with how much the buyer is actually spending on that service, which keeps the risk allocation proportionate.
- The interaction between TSA liability provisions and the underlying stock or asset purchase agreement’s indemnification section needs careful drafting to avoid double recovery or, worse, gaps where neither document covers a specific harm.
- Data breach carve-outs deserve their own attention separate from general gross-negligence language, given how much sensitive operational and customer data typically flows through TSA-supported systems.
- Practical remedies, service credits and formal notice-and-cure periods, resolve far more disputes than litigation-oriented default and termination language ever does.
Buyers sometimes push for uncapped liability on the theory that the seller controls the systems and should bear full risk. That rarely survives negotiation intact, because sellers have no incentive to continue providing services at cost-plus pricing while carrying unlimited downside. The more productive compromise centers on tightly scoped carve-outs and a notice-and-cure mechanism that gives the seller a real chance to fix a problem before financial penalties kick in.
What Third-Party Consents and Software Risks Should You Check First?
Software licenses and vendor contracts cause more TSA breakdowns than almost any other single issue, and they’re identifiable well before signing if someone actually looks. The problem is structural: most enterprise software agreements, ERP systems, CRM platforms, specialized industry tools, are licensed to the parent entity, not the specific business unit being sold. Once the carve-out closes, the divested business technically has no legal right to keep using that software unless the vendor consents.
This gets missed constantly because it falls in a gap between the deal team (focused on price and structure) and IT (often not looped in until diligence is nearly done). A vendor discovering post-close that a former customer is still running its software under someone else’s license can demand a steep consent fee, or simply cut off access.
Who handles this, and how, needs to be settled well before signing:
- Diligence teams should build a full inventory of software and vendor contracts the target business relies on, flagging which are licensed at the parent level versus the subsidiary level.
- Consent fees, when a vendor demands payment to approve continued use, typically get negotiated as a shared cost or allocated to whichever party benefits most from the extended access, and that allocation should be spelled out in the TSA rather than assumed.
- If a vendor flatly refuses consent, the fallback is usually the seller continuing to process transactions through its own licensed instance on the buyer’s behalf as a service line, rather than the buyer attempting to use the software directly, which keeps everyone within the actual license terms.
This is also where diligence practices from other regulated, software-heavy sectors are instructive. Healthcare SaaS diligence frameworks place heavy emphasis on license portability and data ownership precisely because software dependency creates the same kind of hidden transition risk regardless of industry. Building consent identification into the diligence checklist, not the post-signing scramble, is the difference between a clean transition and a vendor holding the deal hostage over a five-figure consent fee.
What Data Security and IP Protections Belong in a TSA?
Running a buyer’s payroll, customer records, or financial systems through seller-owned infrastructure for months creates a genuine security exposure that a lot of TSAs handle with a single vague confidentiality clause. That’s not enough given what’s actually flowing through these systems.
The minimum technical and contractual controls worth insisting on include:
- Role-based access control, limiting which seller employees can touch buyer data to only those directly performing the transition service.
- Multi-factor authentication on any system where buyer data is accessible, especially financial and HR platforms.
- Activity logging and audit trails covering who accessed what data and when, retained for the full term of the TSA plus a reasonable post-termination window.
- Encryption for data in transit and at rest, particularly for any data crossing between the seller’s and buyer’s separate environments.
- Audit rights, giving the buyer the ability to request a security review or third-party audit of the seller’s controls at least once during the TSA term.
A proper data processing addendum should sit alongside the core TSA, specifying exactly what categories of data the seller can access, how long it retains copies after termination, and the process for confirming deletion once the transition ends. Buyers routinely forget to address post-termination data access, leaving the seller with lingering copies of sensitive buyer data on old backup systems long after the relationship ends.
Pro Tip: Ask for a written data destruction certificate at TSA termination, not just a verbal assurance. It costs the seller nothing to provide and gives the buyer a paper trail if a data issue surfaces later.
On intellectual property, the TSA should draw a hard line around background IP, meaning any software, processes, or proprietary methods the seller owned before the deal stay owned by the seller. The buyer typically receives a narrow, time-bound license to use that background IP solely for the duration of the transition period, with no rights surviving termination unless separately negotiated in the purchase agreement itself.
TSA Drafting Checklist and Sample Clause Reference
Turning everything above into a workable draft comes down to sequencing. Trying to negotiate liability caps before the service schedule exists is backward, and it’s one of the most common reasons TSA negotiations drag on past signing.
A practical drafting order looks like this:
- Finalize the service schedule first. Nothing else in the agreement can be priced or termed accurately until the actual service inventory is locked.
- Set term and staggered end dates per service, matched against the buyer’s real migration timeline rather than an arbitrary round number like “twelve months for everything.”
- Assign pricing models per service line (cost, cost-plus, fixed, or pass-through), and draft the invoicing and dispute-resolution mechanics.
- Draft service-level standards and KPIs for the highest-risk services, with the historical-performance standard as the default baseline for everything else.
- Negotiate liability caps and carve-outs, tied to fees paid, with narrow exceptions for gross negligence, willful misconduct, and data breaches.
- Confirm third-party consents and software license status for every system in the service schedule before finalizing pricing.
- Attach the data processing addendum and IP license terms.
- Incorporate the finished service schedule as an exhibit to the purchase agreement, not a standalone side letter, so both documents reference consistent defined terms and there’s no ambiguity about which contract governs a conflict.
For readers drafting from scratch, SEC-filed transition services agreement exhibits offer real, publicly available form language covering scope, pricing, and termination mechanics that practitioners regularly consult before drafting their own version.
Here’s how the core clause categories typically function in a finished agreement:
| Clause category | What it typically covers |
|---|---|
| Scope and schedules | Service-by-service description, systems used, output frequency, named owners on each side |
| Term and termination | Overall duration, staggered per-service end dates, early termination notice periods |
| Pricing and invoicing | Cost/cost-plus/fixed/pass-through model per service, billing cycle, dispute window |
| Service levels | Historical-performance baseline, specific KPIs for high-risk services, service credit remedies |
| Liability | Caps tied to fees paid, carve-outs for gross negligence and data breaches |
| Consents and licenses | Third-party software and vendor consent responsibilities, fallback arrangements |
| Data and IP | Access controls, data processing addendum, background IP ownership and license scope |
Handing counsel a filled-out schedule and a marked-up checklist like this, instead of a blank template, cuts weeks off the drafting timeline in most carve-out transactions.
How Should Buyers and Sellers Negotiate a TSA?
Buyers and sellers walk into TSA negotiations with fundamentally different incentives, and understanding the other side’s pressure points makes for a faster, cleaner negotiation.
Buyers generally get the most value out of these tactics:
- Push for the shortest realistic term per service, rather than accepting a single long blanket period covering everything. A finance function might need ten months while facilities support needs sixty days, and asking for one uniform term overpays for the easy stuff.
- Insist on early termination rights so you’re not locked into paying for a service after internal capability is ready.
- Request escrow or holdback for anticipated third-party consent fees discovered during diligence, so the seller has financial skin in the game to actually secure those consents rather than leaving it to the buyer post-close.
- Get the service schedule finalized before signing, not left as a post-closing exhibit to be negotiated later when leverage has shifted.
Sellers, meanwhile, tend to focus on a different set of priorities:
- Cap the scope tightly to what’s documented in the schedule, resisting open-ended “and any other reasonably requested services” language that creates unlimited exposure.
- Push for cost-plus pricing rather than fixed fees on any service with uncertain volume, protecting against underpricing a service that ends up being more labor-intensive than expected.
- Limit reputational exposure by keeping service-level standards at the historical-performance baseline for lower-risk functions, reserving hard KPIs only for what the buyer specifically negotiates.
In competitive auction processes, Deloitte’s guidance on TSA negotiation points to something buyers underuse: a shorter, more targeted TSA ask can function as a competitive advantage in a bidding process. Sellers running an auction generally favor the buyer who needs the least hand-holding, since it reduces their own post-close operational and legal burden. A bidder who arrives with a tight, well-scoped TSA request, backed by a credible internal migration plan, often reads as the more sophisticated, lower-risk buyer, even when the headline purchase price isn’t the highest on the table.
How Captyx Supports TSA and Post-Close Transition Planning
Experience with TSA structuring is common in many carve-out or full-business sales where the seller retains some operational overlap with the buyer post-close. That experience shapes how Captyx approaches exit readiness work with clients long before a term sheet is on the table.
Service mapping is where most TSA problems originate, so it is addressed during deal preparation rather than after a letter of intent is signed. Walking through which functions, IT, payroll, customer support, a seller would need to keep supporting post-close helps sellers understand their own transition obligations before a buyer’s counsel drafts the first schedule.
Buyer positioning is the other half of the equation. Sellers running a competitive process consistently favor buyers who show up with a realistic, narrow transition ask rather than an open-ended one. Helping clients understand what a credible TSA request looks like, and where vendor consent fees are likely to surface, is part of preparing both sides of a transaction for a smoother close.
Business owners preparing to sell, or buyers evaluating a carve-out, benefit from getting TSA structure right before it becomes a point of friction during diligence rather than a late-stage scramble.
What Deal Teams Should Actually Prioritize
The single biggest mistake I see in TSA negotiations is treating the service schedule as boilerplate to fill in after the real negotiating is done. It’s backward. Five things matter more than anything else in this document.
First, the schedule has to be built from actual system data, not memory, during diligence. Second, staggered end dates per service beat a single blanket term every time, because migration never happens on one uniform timeline. Third, liability caps tied to fees paid, with narrow carve-outs, are the fair middle ground, not a sign either side is getting outmaneuvered. Fourth, third-party software consents need identifying weeks before signing, not discovered after a vendor sends a cease-and-desist. Fifth, governance structure, a real steering committee with a defined escalation ladder, prevents small service failures from becoming six-figure disputes.
If you’re negotiating pre-signing, put your drafting resources into the schedule and the consent inventory first. Everything else in the agreement is easier to negotiate once those two things are solid.
Buyers: ask for less, but ask for it precisely. Sellers: cap your exposure, but don’t let vague scope language create a liability you never priced.
— Tucker
How Captyx Helps You Plan Your Transition Services Agreement
Sellers who walk into a transaction with a mapped-out service inventory and a realistic transition timeline consistently negotiate better TSA terms than those who leave it for the buyer’s counsel to draft from scratch. That’s the gap Captyx closes.

Captyx’s full-scope M&A advisory and business brokerage services build TSA planning directly into deal readiness, alongside value gap analysis, financial preparation, and buyer outreach, so the service schedule and consent inventory are ready well before a buyer’s counsel sends a draft. Post-transaction transition and integration support may be included in such engagements, assisting sellers in avoiding open-ended obligations and helping buyers prepare with a realistic migration plan.
If you’re planning a sale and want a clear picture of where your business stands before TSA terms even enter the conversation, start with a Free REAL Valuation. It’s a practical first step toward understanding your exit readiness, confidentially and with no obligation to move forward until you’re ready.
Sources
- The Transition Services Agreement Is a Deal Document, Not an Afterthought – Montague Law
- A Guide to Transition Services Agreements (TSAs) in M&A – Seidman Law
- Form of Transition Services Agreement (SEC exhibit)
FAQ
Can you provide an example of a transition services agreement?
Real, publicly filed examples exist in SEC exhibit filings, which show actual clause language for scope, pricing, term, and termination that practitioners commonly reference when drafting their own agreements.
What is a transition agreement?
A transition agreement, more precisely a transition services agreement, is a contract where a seller continues providing operational support, like IT, HR, or finance functions, to a divested business for a defined period after a sale closes.
What is the difference between an MSA and a contract?
A master services agreement (MSA) is a specific type of contract that sets ongoing terms for a ongoing vendor relationship, while “contract” is the broader category; a TSA is a distinct, specialized contract type used specifically for post-close operational support in M&A transactions, not an ongoing vendor relationship.
Who needs a TSA in an M&A deal?
Any buyer acquiring a carved-out business unit that shares systems, staff, or infrastructure with its former parent needs a TSA, and any seller divesting such a unit needs one to formally limit its post-close obligations. Captyx builds TSA planning into its exit readiness process for sellers preparing to sell a business with shared operational functions.






