Managing TSA dependencies and exit risks • EL BANTLI

TSA exit is an execution decision, not a contract-expiry decision: the buyer should end each service only when it can own the business outcome, operate the dependency chain, and prove that the seller can be removed without delaying the value plan.

That requires more than a list of services and a target date. After close, the buyer has to control a live system of applications, interfaces, data feeds, people, vendors, approvals, and commercial commitments. One seller-provided service can depend on another seller service, a shared identity tenant, an undocumented batch job, or a person who is not included in the stated scope. If the dependency is discovered at cutover, the buyer has already run out of cheap options.

The practical objective is to make every dependency visible, assign a path to independence, and release services in waves with evidence. The TSA is then a managed runway to ownership. It is not a substitute for capability, and it is not a reason to move the value case to an undefined later date.

Start with the dependency graph

The service catalogue says what the seller provides. The dependency graph shows what must be true for the buyer to operate without it. Build the graph from business outcomes rather than from supplier names.

Start with the processes that cannot stop: order entry, fulfilment, billing, cash collection, procure-to-pay, financial close, payroll, customer support, regulatory reporting, and security response. For each process, trace the services and controls underneath it. A payroll service may depend on identity, HR master data, time capture, bank files, tax configuration, an integration platform, and a support queue. “Payroll” is one TSA line but a chain of dependencies.

Each node should have a clear owner, provider, operating boundary, and intended end state. Each edge should describe the relationship in plain operational terms:

Dependency type	Question to answer	Exit implication
Control	Who can administer, approve, change, or recover the service?	Buyer access and decision rights must exist before handoff.
Data	Which records, extracts, metadata, and histories are required?	Data scope, reconciliation, retention, and post-exit access need evidence.
Timing	Which batch, close, payroll, or transaction window relies on another service?	The exit must be rehearsed against the full operating calendar.
People	Which roles know the exceptions, procedures, and vendor contacts?	Capability and knowledge transfer must be tested, not merely documented.
Commercial	Which license, contract, volume, or renewal permits the service?	Rights and cost must survive the cutover or have a replacement.

The graph should distinguish a direct dependency from a shared control. A buyer may replace the seller’s service desk but still rely on the seller’s identity provider for privileged access. It may move an application to its own hosting account while the seller continues to own the certificates, monitoring, backup keys, or network route. The application has moved; operational control has not.

Use four labels for each relationship: required for Day-1, required for the next exit wave, required only for a value change, or retained by design. The last label matters. Not every seller connection needs to disappear if the buyer has a deliberate, priced, and governed long-term arrangement. Calling a permanent dependency a TSA exit item creates false urgency; calling a temporary dependency permanent hides the real work.

Find the critical path through the graph

The critical path is not the longest project schedule. It is the sequence of conditions that can stop the business from operating independently. Identify it by tracing backward from a business acceptance outcome.

For each process, ask:

What transaction or control must work after seller access ends?
Which service produces or authorizes it?
Which data, interface, identity, infrastructure, vendor, and person must be available for that service to work?
What is the latest date for each replacement, test, and decision if the exit date is to hold?
What evidence would allow the business owner to accept the outcome?

This produces a chain such as: buyer-controlled identity, privileged access, application administration, interface monitoring, reconciled data, business transaction, and period-end control. The chain may cross several workstreams. Its criticality comes from the business outcome, not from which team reports the task.

Score the edges, not just the systems. A system with a low incident count may still sit on the only path to bank file transmission. A shared reporting warehouse may look non-operational until the controller cannot complete the close without it. A vendor consent may be a one-page document but block the entire replacement environment.

Use a simple rule for escalation: if failure of an edge can stop revenue, cash, payroll, close, customer service, safety, security response, or a regulatory obligation, it belongs on the critical path until a tested alternative exists. Everything else can be sequenced around it. This keeps the program from treating every dependency as urgent while preventing convenience work from displacing operating controls.

