From TSA tracking to evidence-based TSA exit

Transition Service Agreements are among the most important—and most underused—sources of information in a divestiture.

Before a TSA is finalized, the seller typically invests significant effort in understanding how the carved-out business operates. Teams perform detailed discovery, assess shared technology, identify logical and physical separation requirements, review contracts and licenses, determine allocation methods, estimate service volumes, define service levels and establish exit assumptions.

That work may involve months of discussions among business, technology, finance, legal, procurement, tax and operational teams. The resulting TSA is therefore more than a commercial agreement. It represents a considerable body of separation knowledge.

Yet once the transaction closes, much of that knowledge disappears from the execution process. The TSA becomes an operating document for service delivery and a checklist for exit. Meanwhile, the buyer often begins separation discovery again.

Why does the buyer have to start over?

During TSA development, the seller may have already identified which applications are shared, how users access them, where they are hosted, which interfaces support them, what data is involved, which contracts and licenses apply and what would be required to separate or replace them.

After close, the buyer launches an application discovery exercise and asks many of the same questions:

• Which applications support the acquired business?
• Who owns them and which users depend on them?
• Are they dedicated or shared, and where are they hosted?
• What data must be migrated and which interfaces recreated?
• Can the underlying licenses transfer?
• What must be completed before the TSA can terminate?

The answers often exist somewhere—in diligence materials, separation assessments, contract reviews, pricing models, legal schedules, architecture documents or the working files used to develop the TSA. But they were not structured for reuse.

The buyer therefore recreates the inventory, repeats interviews, reassesses dependencies and rebuilds the separation logic. Valuable time is consumed rediscovering what was already known.

This is not simply inefficient. It shortens the effective execution window and increases TSA exit risk.

The signed TSA is only the visible tip of the work

A TSA schedule may describe a service in a few lines: provide hosting, support, maintenance and user access for specified business applications.

Behind that description may be a substantial amount of analysis:

• The applications, business capabilities and locations included
• Application and infrastructure dependencies
• Shared and dedicated technology components
• Service volumes and consumption assumptions
• Data ownership and separation requirements
• Software licenses, third-party agreements and required consents
• Security, regulatory and logical separation controls
• Exit prerequisites, lead times, effort and cost

When this supporting knowledge is not connected to the TSA service, the buyer receives the obligation but not the complete execution context. The TSA says what the seller will provide. It may not provide enough structured information to show how the buyer can stop consuming it.

TSA tracking is not the same as TSA exit management

Many programs manage TSA exit through a tracker containing fields such as service ID, description, owner, dates, extension deadline, monthly cost, status and exit date. This is useful for administration, but it does not demonstrate readiness to exit.

A service may be reported as 90% complete while a critical data migration remains unresolved. A replacement application may be implemented while required interfaces still depend on the seller. Users may have new devices but continue to rely on the seller’s identity environment.

The tracker may be green, but the dependency has not actually been removed.

A TSA exit is complete only when the buyer can operate independently and the seller can stop providing the service without unacceptable business, legal, financial, security or operational risk.

That conclusion requires evidence—not a percentage-complete estimate.

What evidence-based TSA exit looks like

Evidence-based exit begins by defining the conditions that must be true before a service can terminate. For an application TSA, the evidence might include:

• The replacement or migrated application is operational
• Required users have access and appropriate roles
• Data has been migrated, reconciled and approved
• Interfaces have been rebuilt and tested
• Infrastructure and monitoring are operational
• Security controls have been validated
• Support procedures and ownership are established
• Contracts and licenses are effective
• Business acceptance has been documented
• Seller access and dependencies can be removed
• Cutover, rollback and stabilization plans are approved

For an infrastructure service, the evidence may involve network connectivity, hosting readiness, backup recovery, monitoring, certificate ownership, operational support and decommissioning approvals.

For end-user services, it may include device deployment, identity migration, collaboration tools, application access, local-site support, service desk readiness, communications and user acceptance.

The exact evidence varies by service, but the principle remains consistent: an exit date is a target. Exit evidence demonstrates readiness.

Preserve the knowledge behind the TSA

The opportunity starts before signing. Instead of treating the TSA schedule as the final output of service-definition work, the program should preserve a structured knowledge package for every TSA service. That package should connect:

• The service to the business processes it supports
• The service to its applications, infrastructure, users, data, contracts and licenses
• The original separation assessment to the agreed TSA scope
• Key assumptions to identified risks and dependencies
• Exit prerequisites to accountable owners
• Exit criteria to the evidence required for approval

This does not mean transferring every seller working file to the buyer. Some information may be confidential, legally restricted, commercially sensitive or outside the transaction perimeter.

It means intentionally identifying the separation knowledge the buyer will need and establishing an appropriate mechanism to make that knowledge available. Without that handoff, the TSA becomes disconnected from the analysis that created it.

Turn the TSA into an execution baseline

A more effective approach is to use the TSA as the starting point for separation execution. Each service should be decomposed into its underlying components and dependencies. Those dependencies should be connected to the buyer’s exit initiatives, milestones, decisions, risks and evidence.

For example, a single “application support” TSA may depend on:

• A new hosting environment
• Identity and access migration
• Historical data extraction
• Several replacement interfaces
• New software licenses and a third-party contract
• Business testing and a support operating model
• Seller decommissioning activities

The TSA should not be marked ready for exit simply because the application migration project reports completion. All the conditions required to remove the service dependency must be satisfied. This creates a direct line from the original TSA obligation to the work required for independence.

Exit is a joint outcome

TSA exit is sometimes treated as primarily the buyer’s responsibility: the buyer builds the replacement capability and notifies the seller when the service is no longer required.

In practice, successful exit usually requires coordinated action from both parties. The buyer must establish independent capability. The seller may need to extract data, transfer knowledge, support testing, remove access, terminate shared processes, modify integrations, allocate licenses, complete contract actions or decommission retained components.

If these activities are not integrated into one exit plan, each party can believe it is ready while the service remains operationally connected. An evidence-based model makes these responsibilities explicit and gives both parties a common definition of completion.

Financial closure is necessary—but not sufficient

TSA exit controls understandably emphasize financial and legal closure: termination notices, final invoices, extension charges, billing schedules and the seller’s liability. These controls are essential. But they should follow operational exit—not substitute for it.

A signed termination notice does not prove that data has been reconciled. A final invoice does not prove that users can operate independently. Removal from the TSA schedule does not prove that seller access has been revoked or that residual dependencies have been eliminated.

True closure requires operational, technical, commercial, legal, security and financial evidence.

The real measure of a TSA program

The quality of TSA management should not be measured solely by the number of services tracked or terminated on schedule. A stronger measure is whether the program:

• Preserved and reused the knowledge developed during TSA creation
• Avoided repeating discovery unnecessarily
• Converted service descriptions into executable exit requirements
• Identified dependencies early enough to act
• Used objective evidence to support exit decisions
• Prevented operational disruption and unplanned extensions
• Removed residual access, cost and liability
• Enabled the buyer to operate independently

The TSA should serve as a bridge between separation strategy and operational independence—not merely as a temporary services catalog.

Final thought

The seller may spend months building the knowledge required to define a TSA. The buyer should not have to spend the first months after close reconstructing that knowledge.

A TSA tracker tells you which services exist, what they cost and when they are expected to end.

An evidence-based TSA exit model tells you whether the underlying dependency has actually been removed.

That is the difference between tracking an agreement and executing a separation.