Free Word download • Edit online • Save & share with Drive • Export to PDF
A Transition Services Agreement (TSA) is a legally binding contract in which a seller or divesting party agrees to provide defined operational services — IT systems access, payroll processing, finance administration, logistics support, or other back-office functions — to a buyer or newly separated entity for a limited period after a transaction closes. Unlike a standard services contract, a TSA is specifically designed to wind down: its purpose is to give the recipient time to build or procure independent capabilities while maintaining business continuity from day one post-close. TSAs are executed alongside — or as a condition of — asset purchase agreements, stock purchase agreements, and merger agreements in M&A transactions, corporate carve-outs, and spin-offs of all sizes.
Without a signed TSA in place at closing, the recipient of an acquisition or carve-out has no enforceable right to access the seller's systems, personnel, or infrastructure — even if everyone informally agreed that support would continue. Deals that close without a TSA routinely stall within the first 30 days when IT access is revoked, payroll runs are missed, or financial reporting is disrupted, because there is no contract defining who owes what to whom. Equally, sellers without a TSA face open-ended support obligations with no agreed fees, no liability cap, and no defined exit — exposing them to indefinite entanglement and unrecovered stranded costs. A properly structured TSA protects both sides: it gives the recipient the operational continuity it needs to integrate without disruption, and it gives the provider enforceable terms — fees, step-up rates, exit milestones, and a liability ceiling — that bound the relationship in time and scope. This template gives you the structure to negotiate, draft, and execute a TSA that is specific enough to be enforceable and flexible enough to reflect the realities of your transaction.
| If your situation is… | Use this template |
|---|---|
| Seller providing IT systems access to buyer after an acquisition | Transition Services Agreement (IT-focused) |
| Parent company providing HR and payroll services to a spun-off entity | Shared Services Agreement |
| Buyer providing reverse transition services back to the seller | Reverse Transition Services Agreement |
| Short-term operational handover between a seller and buyer of a small business | Business Transfer Agreement |
| Ongoing outsourcing of a specific function after integration is complete | Master Services Agreement |
| IT vendor providing interim managed services during a migration | IT Services Agreement |
| Consulting firm supporting integration planning and execution | Consulting Agreement |
Why it matters: Without specific scope definitions — named systems, user counts, output volumes — the provider can claim any additional request is out of scope, forcing the recipient to pay for change orders or go without critical services.
Fix: Describe each service with enough specificity that a third party could determine whether it has been delivered — include system names, user limits, geographic coverage, and processing volumes.
Why it matters: Recipients routinely delay exits, leaving the provider bearing stranded costs while the recipient pays original cost-based fees. Without a financial disincentive, extensions become the norm rather than the exception.
Fix: Add a step-up fee of 15–25% per month on any service that runs past its scheduled end date, payable automatically without amendment to the agreement.
Why it matters: A cap based on 12 months of cost-priced fees may be $50,000 for a service whose failure could cause millions in lost revenue, regulatory penalties, or data-breach liability.
Fix: Negotiate the liability cap separately for high-risk services — particularly IT and data processing — and consider requiring the provider to maintain cyber-liability or professional indemnity insurance with the recipient named as an additional insured.
Why it matters: At exit, providers have returned data in legacy formats that the recipient's new systems cannot ingest, causing weeks of delay and requiring expensive data conversion work at the recipient's cost.
Fix: Specify the exact file format, transfer method, and delivery timeline for each data type in the applicable service schedule, and confirm compatibility with the recipient's target systems before signing.
Why it matters: Different workstreams — IT migration, HR separation, finance cutover — complete at different times. A single end date creates pressure to extend the entire TSA when only one service is delayed, keeping the provider entangled longer than necessary.
Fix: Set an individual end date for each service schedule so services can be terminated independently as the recipient exits each workstream.
Why it matters: Without named contacts, review meetings, and an escalation path, every service dispute — delayed invoice, SLA miss, system outage — defaults to a contract-level standoff between legal teams, slowing resolution and damaging the post-close relationship.
Fix: Name a Transition Services Manager for each party, schedule monthly governance meetings in the agreement, and define a two-step escalation path to CFO level before arbitration is triggered.
In plain language: Identifies the service provider (typically the seller) and the service recipient (typically the buyer or separated entity), and recites the underlying transaction that makes the TSA necessary.
This Transition Services Agreement ('Agreement') is entered into as of [CLOSING DATE] by and between [SELLER LEGAL NAME] ('Provider') and [BUYER LEGAL NAME] ('Recipient') in connection with the [PURCHASE AGREEMENT / MERGER AGREEMENT] dated [DATE].
Common mistake: Using trade names instead of registered legal entity names. If the contracting entity differs from the operating entity providing the service, enforcement and indemnification claims become complicated.
In plain language: Defines each service the provider will deliver by reference to a numbered schedule, specifying the nature, volume, and geographic scope of the service.
Provider shall deliver to Recipient the services described in Schedule [A] (IT Infrastructure), Schedule [B] (Payroll and HR), and Schedule [C] (Finance and Accounting), each as set out in detail therein.
Common mistake: Drafting schedules at too high a level of abstraction — 'IT support' rather than 'access to [ERP SYSTEM] for up to [X] named users at [LOCATION].' Vague scopes generate disputes about what is and is not included within weeks of closing.
In plain language: Sets measurable performance standards for each service — uptime, turnaround time, error rates — and the remedy when standards are not met.
Provider shall deliver each service at a standard no less than the level at which it was performed during the [12]-month period preceding the Closing Date. Specific SLAs for each service are set out in the applicable Schedule.
Common mistake: Omitting SLAs entirely and relying on 'reasonable efforts.' This makes it nearly impossible to claim a breach or withhold payment when service quality deteriorates after close.
In plain language: Sets the overall TSA duration, the individual end date for each service, and the exit milestones the recipient must hit to transition off each service.
The initial term for each service shall be as specified in the applicable Schedule, not to exceed [18] months from the Closing Date. Recipient shall achieve the exit milestones set out in Schedule [D] and shall notify Provider no less than [30] days before exiting each service.
Common mistake: Setting a single global end date for all services instead of per-service end dates. IT migration and HR separation rarely complete at the same time; a single deadline creates pressure to extend the entire agreement when only one service is delayed.
In plain language: States the fee for each service — whether cost-plus, fixed, or time-and-materials — the invoicing schedule, and step-up fees for services that run past their scheduled end date.
Recipient shall pay Provider the fees set out in each Schedule, invoiced monthly in arrears. Fees are net of applicable taxes. Services continuing past the scheduled end date shall be subject to a [20]% step-up fee applied to the then-current monthly fee.
Common mistake: Omitting step-up fees. Without a financial incentive to exit on time, recipients routinely extend TSA services beyond the agreed term, increasing stranded costs and creating dependency.
In plain language: Clarifies that the provider retains ownership of its systems, software, and data, and that the recipient's data remains the recipient's property; governs data access, transfer, and deletion at exit.
Nothing in this Agreement transfers ownership of Provider's systems, software, or proprietary processes to Recipient. All data of Recipient processed under this Agreement ('Recipient Data') remains the sole property of Recipient. Upon expiration of each service, Provider shall deliver Recipient Data in [FORMAT] within [30] days and delete all copies.
Common mistake: Failing to specify the format and timeline for data return at exit. Providers have returned data in formats the recipient's new systems cannot ingest, effectively holding the data hostage for weeks after TSA termination.
In plain language: Restricts both parties from disclosing the other's confidential information — financial data, customer lists, trade secrets, and operational data shared during service delivery.
Each party shall hold the other's Confidential Information in strict confidence, use it solely to perform or receive services under this Agreement, and not disclose it to any third party without prior written consent. Obligations survive termination for [3] years.
Common mistake: Using a mutual confidentiality clause that treats both parties' obligations as identical. Post-M&A, the provider typically has access to far more of the recipient's operational data than vice versa; asymmetric obligations and audit rights for the recipient are often warranted.
In plain language: Limits the provider's financial exposure for service failures and sets out each party's indemnification obligations for third-party claims arising from service delivery.
Provider's aggregate liability under this Agreement shall not exceed the total fees paid by Recipient in the [12] months preceding the claim. Each party shall indemnify, defend, and hold harmless the other from third-party claims arising from its own negligence or wilful misconduct.
Common mistake: Setting the liability cap as a multiple of annual fees when TSA fees are intentionally priced at cost — resulting in a cap so low it provides no meaningful recovery for a material data breach or system failure.
In plain language: Establishes a joint governance structure — named service coordinators, periodic review meetings, and an escalation path — for resolving operational disputes before they become legal claims.
Each party shall designate a Transition Services Manager. The parties shall hold monthly governance reviews. Disputes not resolved within [10] business days shall be escalated to the CFOs of each party. Unresolved disputes shall be submitted to [MEDIATION / ARBITRATION] in [CITY] under [AAA / JAMS] rules.
Common mistake: Skipping the governance clause and relying on the dispute resolution clause alone. TSAs generate frequent low-level service disputes that benefit from a named contact and escalation path — without one, every friction point becomes a potential litigation trigger.
In plain language: Sets out the conditions under which either party may terminate a service or the entire agreement — for cause, for convenience with notice, or on change of control — and the obligations on wind-down.
Recipient may terminate any individual service for convenience on [60] days' written notice. Either party may terminate for material breach if uncured within [30] days of written notice. On termination, Provider shall cooperate with Recipient's transition to an alternative provider and deliver all Recipient Data within [30] days.
Common mistake: No termination-for-convenience right for the recipient. If the recipient completes its exit ahead of schedule for a particular service, it should not be obligated to pay for services it no longer needs through the full scheduled term.
Audit every operational function the recipient cannot perform independently at close — IT systems, payroll, benefits administration, finance, logistics, facilities. Assign each function a separate numbered schedule.
💡 Complete this list at least 60 days before signing the main purchase agreement so TSA scope can be negotiated as part of the deal — not scrambled in the 48 hours before closing.
For each schedule, specify exactly what is included: named systems, user counts, geographic coverage, data volumes, and any excluded activities. The more specific the schedule, the fewer disputes arise post-close.
💡 Attach a process flow or system diagram as a sub-exhibit for complex IT services — it takes 30 minutes to create and eliminates weeks of post-close argument about what was in scope.
Define measurable SLAs for each service — uptime percentages, processing turnaround times, error thresholds — and specify the remedy for a miss: service credit, fee reduction, or cure period.
💡 Use the pre-close performance baseline as the SLA floor. Pull 12 months of historical data and state it explicitly; this protects the recipient if the provider deprioritizes TSA services post-close.
Set the fee for each service — cost-plus at a defined margin, fixed monthly, or time-and-materials — and add a step-up fee of 15–25% for any service that runs past its scheduled end date.
💡 Providers often underprice TSA fees to appear cooperative during deal negotiations. Recipients should ensure fees are high enough that the provider is genuinely incentivized to staff and maintain service quality.
Set an individual end date for each service and list the specific milestones the recipient must hit to exit — e.g., 'ERP system go-live' or 'payroll provider contract signed.' Attach these as Schedule D.
💡 Build in a 30-day buffer between the expected exit milestone and the scheduled service end date. Real migrations always run late.
Specify the format and timeline for data return at each service exit, confirm that the provider's systems and IP are not transferred, and state the provider's obligation to delete recipient data within a defined period after exit.
💡 Name the specific file format for data delivery — CSV, JSON, XML — and confirm the recipient's new system can ingest it before the TSA is signed.
Insert the name and contact details of each party's designated Transition Services Manager in the governance clause and confirm the monthly review cadence.
💡 Choose managers with operational authority to resolve disputes, not just project coordinators. The ability to escalate to CFO level within 10 business days is only useful if the day-to-day manager can resolve 80% of issues without escalation.
Sign the TSA simultaneously with — or as a condition to — the closing of the main purchase agreement. Both parties' authorized signatories must execute; confirm entity names match those in the purchase agreement exactly.
💡 If execution must happen post-close, get a signed term sheet for the TSA before closing — an unsigned TSA post-close gives the provider strong leverage to negotiate less favorable terms.
A transition services agreement (TSA) is a contract in which a seller or divesting party agrees to provide specified operational services — IT systems access, payroll processing, finance functions, or logistics support — to the buyer or separated entity for a defined period after a transaction closes. It bridges the gap between deal closing and the point at which the recipient can operate fully independently. TSAs are standard in M&A transactions, corporate carve-outs, and spin-offs.
A TSA is typically required when a buyer acquires a business that cannot immediately operate independently of the seller's infrastructure — particularly in carve-outs where shared ERP systems, HR platforms, or supply chain relationships must be unwound. It is also used when a parent company spins off a subsidiary that has historically relied on corporate shared services. The need for a TSA should be identified during due diligence, not at closing.
Most TSAs run 6 to 18 months from the closing date, with 12 months being the most common duration for mid-market transactions. IT migrations typically take the longest — often 12–18 months. HR and payroll transitions frequently complete in 3–6 months. Step-up fees are used to incentivize the recipient to exit each service by its scheduled end date rather than rolling the entire TSA to a single extension date.
A reverse TSA is an arrangement in which the buyer provides services back to the seller post-close. This arises when the buyer acquires systems or infrastructure that the seller still depends on — for example, when a divested business unit operates the seller's primary data center or customer-facing platform. The reverse TSA and the standard TSA are often negotiated together as part of the same transaction.
The buyer (as service recipient) typically pays the seller (as service provider) for TSA services. Fees are usually priced at cost-plus a small margin (5–15%), though negotiated fixed fees are also common. In some deals, the parties agree to a limited period of free services as part of deal economics, particularly where the seller is motivated by a clean exit. Step-up fees apply if services extend past the scheduled end date.
The remedy depends on the TSA's SLA provisions. Common remedies include service credits applied against future invoices, a right to cure within a defined period, or — for persistent or material failures — a right to terminate the affected service and transition to an alternative provider. Without SLAs in the agreement, the recipient's only remedy is a general breach-of-contract claim, which is expensive and slow to pursue.
No — a TSA does not need to be drafted or signed by a lawyer to be enforceable, but legal review is strongly recommended. TSAs sit at the intersection of M&A, IT, employment, and data privacy law; errors in liability caps, data ownership, or governing law can have material financial consequences. For transactions above $5M in deal value, a 1–3 hour attorney review of the TSA is considered standard practice in most jurisdictions.
A TSA is a temporary, transaction-specific agreement designed to wind down as the recipient builds independent capabilities. A master services agreement (MSA) is an ongoing commercial arrangement with an indefinite or renewable term, used for continuous outsourcing relationships. If TSA services are still needed after the transition period ends, converting specific workstreams to an MSA with a third-party provider is the typical path forward.
In the US, TSAs are governed by contract law in the state specified in the governing-law clause. In Canada, provincial employment standards and data privacy laws affect HR and payroll service schedules. In the UK, TUPE regulations may apply if employees are transferred alongside services. In the EU, GDPR imposes strict data processing and transfer requirements that must be addressed in the IP and data ownership clause of any TSA involving personal data.
A master services agreement governs an ongoing, open-ended commercial relationship between a service provider and client — it is not time-limited and is not tied to a specific transaction. A TSA is a temporary bridge agreement designed to wind down as the recipient builds independent capabilities. Use a TSA for post-close transition needs; use an MSA when outsourcing a function on a permanent or indefinite basis.
An asset purchase agreement transfers ownership of specific assets from seller to buyer at closing. A TSA does not transfer anything — it governs the seller's continued provision of services to the buyer for a defined period after the APA closes. The two documents are typically executed simultaneously, with the TSA drafted as a condition to or exhibit of the APA.
A consulting agreement engages an individual or firm to provide advisory or professional services on a project or retainer basis. A TSA is an operational continuity document covering infrastructure, systems, and back-office functions — not advisory work. The parties to a TSA are typically transaction counterparties with existing operational entanglement, not a client and an external advisor.
A service level agreement defines performance standards and remedies for an ongoing service relationship — it is typically an exhibit or addendum to a broader services contract. A TSA is the governing agreement itself, which contains SLA provisions for each service schedule. A standalone SLA cannot substitute for a TSA in a post-transaction context because it lacks the IP, data ownership, termination, and governance provisions that a TSA requires.
IT-heavy TSAs covering ERP access, cloud infrastructure handover, software license assignments, and API integrations that cannot be migrated before close.
Regulatory reporting obligations, shared compliance systems, and licensed platform access require precisely scoped schedules and heightened data-security SLAs.
HIPAA-compliant data handling obligations must be embedded in service schedules; clinical system transitions require strict uptime SLAs and defined patient-data migration timelines.
Supply chain and procurement systems, shared logistics contracts, and ERP-driven production planning are the most common service categories requiring TSA coverage in manufacturing carve-outs.
Client-file access, billing system continuity, and shared back-office platforms are typically the critical services; client-notification obligations under professional rules must be coordinated with TSA exit timelines.
Point-of-sale system access, inventory management platforms, and shared distribution center agreements are the most common TSA service categories; peak trading periods must be excluded from planned exit windows.
TSAs are governed by the contract law of the state specified in the governing-law clause — Delaware and New York are most common for M&A transactions. Data privacy obligations under state laws (California CCPA, Virginia VCDPA) must be reflected in service schedules involving personal data. If employees are involved in delivering TSA services, classification and wage-and-hour compliance under FLSA and applicable state law must be confirmed.
PIPEDA and provincial privacy statutes (Quebec Law 25 in particular) impose strict data processing and cross-border transfer requirements that must be addressed in the IP and data clause. If TSA services involve HR or payroll, Employment Standards Act minimums in each applicable province constrain how service delivery personnel can be engaged. Quebec-based entities may require French-language contract execution under the Charter of the French Language.
TUPE (Transfer of Undertakings Protection of Employment) regulations may apply where employees whose roles are substantially connected to TSA service delivery are ultimately transferred to the recipient — triggering automatic transfer of employment terms. UK GDPR and the Data Protection Act 2018 require a data processing agreement to be incorporated or appended where personal data is processed under the TSA. Post-Brexit, cross-border data transfers to non-adequate countries require standard contractual clauses.
GDPR Article 28 requires a data processing agreement (DPA) wherever personal data is processed by the service provider on behalf of the recipient — this must be incorporated into or appended to the TSA for any service involving employee, customer, or operational personal data. Transfers of personal data outside the EEA require either an adequacy decision or standard contractual clauses. Member state employment law — particularly in Germany, France, and the Netherlands — may impose co-determination or works council consultation obligations before TSA services affecting employees can be restructured.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Small business owners providing limited post-sale operational support after a straightforward asset sale under $1M | Free | 1–3 hours |
| Template + legal review | Mid-market M&A transactions ($1M–$50M deal value) with multiple service schedules and data privacy implications | $500–$2,500 for a 2–4 hour attorney review | 2–5 business days |
| Custom drafted | Large or complex carve-outs, cross-border transactions, regulated industries (healthcare, financial services), or deals with material IT infrastructure dependencies | $5,000–$25,000+ | 2–6 weeks |
This document is one of 3,000+ business & legal templates included in Business in a Box.
Access over 3,000+ business and legal templates for any business task, project or initiative.
Customize your ready-made business document template and save it in the cloud.
Share your files and folders with your team. Create a space of seamless collaboration.
"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."
"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."
"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."
Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.
Free Forever Plan · No credit card required