Service-to-service coupling is where schedules usually become unreliable. Model coupling explicitly when services share any of the following:

one identity directory, network route, integration platform, or hosting account
one master-data source or batch schedule
one support queue, privileged role, or vendor contract
one change window, close calendar, or recovery process
one environment that cannot be tested independently

If two services share a control plane, they may need to exit together or in a sequence that preserves the control. The buyer should not split a wave merely because the service catalogue has separate lines.

Design exit waves around control and coupling

An exit wave is a set of services that can move through design, build, test, cutover, and stabilization with one coherent acceptance decision. It should be small enough to manage and complete enough to avoid leaving a hidden control dependency behind.

Use four wave types.

Wave 0: establish buyer control

This wave does not necessarily end a TSA service. It makes the later exit possible. Establish buyer-owned identities, privileged access, service-management routes, monitoring, backup visibility, vendor contacts, contract rights, and the service baseline. Capture the seller’s configuration and exception knowledge while access is available.

The acceptance question is: can the buyer see, authorize, escalate, and recover the service even while the seller still operates it? If not, later delivery is being performed inside a blind spot.

Wave 1: low-coupling services

Move services with a clear boundary, limited shared data, and an available buyer owner. Examples may include a standalone endpoint service, a dedicated collaboration tenant, or a vendor contract that can be assigned without changing a core transaction. These exits test the buyer’s service-management model and expose weaknesses in access, support, and cutover evidence.

Do not pick the first wave only because it is easy. It should also test a capability that later waves depend on. If buyer incident management has not been exercised, a technically simple exit may still leave the program unprepared for a business-critical handoff.

Wave 2: business-process services

Move coupled services only after the buyer can run the end-to-end process. Finance, HR, customer operations, and supply-chain exits commonly require data reconciliation, interface testing, calendar-based rehearsals, and business acceptance. A process owner—not only a technology lead—must approve the wave.

Run at least one rehearsal under buyer control before the final cutover. For transaction services, test a complete cycle and the exception path. For finance, include close activities, reconciliations, approvals, reporting, and evidence retention. For payroll, include joiners, leavers, corrections, funding, and statutory outputs. The point is not to prove that a screen works; it is to prove that the business control works.

Wave 3: residual services and decommissioning

The final wave removes remaining access, feeds, environments, support obligations, and seller cost. It often has fewer visible users but more hidden dependencies. Historical data, audit access, backup retention, scheduled jobs, certificates, dormant service accounts, and vendor renewals need explicit treatment.

Do not declare a wave complete when the replacement is live. The wave completes when the old service is no longer needed, the buyer has the required records and controls, and the seller’s access and charges have ended or been deliberately retained.

Waves can run in parallel only when their shared controls, support capacity, data boundaries, and fallback plans are independent. Parallel delivery is not free capacity. If two waves compete for the same seller specialist or buyer testing team, the program has created a hidden queue.

Make acceptance gates evidence-based

An exit date should be the final point in a gate sequence, not the first item on a calendar. Each service needs an acceptance owner from the business, a delivery owner from technology, and an accountable TSA owner who can escalate a missed condition.

Use five gates:

Boundary gate: scope, entities, data, contracts, interfaces, and retained responsibilities are confirmed.
Capability gate: buyer roles, coverage, access, runbooks, monitoring, vendors, and escalation routes are ready.
Transaction gate: representative business transactions and exception paths complete under buyer control and reconcile to the source.
Operational gate: the service survives a support rehearsal, recovery test, security review, and the relevant close, payroll, or operating cycle.
Decommission gate: old access, jobs, routes, licenses, environments, and charges are removed or recorded as an approved retained dependency.

The acceptance pack should contain test results, reconciliations, open defects, control approvals, support contacts, cutover records, and a signed residual-risk decision. A green status with no evidence is not an acceptance gate. Neither is a signed technology checklist that the finance, HR, operations, or security owner has not reviewed.

