A TSA works when its schedules make a temporary dependency operable, measurable, and replaceable. A service list and an end date are not enough. Define each service’s boundary, baseline, access, data, price, and exit evidence.

The negotiation has two outputs: continuity for selling, delivery, invoicing, payment, close, customer support, and controls; and ownership, so the buyer can build, test, accept, and run the replacement. Without the second, a stable TSA can still let the exit slip.

Turn the exit design into a schedule

Start with the future operating boundary, then describe the temporary service that bridges to it. The seller’s service catalogue is evidence, not a contract schedule: it describes the parent model, not what the buyer must receive or own.

For every service, write one service card before negotiating price:

Schedule field Required decision
Business outcome Payroll, order processing, close, reporting, customer support, or another named result
Service boundary Entities, locations, users, systems, environments, interfaces, jobs, and support
Exclusions Project work, enhancements, new sites, and unplanned volume the seller will not provide
Dependencies Vendors, licenses, networks, identity, data, facilities, people, and buyer capability
Baseline Volumes, service hours, incidents, performance, open changes, and assumptions at start
Service measure Unit, target, measurement source, reporting cadence, and exception treatment
Exit obligation Data, access, documentation, testing, transfer, cutover, and acceptance evidence
Commercial rule Fixed fee, unit rate, volume band, cap, true-up, credit, or change mechanism

This format exposes missing decisions early. “ERP support” may exclude master-data fixes, interfaces, and month-end assistance. If an exclusion blocks replacement, it needs a priced work package, buyer capability, or different exit plan. Name the business and technology owners.

Establish the baseline before setting the SLA

An SLA without a baseline creates a dispute about what the seller agreed to preserve. Freeze each service’s baseline at an agreed measurement date; it should cover more than tickets.

Record the demand and operating conditions that shape delivery:

  • users, entities, sites, environments, interfaces, service accounts, and transaction volumes
  • service hours, maintenance, coverage, performance, measurement source, incidents, defects, workarounds, and planned changes
  • suppliers, named roles, data quality, retention, and invoice or usage reports needed to reconcile consumption

Give the baseline an owner and correction process. Do not reset it when demand rises. If volume is outside the assumption, define the band, notice period, pricing rule, and approval path before consumption.

Make service levels testable

An SLA should answer four questions: what is measured, how, who reports it, and what happens when it is missed. Availability alone is rarely enough; a finance service can be up while a close-critical interface is late or a batch cannot be reconciled.

Set measures around the business outcome and control points:

  • incident response, restoration, workaround, and resolution by severity
  • scheduled jobs, transaction processing, interface delivery, and reconciliation accuracy
  • user and privileged-access provisioning within the agreed window
  • data extract completeness, format, timing, error correction, and service-request ageing
  • planned-change success, rollback, and notice

Define severity by business impact, not ticket count. A failure blocking payroll, customer billing, production, or close belongs in the highest-impact path. State who can declare it, how the seller is notified, and which route applies outside normal hours.

State whether maintenance is excluded, how partial service is treated, which clock applies across time zones, and what raw evidence validates the report.

Service credits do not repair a missed business outcome. A repeated miss should trigger corrective action, escalation, or a readiness review; an exit-critical service may need extra testing support or a recovery plan.

Separate run support from change and project work

“Reasonable assistance” is not a service definition. Data extraction, interface changes, replacement configuration, cutover testing, and support for a new entity belong in a separate schedule or the base service.

Classify requests into three paths:

  1. Run support: incidents, standard requests, monitoring, routine operations, and recurring reporting within the baseline.
  2. Standard change: repeatable, low-risk changes with a defined unit, lead time, approval, and rollback procedure.
  3. Project or exit work: migration, data remediation, new interfaces, redesign, test cycles, cutover, hypercare, and decommissioning.

For each path, define intake, estimate, approval, delivery evidence, and output ownership. State how the buyer can challenge an estimate, use another provider, or reduce scope when the seller misses the date.

Use a rate card only when the unit and deliverable are clear. Otherwise use a work order with scope, assumptions, milestones, acceptance criteria, and a cap. A cap without scope only delays the dispute. Require warning before the limit and an executive decision for additional funding.

