TSA negotiations often start with a list of services and an end date. That is backwards. A Transition Service Agreement is a temporary operating model with a price, a dependency graph, and an exit test. If the buyer cannot explain how each service will end before signing, the TSA is buying time without buying independence.

The headline fee is rarely the whole cost. The buyer also pays for project work excluded from the service, data extraction, vendor support, access controls, knowledge transfer, buyer-side capability, and any extension. A weak TSA delays the value plan while the seller’s team protects its own operating model. A well-designed TSA keeps the business stable, makes dependencies visible, and creates pressure to build the buyer’s capability before the contract expires.

The strategy is therefore not “negotiate the lowest TSA price.” It is choose the minimum temporary support that protects continuity, then contract the work and rights required to leave it.

A TSA has four clocks

Treating the TSA as one schedule hides the trade-offs. There are at least four clocks running at once.

The continuity clock covers the services the business needs to sell, ship, invoice, pay, close, run payroll, support customers, and meet security obligations. Failure here affects revenue, cash, employees, and control.

The build clock covers the time to stand up or connect the buyer’s replacement: design, procurement, configuration, migration, testing, training, cutover, and stabilization. The service end date cannot be shorter than this path unless the buyer accepts a different operating posture.

The seller-incentive clock changes after close. The seller wants predictable cost, fewer exceptions, and a clean exit. The buyer wants access, changes, data, and help with problems that were not visible during diligence. Those incentives need commercial terms, not goodwill.

The value clock is when the deal model expects cost, revenue, working capital, or reporting benefits to appear. If the TSA blocks the process or data needed for the value lever, the model date is wrong even when the service remains stable.

The shortest clock sets the risk. The value clock sets the economic consequence. A TSA plan that tracks only the continuity clock leaves the other three unmanaged.

Start from the exit, not the current service inventory

The seller’s service catalogue describes what it does today. It does not tell the buyer what it must own tomorrow. Build the TSA from the exit backward.

For every proposed service, answer:

  1. What business outcome does it protect? For example, first close, payroll, order processing, customer support, or regulatory reporting.
  2. What is the replacement service? A buyer platform, a new provider, a standalone application, a manual control, or a retained seller service.
  3. What must be transferred? Data, configuration, interfaces, credentials, licenses, contracts, documentation, operating procedures, and knowledge.
  4. What proves the buyer can take it over? A reconciled migration, successful transaction test, support rehearsal, security approval, and named owner.
  5. What happens if the test fails? Extension, fallback service, narrower scope, or a delayed value gate.

If these answers do not exist, the service is not ready for a fixed exit date. It may still belong in the TSA, but the buyer should negotiate a readiness-based extension right and price the risk.

Define the service boundary in operational terms

“ERP support” or “IT infrastructure” is not a service definition. It is a label that creates disputes. A usable schedule states the boundary across five dimensions:

  • People: roles, locations, skills, named contacts, coverage hours, on-call expectations, and knowledge-transfer responsibilities
  • Process: included activities, approvals, reconciliations, reporting, incident handling, and change control
  • System: applications, instances, environments, interfaces, batch jobs, certificates, and dependencies
  • Data: source systems, extracts, retention, historical access, master-data ownership, and permitted use
  • Commercial unit: users, transactions, entities, sites, tickets, environments, or another measurable driver

The schedule should also state what is excluded. Project work, new reports, enhancements, new legal entities, major volume changes, and vendor migration support are common exclusions. If they are necessary for exit, they cannot remain outside the cost model.

The buyer should request an opening baseline for each service: current volumes, service levels, open incidents, planned changes, interfaces, and known exceptions. Without a baseline, the seller can argue that the buyer’s needs are “new scope” and charge accordingly.

Why TSA strategies fail

1. The headline fee hides consumption and project cost

A fixed monthly charge can look attractive while the real work sits in variable pricing. Data fixes, report changes, access requests, testing support, vendor calls, and cutover assistance may be excluded or billed by the hour. The buyer then has to choose between paying extra and delaying the exit.

Model at least five components:

base service fee + variable consumption + project and exit work + buyer run cost + extension exposure