Set no-go criteria before the cutover meeting. Examples include an unreconciled critical data set, missing privileged access, an untested recovery route, unresolved vendor rights, absent support coverage, or a failure in a payroll, close, bank, or revenue-critical cycle. The threshold should reflect the process control. “No open defects” is usually too broad; “no unowned defect that can prevent invoicing” is testable.

Contract for the seller inputs the graph requires

The seller’s obligation is not complete when it continues to answer tickets. Exit work needs inputs that ordinary service levels rarely cover.

For every critical dependency, specify the seller input, format, owner, due date, review window, and consequence of delay. Inputs commonly include:

administrative access, service accounts, certificates, logs, monitoring, and backup information
data extracts with definitions, history, metadata, reconciliation support, and permitted use
configuration, interface maps, batch schedules, runbooks, known defects, and incident history
named subject-matter experts, shadowing time, reverse-shadowing, and replacement support
vendor contacts, assignment or consent documents, license details, renewal dates, and support rights
test environments, masked data, change windows, cutover support, and rollback assistance

Make the request measurable. “Provide knowledge transfer” can be satisfied by a presentation that does not transfer operating ability. “Provide data” can be satisfied by an extract that cannot be reconciled. Define completion as a usable artifact plus a demonstrated procedure or accepted test.

The TSA owner should track seller-input aging separately from buyer delivery status. A buyer workstream can be late because it is late, or because a seller input is missing. Those cases need different remedies. Escalate through the service owner, steering group, and deal governance in that order, with the commercial consequence visible before the exit gate is missed.

Build buyer capability before the handoff

A replacement platform is not a replacement service. The buyer needs people, operating procedures, control ownership, support coverage, and a way to make changes after the seller leaves.

For each service, identify the minimum capability required at exit:

who owns the service and who approves changes
who provides first-line, second-line, and specialist support
who manages privileged access, security events, backups, and recovery
who owns the vendor, license, renewal, and consumption decision
who performs the business control and accepts exceptions
what coverage is required outside normal working hours or across countries

Use a staged transfer where the risk warrants it: seller demonstrates, buyer shadows, buyer performs under observation, then buyer operates while the seller remains available for defined escalation. Reverse-shadowing is the important step. It shows whether the buyer can execute an actual procedure rather than repeat the seller’s explanation.

Capability gaps should be visible in the cost and timing model. A hire, managed service, contractor, retention arrangement, or temporary buyer team may be required before the exit. Do not count an exit as funded because the replacement software has been purchased.

Track consumption and total exit cost

TSA cost needs a bridge from current consumption to independent run cost. The monthly invoice is only one part of it.

Track at least five components:

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

Use measurable units where possible: users, transactions, tickets, environments, interfaces, storage, hours, or legal entities. Compare actual consumption with the baseline and the remaining exit plan. A low base fee can still be expensive if testing, data correction, report changes, vendor calls, and cutover support are out of scope.

The TSA scorecard should show, by service:

current volume and trend against the agreed baseline
included capacity consumed and out-of-scope requests
project work approved, delivered, and still needed for exit
buyer capability spend and unfilled roles
cost of dual running, extension, fallback, and decommissioning
the value date that depends on the service leaving or changing

This view supports a decision before the extension is unavoidable. If an exit is late, compare the cash cost and operational risk of extending with the cost, risk, and value delay of accelerating. Treat the comparison as a business decision, not as a negotiation held after the contract has expired.

Define extension triggers before the deadline

An extension can protect continuity, but an open-ended extension turns a temporary dependency into the target operating model. Agree the trigger, approver, scope, duration, price, and required remediation before close.

Typical extension conditions include:

an acceptance gate failed for a defined business or control reason
a seller input or vendor right was delayed and the buyer has a dated recovery plan
a critical defect has a tested workaround but not yet a durable fix
a regulatory, customer, payroll, close, or safety obligation makes the fallback unacceptable
a connected service wave cannot exit without breaking a shared control