Negotiate cutover support as a named work package: rehearsal, freeze coordination, data validation, command-centre coverage, rollback, and stabilization. Otherwise the seller can meet the run SLA while declining exit work.

Contract access and data as operating rights

The buyer cannot replace a service it cannot inspect. Access rights should support operation, security, testing, and transition without exceeding the permitted boundary.

For each system and dependency, decide whether the buyer receives:

  • named access, service accounts, API credentials, certificates, and key rotation
  • read-only, operator, or administrator rights, with approval and logging
  • monitoring, event logs, incident history, configuration, topology, and backup evidence
  • test environments, masked data, test users, vendor portals, and escalation rights
  • data extracts with format, frequency, metadata, history, reconciliation, and error correction

“Access on request” is not a workable right. State the request route, response target, approver, evidence, and fallback. If privileged access is prohibited, define the seller-operated action, audit evidence, and maximum response time.

Distinguish operational data, history, metadata, logs, and derived reports. The replacement may need history to reconcile balances, support customers, or validate a migrated master. State what is delivered before each exit wave and how completeness is proved. Counsel should determine permitted use, retention, transfer, privacy, and deletion terms; the technology schedule should identify the data and handoff test.

Put security and control obligations beside the service

Security cannot be a general statement that each party follows its own policy. Specify the controls needed at the transaction boundary and the evidence exchanged between providers.

At minimum, assign responsibility for:

  • identity federation, MFA, privileged access, service accounts, and access reviews
  • endpoint, network, cloud, application, and vulnerability monitoring
  • logging, retention, alert triage, incident severity, and cross-party escalation
  • backup, restore, disaster recovery, remediation, exceptions, and third parties

For a security event affecting the buyer’s service, define notification, evidence, containment authority, and the business decision maker. If legal notification or reporting may apply, counsel sets the obligation and timing; the schedule states who gathers facts and communicates through the approved route.

Make knowledge transfer a demonstrated deliverable

Documents are an input, not completion. For each critical service, require configurations, interfaces, batch schedules, defects, workarounds, monitoring, vendor contacts, runbooks, recovery procedures, and named people for walkthroughs and testing.

Use a three-step proof:

  1. The seller explains the process and provides the working artifacts.
  2. The buyer performs the process under observation, including an exception path.
  3. The buyer operates the process without seller intervention and receives sign-off from the service owner.

Test an exception path: failed batch, rejected file, access removal, vendor escalation, data mismatch, or rollback. If the buyer can complete only the normal path, the service is not ready.

Name a replacement owner before transfer starts. If no person or provider can receive the service, add capacity, change the exit wave, or keep it in scope while capability is established.

Choose price units and caps that match consumption

Select a measurable commercial unit: users, entities, sites, transactions, interfaces, environments, tickets, jobs, or service hours. Avoid a unit the seller controls or that cannot be reconciled to the baseline.

Use a fixed fee for a stable service, unit pricing for predictable variation, a cap for bounded uncertainty, and a work order for project scope. These mechanisms can coexist.

Every variable mechanism needs a baseline, volume definition, notice period, invoice detail, and true-up rule. Every cap needs scope, measurement period, warning threshold, approval owner, and unused-capacity treatment. A cap that excludes exit work protects the wrong cost.

Negotiate extension pricing before close. It should reflect remaining scope, with step-downs where volume or seller effort declines. Retain a route to accelerate exit or use another provider when the seller cannot deliver. Counsel assigns the rights; technology provides the dependency and readiness evidence.

Separate governance forums and decision rights

One meeting cannot manage incidents, invoices, scope, security, and exit acceptance well. Use separate forums with explicit decisions.

Operational review covers service levels, incidents, requests, changes, capacity, security events, and actions, with a chair and escalation route.

Commercial review covers consumption, invoices, disputed charges, caps, forecasts, credits, work orders, and extensions; finance and procurement reconcile the bill to the baseline and approvals.