Put an owner beside each line. If the seller cannot provide a reliable baseline, use a cap, a defined unit rate, a change budget, or a right to obtain the work from another provider. “Reasonable assistance” is not a price mechanism.

2. The end date is treated as a plan

An end date is a commercial event, not proof of readiness. The buyer may still lack migrated data, support coverage, vendor rights, access controls, or a tested first-close process when the calendar reaches the last month.

Write exit criteria into the operating cadence. Examples:

  • two consecutive transaction cycles reconcile between source and replacement systems
  • named buyer support owners resolve incidents through the agreed route
  • critical interfaces, certificates, and batch jobs have been tested under buyer control
  • required historical data is accessible, retained, and reconciled
  • security, privacy, and audit controls have passed the buyer’s approval

An exit gate should have evidence, an owner, and a decision date. If the gate is missed, the agreement needs a defined extension or fallback. Otherwise the buyer faces an unsafe cutover or an extension negotiated from a weak position.

3. The TSA is too broad to exit

Buyers sometimes put every shared activity into the TSA to reduce Day-1 risk. That can be the right short-term choice for payroll, finance, or core infrastructure. It is poor strategy when the scope includes convenience services that the buyer could own quickly.

Separate services into three groups:

  1. Keep stable: services where interruption would threaten revenue, cash, people, safety, or compliance.
  2. Build to exit: services where independence is required for the deal thesis or for a contractual deadline.
  3. Stop or redesign: services that exist because of the parent model but do not belong in the buyer’s target operating model.

The third group should not be carried forward merely because it is available. A buyer can inherit a parent help desk, reporting pack, approval process, or vendor arrangement that adds cost and delays better decisions. The TSA should protect the business while the buyer chooses its own operating model.

4. The buyer negotiates service delivery but not knowledge transfer

Seller employees often know the exceptions that never made it into the documentation: manual reconciliations, fragile interfaces, month-end workarounds, local tax steps, and the person who restarts a failed job. A service can meet its SLA while the buyer remains unable to operate it.

Make knowledge transfer a deliverable. It should cover current configuration, dependencies, runbooks, known defects, monitoring, access, vendor contacts, incident history, and shadowing for critical processes. Require the buyer to demonstrate the procedure, not just receive a document.

The seller should also identify named subject-matter experts for the services that control payroll, revenue, close, manufacturing, customer access, or TSA exit. If those people may leave, the buyer needs a retention or replacement plan before the service starts.

5. Governance starts after the first invoice

Without governance, the buyer learns about consumption, risk, and blocked decisions through invoices and outages. Set the cadence before close.

The service review should track volume, SLA performance, incidents, open changes, spend against cap, data requests, and exit evidence. The steering group should decide scope disputes, funding, extension posture, and gates that affect the deal model. A named TSA owner should connect operations, procurement, finance, legal, security, and the integration or separation program.

Service governance and exit governance are related but different. A stable service can still be failing its exit plan. Report both.

Choose the TSA posture with three tests

The right posture depends on service criticality, separation complexity, and buyer capacity.

The time bands below are planning heuristics, not universal market standards. The actual cutoffs should follow the service scope, evidence, and build-and-test path.

Short TSA: under nine months

If the TSA is under nine months and the service touches shared identity, ERP, data, network, or revenue-critical interfaces, assume the buyer needs a minimum viable standalone capability immediately after close. Do not rely on a large replacement program completing within the same window unless data, rights, people, and testing are already proven.

The negotiation priorities are a narrow service boundary, early data and access rights, seller staffing, project-work rates, extension mechanics, and an explicit fallback. Full transformation should wait if it competes with the safe exit.

Medium TSA: nine to eighteen months

This window can support phased exit when the data boundary is clear, the replacement owner is funded, and the seller commits the people needed for testing and knowledge transfer. Split the service into exit waves. Do not leave all services to the final month; early waves expose contract, data, and support problems while there is still time to respond.

Long TSA: more than eighteen months

A long term can be useful when the service is genuinely complex or the business needs continuity through a major operating change. It is not evidence that the plan is safe. Longer terms often reduce urgency, preserve parent dependencies, and move the cost outside the original value case.