An extension request should include the failed condition, evidence, owner, recovery date, incremental cost, and effect on the value plan. It should also state what will be removed from scope if the extension is approved. “Same service for another quarter” is not a plan.

Set a second decision point before the extension ends. If the same condition remains unresolved, the steering group should choose among accelerated capability, a new provider, a redesigned process, a longer priced extension, or an approved retained dependency. Repeating the same date with the same evidence gap is not risk management.

Prove decommissioning, not just go-live

Decommissioning is the evidence that the seller dependency has actually ended. Without it, the buyer may continue paying for dormant services and leave an attack path or reconciliation obligation behind.

The decommission pack should record:

seller and buyer access removed or retained under an approved control
service accounts, certificates, keys, routes, firewall rules, and integrations retired
batch jobs, alerts, monitoring, backup schedules, and recovery procedures updated
historical records archived or made accessible under the required retention rules
open transactions, tickets, incidents, and vendor obligations closed or transferred
licenses, subscriptions, minimum commitments, and support charges terminated or resized
final consumption reading, invoice reconciliation, and dispute resolution
named approval from security, finance, records, operations, and the TSA owner

Do not delete evidence to create a clean exit report. Retain the records needed for audit, legal, tax, customer, and regulatory obligations. Decommissioning means ending the operational dependency while preserving the required history.

Tie exit timing to value timing

TSA exits affect value in two directions. They can remove seller cost and release buyer capacity, but they can also unlock a process change, data use, system consolidation, or control improvement. The value case should show which condition is required for each benefit.

Create a TSA-to-value register with four fields: value lever, dependency, acceptance gate, and earliest credible value date. If a procurement benefit depends on a buyer-controlled supplier master, the date follows the data and control gate. If a cost benefit depends only on stopping a seller service, the date follows effective termination of the charges and decommission evidence; reconcile the final invoice separately. If the value lever requires a transformation after independence, do not count the transformation benefit at TSA exit.

This prevents two opposite errors. A program can claim value too early because the replacement went live, or delay value unnecessarily because a low-risk service remains under a priced, deliberate arrangement. The right date is the first date when the process can operate, the control owner accepts it, and the cost or benefit mechanism is actually active.

Install a short operating cadence

The TSA owner should run a weekly service review with service owners, workstream leads, finance, security, and procurement. Review dependency changes, seller inputs, consumption, incidents, acceptance evidence, and the next decision date. Each service gets one status for continuity and another for exit readiness; a stable service can still be late for exit.

The steering group should meet on a fixed cadence to decide gate failures, funding, extensions, retained dependencies, and value-date changes. Bring decisions with evidence and a recommendation. Do not use the forum to read the full tracker.

Keep one integrated critical path across the TSA, buyer capability, vendor work, testing, cutover, and decommissioning. If a date changes in one plan but not the others, the dependency graph is no longer the source of truth.

Build the exit-control pack

The separation lead, TSA owner, technology lead, finance lead, security lead, and business acceptance owners should produce five outputs:

Dependency graph: every critical business outcome, service, control, data flow, person, vendor, and commercial edge, with owner and intended end state.
Critical-path register: the conditions that can stop each exit, latest decision dates, seller inputs, buyer capability, and fallback.
Exit-wave plan: services grouped by coupling and acceptance path, with rehearsal, cutover, stabilization, and decommission milestones.
Cost and consumption bridge: base fees, variable use, project work, buyer run cost, dual running, extension exposure, and value timing.
Evidence and extension pack: acceptance criteria, no-go thresholds, evidence owners, extension triggers, and required approvals.

Then select the next exit wave by asking one testable question: what is the smallest group of services that can leave the seller without leaving a hidden control dependency behind? Fund that wave, prove it, and use the evidence to reset the remaining schedule. Independence is achieved service by service, but the business accepts it end to end.