Private equity and portfolios
TSA ends: getting your records out of the former parent's systems
By SourceX Editorial · Updated
Short answer
A transition services agreement data handover should move every record the carve-out acquired out of the former parent's systems, with history, attachments and links intact, before TSA access ends. Start from the purchase agreement and TSA schedules, agree filters for shared instances, test the extract, and verify it in your own storage before the parent decommissions anything.
Key takeaways
- The purchase agreement and the TSA decide which records the carve-out is entitled to; read both before planning any export.
- Shared instances are the hard part: agree in writing how carve-out records are filtered from the parent's own records.
- Export closed history, attachments, comments and linking IDs, not just the master data the new systems need on day one.
- Verify the extract in storage you control before confirming any TSA service as complete.
- Keep a manifest of what was received; it becomes the provenance record for audits, disputes and any later licensing.
What has to come out before the TSA ends?#
Before a TSA ends, every record the carve-out acquired or needs must leave the former parent's systems: operating histories, finance and tax records, people records, email and shared files. Current master data for the new systems is only one part of that list.
Migration teams naturally focus on what the new ERP, CRM or help desk needs on day one: open orders, active customers, current price lists. Closed cases, completed work orders, quality investigations and old email threads get left for later, and later often arrives after the parent has switched off access.
Those historical records hold the business's operating knowledge. They support warranty claims, tax questions and disputes, and they are the records an AI developer might later license, provided the company actually received them and holds the rights to use them.
Read the deal documents before planning exports#
The deal documents decide what the carve-out is entitled to take, so the export plan starts with the purchase agreement, the TSA and its service schedules rather than the IT runbook.
Where the documents are silent on history, raise the gap early with the parent's integration team. A short written side letter naming systems, record families and date ranges is far easier to agree before the TSA end date than after it.
| Document | What to look for | Why it matters |
|---|---|---|
| Purchase agreement | Which books and records transfer and which the parent keeps | Defines what the carve-out owns outright |
| TSA service schedules | Each system the parent runs for you and its end date | Systems can end on different dates |
| Exit or migration assistance clause | Whether the parent must supply extracts, formats and help | Sets what you can request and at whose cost |
| Records access clause | Rights to request records the parent keeps after closing | Covers later tax, audit and litigation questions |
| Commingled data terms | How shared records are split, licensed back or destroyed | Decides whether mixed records can be used at all |
| Confidentiality provisions | Limits on parent information that appears in your records | Parent material may need removal before reuse |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why are shared instances the hardest part?#
Shared instances are the hardest part of a TSA exit because the carve-out's records sit inside the same Salesforce org, ERP or help desk as the parent's, interleaved with and often linked to records the parent keeps.
Extraction depends on a reliable filter field: legal entity, business unit, division code or product line. Where that field was applied inconsistently, records created before the business was a distinct unit may be missed, or the extract may pull in the parent's own customers.
Agree the filter logic in writing, run a test extract and sample it jointly. Records that touch both businesses, such as shared customers or cross-division escalations, need a stated rule: transferred, redacted, licensed back or left with the parent.
The TSA exit data checklist#
The TSA exit data checklist runs from the deal documents to a verified archive, and each line should have a named owner on both the parent's side and the carve-out's side.
Do not accept a decommission notice for any system until the verification line is signed off. Once a parent retires a shared instance, recovering one division's history from backups is slow, uncertain and dependent on goodwill.
- List every system the parent runs for you under the TSA, with its service end date.
- For each system, name the record families to transfer, the date range and the export format.
- Confirm entitlement for each record family against the purchase agreement.
- Agree filter logic for shared instances and the rule for records that touch both businesses.
- Request export features that need enabling or vendor support well before the end date.
- Export history, attachments, comments and audit trails, plus the IDs that link records across systems.
- Run a test extract, sample it jointly and fix gaps before the full run.
- Load the full extract into storage you control and verify counts and links.
- Record a manifest of systems, families, date ranges, counts, filters and exclusions.
- Only then confirm the TSA service as complete.
Export traps in common systems#
Export traps in common systems usually involve features that are off by default, content stored somewhere unexpected, or export files that expire before anyone downloads them. Check each vendor's current documentation, because these details change.
Parent IT teams run these exports on their own schedule and permissions. Put the export calendar in the TSA exit plan so a download window does not open while your storage or staff are not ready.
| System | What catches teams out | What to do |
|---|---|---|
| Zendesk | Account data exports are not on by default; the account owner must ask Zendesk support to enable them | Have the parent's account owner request it early |
| HubSpot | Calls, notes and other activities need a separate export method from the standard record export | List activities as their own export line |
| Microsoft Teams | Chat files sit in the sharer's OneDrive, while channel files sit in the team's SharePoint site | Include OneDrive and SharePoint locations, not just mailboxes |
| Microsoft Purview eDiscovery | Search exports expire 14 days after creation | Line up download capacity before running exports |
| Google Vault | Export files are available for 15 days after the export starts, then deleted | Download and verify inside the window |
Illustrative: a service division leaving its parent's Salesforce org#
Illustrative: a fictional PE fund buys Kestrelton Field Services, the industrial equipment service division of a diversified manufacturer. Under the TSA, the parent keeps running the division on its shared Salesforce org, its SAP instance and its Microsoft 365 tenant while the division stands up NetSuite and its own tenant.
The integration plan covers open work orders and active service contracts. The operating partner adds history: closed cases, completed work orders with technician notes, warranty claims and the service managers' email folders. Cases carry a division code, but older cases predate it, so both sides agree to filter older records by service contract number instead.
A test extract shows missing attachments and dropped case-to-work-order links, and both are fixed before the full run. The parent's decommission notice is accepted only after the manifest is signed, leaving the division with a linked service history in its own storage and clear provenance for any later licensing assessment.
After the handover: keep the archive usable#
After the handover, the archive stays usable only if someone owns it: a named custodian, a retention policy and a manifest recording where every record came from.
Finance and tax records need particular care. The IRS says to keep records supporting income, deductions or credits until the period of limitations for that return runs out, generally 3 years and longer in some situations, so pre-close records may still be needed. Lenders and insurers can require longer retention.
Keep the archive read-only, store the purchase agreement schedule that conveyed it next to the manifest, and avoid loading it into new systems in ways that strip original IDs and timestamps.
How SourceX approaches carve-out archives#
SourceX starts a carve-out review with the purchase agreement and the TSA, because rights in a carved-out archive depend on what actually transferred. During the initial fit check SourceX asks only for metadata about systems and record families; the archive itself stays in your storage.
Within the SourceX five-step transaction, the Rights step checks commingled records and parent confidentiality before Preparation begins, and records with unclear transfer are excluded rather than debated. The handover manifest feeds the provenance section of the SourceX Evidence Packet, alongside licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Can we extend the TSA just to finish data extraction?
Many TSAs allow extensions for specific services, though notice periods and pricing vary. If extraction is at risk, ask early and name only the systems and record families still outstanding. An extension limited to read-only access is often easier to agree than continued full service.
What if the parent will not export closed records?
Check the purchase agreement first. If those records transferred, the parent may be obliged to deliver them, and counsel can raise the issue under the TSA's cooperation or dispute terms. If they did not transfer, a records access clause may still allow specific requests later, though rarely a full archive.
Should history go into the new systems or a separate archive?
Migrate what teams use daily and keep the rest in a read-only archive with original IDs, timestamps, attachments and links. Forcing years of closed history into a new schema tends to drop fields and break links, while an archive keeps the context needed for audits, disputes and later licensing review.
Who should own the data plan on the buyer side?
A named owner at the carve-out, usually the incoming IT lead or integration lead, with the operating partner backing escalations to the parent. Counsel confirms entitlement, finance confirms tax and audit records, and business leaders confirm which histories their teams rely on.
Do personal details in transferred records need extra care?
Often. Employee files, customer contacts and similar records carry privacy obligations that travel with them, and some may need to stay with the parent or be limited. Which laws may apply depends on the people and states involved, so counsel should review the handover scope rather than assume everything can move as is.
Sources
- Zendesk data exports are not turned on by default; the account owner must contact Zendesk Customer Support, giving the Support subdomain, to enable them. Source
- HubSpot's export-records article says activities such as calls and notes must be exported with a separate method, not the standard record export. Source
- Microsoft states that files shared in Teams chats are stored in the OneDrive account of the user who shared them, while files uploaded to channels are stored in the team's SharePoint site. Source
- Microsoft states that Purview eDiscovery search exports expire 14 days after creation, so export packages must be downloaded before they are automatically deleted. Source
- Google Vault export files are available for 15 days after the export starts and are then deleted, so the export must be re-created to obtain the data again. Source
- The IRS says to keep records supporting an item of income, deduction or credit until the period of limitations for that return runs out: generally 3 years, with longer periods in specified situations. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.