If a long TSA is required, add step-down economics, quarterly exit gates, a buyer-controlled plan, data access that continues after system exit, and the right to use another provider for work the seller cannot deliver. Reconfirm the value model when the plan changes; a long extension is a decision, not an administrative amendment.

Negotiate the terms that determine independence

The TSA schedule and the transaction documents should cover the dependencies that the buyer cannot fix alone.

  • Scope and baseline: included entities, sites, users, volumes, interfaces, service levels, exclusions, and assumptions
  • Access and control: named administrative access, certificates, service accounts, logs, monitoring, and incident evidence
  • Data and extracts: format, frequency, historical data, metadata, reconciliation, retention, privacy, and post-exit access
  • Change and project work: approval path, response times, rates, caps, deliverables, and ownership of outputs
  • People and knowledge: named roles, coverage, retention, shadowing, runbooks, and replacement support
  • Vendor and license rights: consent, assignment, sublicensing, renewal, true-up, support, and termination mechanics
  • Security and compliance: minimum controls, breach notification, audit rights, segregation, and access review
  • Commercial protection: invoice detail, dispute rights, service credits, fee escalators, volume changes, and extension pricing
  • Exit: waves, readiness tests, cutover support, fallback, data handoff, and the point at which the seller’s service ends

The buyer should avoid an artificial split between “legal terms” and “technology terms.” A right to extract data is a technology dependency. A service cap is a schedule dependency. A change-of-control clause is a cost dependency. Each belongs in the deal model and the exit plan.

Protect the first 100 days

The first 100 days should not be consumed by TSA administration. Use the agreement to release capacity for value work.

At Day 1, confirm the minimum operating state: access, transaction continuity, support, security, reporting, and data ownership. By the first review, confirm that every service has an owner, baseline, open-risk list, and exit wave. By the next review, prove that the replacement path has started for services on the critical path; “design to begin” is not progress if procurement, data, or vendor rights are unresolved.

The integration or separation lead should also maintain a “TSA-to-value” map. For each value lever, show whether it is blocked by a seller service, a buyer capability, or a business decision. If procurement savings depend on a seller-controlled supplier master, the value gate must include a data and ownership condition. If reporting depends on a parent warehouse, the TSA must include extracts, historical access, and a standalone reporting path before the model counts the benefit.

Decision triggers for the deal team

  • If the seller will not provide the data, access, or people required to exit, do not sign an exit date as though it were achievable. Add a protection or change the posture.
  • If the TSA term is shorter than the proven build-and-test path, negotiate an extension right before close or choose a minimum viable standalone path.
  • If project work is excluded but required for exit, price it, cap it, and assign it an owner before accepting the service fee.
  • If the buyer cannot name the replacement owner for a service by the first governance review, the service is not on an exit path; escalate it as a capability gap.
  • If a TSA-dependent value lever has no data or process gate, move the synergy timing until the gate is defined and tested.
  • If the seller’s fee escalates after the base term, compare the extension cost with the cash and risk of accelerating exit. Do not let the escalator make the decision by surprise.

What to do before signing

In the next 10 business days, the deal lead, separation lead, technology lead, finance lead, legal counsel, and seller service owners should produce five artifacts:

  1. A service-to-outcome map showing what each service protects and what would happen if it stopped.
  2. An exit dependency map covering rights, data, people, environments, vendors, and buyer capabilities.
  3. A TSA cost bridge with base fees, variable use, project work, buyer run cost, and extension exposure.
  4. An exit wave plan with evidence-based gates, owners, dates, and fallbacks.
  5. A negotiation issue list that turns every dependency into a scope term, access right, staffing commitment, price mechanism, or deal protection.

Then test the plan with one question: if the buyer had to exit the highest-risk service tomorrow, what would be missing? The answer identifies the item to negotiate now. If the answer is “we would need more time,” the TSA needs to buy a controlled path to independence, not an optimistic date.

A TSA is successful when the business remains stable and the buyer becomes less dependent every month. Stability without an exit path is delay. A low fee without scope control is a false saving. The deal team should optimize for a safe, measurable handoff to ownership.

Primary reference