Exit review covers replacement readiness, data and access, knowledge-transfer evidence, tests, defects, cutover, and acceptance. The service owner signs off; the separation lead coordinates; the executive sponsor resolves risk acceptance or a date change.

Write decision rights into the schedule: who may approve a change, declare severity, accept degradation, authorize emergency work, extend service, accept evidence, and approve a fallback. A steering group resolves conflicts.

Define exit acceptance before the end date

Exit is an acceptance event, not a calendar event. A replacement service should pass four tests:

  • Operational: the named users and teams can run the required process, including an exception path.
  • Technical: systems, interfaces, batch jobs, certificates, monitoring, and backups work under buyer control.
  • Data and control: required records reconcile, access is correct, security evidence is accepted, and reporting can continue.
  • Support: buyer or replacement-provider owners can receive incidents, manage changes, contact vendors, and restore service.

Each test needs evidence, an approver, a defect classification, and a cure period. Define which defects block exit and which can remain on a backlog. A cosmetic documentation issue should not hold a service indefinitely; an unowned privileged account should.

If acceptance fails, state the choices: cure and retest, a limited extension, a narrower exit wave, an approved fallback, or executive risk acceptance. An extension needs its own scope, price, support, and next acceptance date.

Use if/then triggers to keep the schedule honest:

  • If the proven build, migration, and test path exceeds the TSA term, change the term, narrow the promise, or fund a minimum standalone capability before signing.
  • If an exit-critical activity is excluded from run support, add a priced work package, assign a buyer owner, or move the exit gate.
  • If the seller will not provide the access or data needed for testing, add a seller-operated test with evidence and a fallback; do not treat a verbal commitment as readiness.
  • If the replacement owner cannot perform the exception path, hold acceptance and address capability before reducing seller coverage.
  • If a security or data condition requires legal interpretation, stop the operational assumption and obtain counsel’s direction before transferring or granting access.

Negotiate trade-offs explicitly

The buyer will rarely receive maximum scope, control, flexibility, and low cost at the same time. Record the trade-off.

Buyer need Seller concern Negotiation mechanism
Shorter term Unfunded transition effort Narrow the boundary, fund exit work, and add readiness-based protection
Broad scope Unbounded demand Freeze the baseline, define volume bands, and price approved changes
Buyer administrator access Security and control exposure Use named accounts, least privilege, logging, approval, and periodic review
Flexible project support Capacity and priority conflicts Use a rate card, queue rules, lead times, caps, and escalation rights
Reliable data handoff or hard exit Privacy and readiness uncertainty Define extracts, reconciliation, evidence gates, cure periods, fallback, and a priced extension path

Ask which risk the term transfers, who controls it, and whether price and schedule show that transfer. Counsel should draft and interpret protections, liability, confidentiality, privacy, assignment, and other legal terms. Technology and business teams supply the operational boundary, dependency, evidence, and consequence.

The pre-signing schedule pack

In the next 10 business days, the separation lead should coordinate a review with technology, process owners, finance, procurement, security, vendor owners, and counsel. Produce five artifacts:

  1. Service schedules for every retained dependency, with scope, exclusions, baseline, SLA, access, security, and owner.
  2. Change and exit work orders for migration, data, testing, cutover, hypercare, knowledge transfer, and decommissioning.
  3. Commercial model showing units, volumes, fixed and variable charges, caps, project assumptions, extension exposure, and buyer run cost.
  4. Acceptance matrix linking each exit gate to a test, evidence source, approver, defect rule, fallback, and decision date.
  5. Issue list for counsel and executives covering rights, obligations, unresolved assumptions, risk acceptance, and decisions that affect the deal model.

Review the pack against first-close, payroll, order-to-cash, procure-to-pay, reporting, security, and customer-support workflows. Ask which service supplies each, which schedule controls it, and what evidence allows ownership. If the answer stops at “seller support,” the agreement describes dependency rather than transition.

A workable TSA protects continuity while making itself smaller. Its schedules tell the seller what to deliver, the buyer what to build, finance what to pay, operators what to test, and counsel what requires protection. The negotiation is complete when the exit path is as concrete as the Day-1 service.

Primary reference