Definitions and comparisons
What is a transition services agreement, and who controls the data?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
A transition services agreement (TSA) is a short-term contract in which the seller of a business keeps running some systems or services for it after closing. A TSA usually governs access to data, not ownership: ownership follows the purchase agreement, so read both before anyone licenses records still sitting on the seller's systems.
Key takeaways
- A TSA is a services contract; it sets access, use and security terms for records on shared systems.
- Ownership of business records is usually decided by the purchase agreement, not the TSA.
- Commingled records, such as shared customers in one CRM, rarely belong cleanly to either side.
- Migrations are scoped for operations, so historical archives are often left behind unless the TSA exit plan names them.
- Licensing usually waits until records sit in the divested company's own storage and a rights review is done.
What is a transition services agreement?#
A transition services agreement (TSA) is a contract in which the seller of a business, usually its former parent, keeps providing certain services to the divested business for a limited period after closing. The services typically include IT hosting, ERP access, payroll, help desk, email and finance operations that the business cannot yet run on its own.
TSAs are most common in carve-outs, where a division shares systems with the rest of the parent. The buyer, often a private equity sponsor or a strategic acquirer, uses the TSA period to stand up its own systems and migrate. A reverse TSA runs the other way: the divested business provides services back to the seller.
For data, the key point is that a TSA is a services contract. It sets out who may touch records on shared systems, for what purpose and under what security terms. It rarely decides who owns those records.
Who owns the data during a TSA?#
Ownership of data during a TSA is usually decided by the purchase agreement, not the TSA itself. The stock or asset purchase agreement lists transferred assets, excluded assets and intellectual property, and often defines business records or business data. The TSA then governs access and handling while those records still sit on the seller's systems.
This split creates a gap that operating teams often miss. A divested company may own its customer history under the purchase agreement and still be unable to export it until the TSA schedule allows, or until the seller's migration team gets to it. Read the documents together, not one at a time.
| Document | What it usually decides | Data questions it answers |
|---|---|---|
| Purchase agreement | Which assets, records and IP transfer to the buyer | Who owns business records, shared records and legacy archives |
| Transition services agreement | Which services the seller provides, for how long and on what terms | Who can access, use, host and secure records during the transition |
| IP or data cross-license | Rights each side keeps in shared or commingled material | Whether either side may use shared records after separation |
| Separation or migration plan | How systems and records move to the buyer | Which history is extracted, in what format and by when |
| Data processing terms | Privacy duties when one side handles personal data for the other | Purpose limits, security and deletion for customer and employee records |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Who can license what during the TSA?#
Who can license records during a TSA depends on the record type and on what both agreements say. As a starting rule, the divested business can consider licensing only records it owns and can lawfully export, and the TSA provider generally has no right to license the divested business's records at all.
Commingled records are the hard case. A shared Salesforce org or a single NetSuite instance can hold accounts, cases and transactions that relate to both sides, and separating them takes deliberate work and often a negotiated allocation.
| Record type | Usual position | Watch for |
|---|---|---|
| Records exclusively about the divested business, hosted on shared systems | Owned by the buyer side after closing if the purchase agreement says so; export may wait on the TSA | Definitions of business records that exclude certain systems or archives |
| Commingled records, such as shared customers or company-wide chat | Often covered by a cross-license or allocation clause; neither side may have a clean right alone | Clauses limiting shared data to internal business use |
| Records about the seller's other businesses | Retained by the seller | Access granted only for support purposes |
| New records the divested business creates on seller systems during the TSA | Usually owned by the divested business | Provider rights to use service data for its own purposes |
| Data received under vendor or customer contracts | Governed by those contracts' terms | Software licenses that bar the seller from running systems for an unaffiliated company |
| Personal data about customers and transferred employees | Ownership plus the privacy notices that covered collection | Notices and processing terms that limit new uses |
Which TSA clauses affect data?#
The TSA clauses that affect data are scattered across the service schedules, the general terms and the exit provisions. Pull them into a one-page summary before anyone discusses analytics, AI projects or licensing, so the operating team and counsel work from the same facts.
- Service schedules: which systems are covered, such as ERP, CRM, help desk, file shares and email, and whether historical archives are in scope.
- Use restrictions: language limiting the provider to using data solely to perform the services.
- Confidentiality: who may see what, and whether provider staff who support both businesses are walled off.
- Security standards: access controls, logging and incident notice for records the provider hosts.
- Extraction and migration: the format, completeness and timing of the handover, including history, attachments and audit trails.
- Return and deletion at exit: what the provider deletes, what it keeps under legal holds or its own retention policy, and what certification it gives.
- Third-party consents: software licenses that need vendor approval before the seller runs systems for an unaffiliated company.
- Term and extensions: what happens to access and fees if the migration slips.
Why the TSA exit decides how much history you keep#
The TSA exit decides how much history the divested business keeps, because migrations are usually scoped for operations, not for archives. Teams move open orders, active customers and recent tickets to the new system and leave older history behind on the seller's side.
Once the TSA ends, the seller may delete the divested business's data or keep a copy only under its own retention policy. Either way, the buyer loses practical access. Order exceptions, resolved support cases and maintenance histories that span many years are the records AI developers find most useful, and they are the first to be cut from a go-live plan.
The fix costs little compared with a recovery attempt later. Add a full historical extract to the migration schedule, specify the format, include notes and attachments, and confirm the export is complete before the exit date. Store it in the buyer's own environment with a record of where it came from.
Illustrative: a distribution division carved out of a manufacturer#
Illustrative: a fictional private equity sponsor buys the industrial distribution division of a larger manufacturer. During the TSA, the division runs on the parent's Epicor instance and a shared Zendesk account. Its records include orders, return authorizations, supplier exceptions and service tickets going back many years.
The operating partner wants to know whether the division's exception records could be licensed later. Counsel finds that the purchase agreement transfers records exclusively related to the division, that several large customers bought from both the division and the parent, and that the TSA has no schedule for extracting history.
The sponsor negotiates an extraction schedule covering closed orders, returns and resolved tickets, with notes and attachments. Records for shared customers are flagged for separate review. Licensing is deferred until the archive sits in the division's own storage and a rights review is complete. The outcome is a clean, documented archive and a narrower but defensible scope.
How SourceX approaches data in a carve-out#
SourceX treats the purchase agreement and the TSA as core documents in the Rights step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The supplier is the entity that owns the records, and the review confirms which records it can license and which belong to the former parent or to shared arrangements.
The SourceX Evidence Packet records provenance, including how records moved off the seller's systems, along with licensing rights, permitted use, the privacy record and release authorization. Nothing is shared during the initial assessment, and large archives stay in the company's own storage.
Frequently asked questions
Can the TSA provider use our records to train its own AI models?
Usually not without permission. Most TSAs limit the provider to using data only to perform the services, and confidentiality terms add further limits. Check whether the TSA or the provider's standard terms include any right to use service data for its own product improvement, and close that gap in writing if it exists.
Do we need the seller's consent to license records still hosted on its systems?
It depends on the documents. If the purchase agreement transfers the records, the buyer side may own them, but the TSA can still control access, export timing and security. Licensing before extraction usually needs the provider's cooperation, so most companies wait until the records sit in their own environment.
What is the difference between a TSA and a reverse TSA?
A TSA has the seller provide services to the business it sold. A reverse TSA has the sold business provide services back to the seller, often because a shared system or team ended up on the buyer's side. The data questions mirror each other: access, use limits and exit terms.
What happens to the data if the TSA is extended?
An extension usually keeps the same use restrictions and security terms, sometimes at a higher fee. It also delays the exit, so check whether retention and deletion dates move with it. An extension is a good moment to add a historical extract if the original migration plan left one out.
Does a TSA cover personal data about customers and employees?
Often, through data processing terms attached to the TSA that limit the provider to handling personal data on the divested business's instructions. Separately, the privacy notices that covered the original collection still shape what either side can do with those records later, including any licensing.
Related resources
- InsightCan roofing contractors sell their data to AI companies?
- InsightCan you license data from a business you already sold?
- InsightSelling a home services company: is the job history part of the deal?
- SolutionData monetization: earning revenue from data you already have
- IndustryHealthcare administration data
- IndustryLegal data
See if your company qualifies
A short company assessment. No data uploads are needed.