Transition services agreements: keeping system access after a carve-out

What does a TSA cover for systems and data?#

A transition services agreement covers the services a seller keeps providing to a carved-out business after closing, usually IT, finance, HR and access to shared systems, for a fixed term with negotiated extensions. Each service sits on a schedule with a description, a fee, a duration and an exit plan.

For systems, the schedule typically lists the ERP, CRM, helpdesk, email tenant, file shares and engineering tools the business runs on. The usual gap is scope. The schedule promises that the business can keep taking orders and answering customers; it rarely says which years of closed orders, cases, quotes and project records will be handed over, in what format, or by when.

TSA terms are negotiated deal by deal and interact with the purchase agreement, so treat this as general information, not legal advice, and work through the specifics with deal counsel.

Why system history gets lost at TSA exit#

System history gets lost at TSA exit because cutover plans are built around open work. The integration team moves active customers, open orders, open tickets and current price lists into new systems, and everything closed stays behind in the seller's shared instance.

Shared instances make the problem harder. The divested business may sit in one ERP company code among many, one region of a CRM org or one set of queues in a helpdesk, with its records interleaved with the seller's other businesses. The seller has good reasons to protect that other data, so without an agreed separation rule nobody extracts the history at all.

Once access ends, the history follows the seller's retention schedule, not yours. The questions that need it arrive later: warranty claims, customer pricing audits, tax inquiries, disputes and diligence on the next sale.

The TSA systems checklist#

The TSA systems checklist turns history into named deliverables with owners and acceptance tests. Attach it to each systems service and fill it in during negotiation, while both sides still have leverage and the seller's IT team is engaged.

Four ways to separate records from a shared instance#

Separating the business's records from a shared instance comes down to four approaches, and most carve-outs combine them. The choice depends on how cleanly the business can be identified in the data and how much of the seller's information sits in the same tables.

A common pattern is to migrate open records, archive closed history in a separate extract, and negotiate a short read-only window for anything missed. Whatever the mix, require original identifiers in every output so records from different systems can still be joined later.

What happens to history after the TSA ends#

History left in third-party systems after the TSA ends is governed by vendor terms, and those windows are short. The Salesforce Main Services Agreement provides that customer data is made available for export if the customer asks within 30 days after termination, after which Salesforce has no obligation to keep it. Microsoft says it keeps customer data from an ended cloud subscription in a limited-function account for 90 days so it can be exported.

Those windows matter when subscriptions transfer to the carved-out business and are cancelled after migration, or when the seller retires its own instance. Put export deadlines on the integration plan for every subscription that will close, and check the actual order forms, which may differ from standard terms. Before signing off on exit, work through this list.

• 1Confirm the historical extract passed validation and that acceptance is signed.
• 2Store the archive in company-controlled, encrypted storage with an index of systems, record types and date ranges.
• 3Record what the seller retains, for how long, and under what confidentiality and use limits.
• 4Close or transfer subscriptions only after their exports are verified.
• 5Add the archive to the company's retention schedule and name an owner for it.

Illustrative: a distribution division leaves its parent's systems#

Illustrative: a fictional industrial parts distribution division is carved out of a diversified manufacturer by a private equity buyer. The division runs on the parent's ERP as its own company code, shares a CRM org with two sister businesses, and handles customer cases in a shared helpdesk with its own queues.

The draft TSA covered order processing and invoicing for a fixed term and the migration of open orders and active customers. The operating partner adds a historical extract service: closed orders, returns and credit memos for every year the ERP holds, CRM activity history for the division's accounts, and helpdesk cases from its queues, all with original IDs and attachments, accepted against record counts.

The new ERP starts with open records, and the history sits in a readable archive the company controls. When a large customer audits its pricing history, the team answers from the archive. The board later asks whether the returns and exception records could be licensed, which depends on how the purchase agreement allocates data and on the customer contracts.

How SourceX approaches carve-out records#

SourceX approaches carve-out records through the Rights step of the SourceX five-step transaction as much as the Supply step. Records still commingled with the seller's data, or records the purchase agreement leaves with the seller, are out of scope until separation and ownership are settled.

Once the carved-out company controls its history, the fit check needs only metadata: systems, years, record families and known restrictions. If a package proceeds, the SourceX Evidence Packet records provenance, including the chain from seller to carved-out company, along with licensing rights, permitted use, the privacy record and release authorization.