AI-Powered IT M&A Execution Platform
Exiting a TSA is an important milestone in any separation. It means the buyer can operate the service independently and no longer depends on the seller for that particular capability.
But there is a common assumption that once the TSA ends, the cost associated with it also disappears.
That is not always the case.
A TSA exit confirms that a service is no longer being provided by the seller. It does not necessarily confirm that the applications, infrastructure, contracts, licenses, support arrangements and people supporting that service have been removed or resized.
The transaction may have achieved operational independence while still carrying a significant amount of stranded IT cost.
The migration is complete. The old environment is still running.
Consider an application that has been migrated from the seller’s environment to the buyer’s environment. The users have been moved, testing has been completed and the TSA can be exited.
From the program’s perspective, the application is green.
But what happened to the original environment?
In many cases, it is still running.
The servers may still be active. The database may still be available. Monitoring and backup jobs may still be operating. Interfaces may still be scheduled. Support teams may still have access. The application may even remain covered under existing infrastructure and managed-services contracts.
There are often valid reasons for keeping the environment available for a short period after migration. The problem is when “temporary” becomes indefinite because shutdown was never treated as a separate deliverable.
Migration and decommissioning are related, but they are not the same activity. One does not automatically trigger the other.
Duplicate licenses are easy to create and difficult to remove
Licensing is another common source of stranded cost.
During a separation, the buyer may need to establish new agreements quickly to protect Day 1 or meet a TSA exit date. New licenses are purchased, users are provisioned and the replacement environment becomes operational.
Meanwhile, the licenses embedded in the seller’s enterprise agreement may remain unchanged.
The seller may not be able to reduce the agreement until the next renewal. The vendor may impose minimum commitments. The contract may cover multiple applications or business units. Nobody may have confirmed whether the separated users were actually removed from the licensing baseline.
The result is that both parties can continue paying for some portion of the same capability.
I have seen programs spend considerable time confirming that a new license is available for the buyer, but very little time confirming how and when the old license will be reduced for the seller.
License readiness supports the migration. License removal delivers the savings.
TSA charges can stop while the underlying contracts continue
A TSA charge is often a calculated allocation of the seller’s cost. Ending that charge does not automatically change the commercial commitments behind it.
The seller may still have a three-year hosting contract. A support agreement may include fixed minimum volumes. A network circuit may have a long termination period. A software contract may not permit reductions before renewal.
In one situation, a site had been fully migrated and the related services were removed from the TSA. Operationally, the exit was complete. However, several circuits supporting the site remained active because the telecom provider had not received formal disconnect orders.
The TSA stopped. The invoices did not.
This is why contract actions need to be connected directly to the separation plan. A contract cannot simply be marked “reviewed.” The program needs to know:
- What must be terminated?
- What must be reduced?
- What must be transferred?
- What must remain?
- When can each action legally take effect?
- Who is responsible for confirming that the billing has changed?
Without that discipline, a completed migration can still leave months of unnecessary cost behind.
Cloud does not eliminate stranded cost
Cloud environments can create the impression that cost removal will happen automatically. If workloads are no longer needed, they can simply be shut down.
In practice, it is rarely that simple.
A migrated application may leave behind storage, backups, snapshots, monitoring tools, security services, data-transfer charges, reserved capacity, test environments or disaster-recovery components.
Shared cloud services make the situation even more complicated. The separated application may represent only part of a larger environment, and the remaining environment may not be resized after the workload leaves.
The application has moved, but the cost base has not changed materially.
Cloud cost removal requires its own plan. The team must identify which resources can be deleted, which shared services can be resized, which commitments can be reduced and which retained data has a legitimate business or regulatory purpose.
Turning off a virtual machine is not the same as removing the full cost of the service.
Users and devices leave behind costs too
End-user migrations often focus on whether the employee can work successfully in the new environment.
Can the user sign in? Is the device configured? Are the required applications available? Can the user access email, collaboration tools, files, printers and business systems?
Once those tests pass, the user is considered migrated.
But several cost-related questions may remain:
- Was the old account disabled and eventually removed?
- Was the previous device recovered or retired?
- Were mobile subscriptions cancelled?
- Were software licenses reclaimed?
- Was the user removed from support and security tools?
- Were virtual desktops and remote-access services deprovisioned?
- Were retained devices removed from maintenance contracts?
On a large separation, even a small monthly cost per user can become significant when multiplied across thousands of users.
The migration team measures whether users moved successfully. Someone also needs to measure whether the old services stopped costing money.
Support models often remain oversized
Technology is not the only source of stranded cost.
Support organizations are often sized around the pre-separation environment. After applications, users, sites and infrastructure move away, the operating model may remain largely unchanged.
Internal teams may continue performing monitoring, service management, security, vendor management and application support activities for a smaller technology estate. Managed-service agreements may still be based on the original scope. Service towers may have minimum staffing commitments that were not reconsidered during the separation.
This is not necessarily a people-reduction exercise. It is an operating-model question.
What work disappears after the separation? What work remains? What capabilities need to be resized? What temporary separation support should end? What knowledge must be retained?
If these decisions are deferred until after TSA exit, the cost can remain for much longer than expected.
The problem starts when cost removal is treated as a finance exercise
Stranded cost is often discussed at a high level during deal planning and then handed to finance for tracking.
But finance cannot remove an application, disconnect a circuit, terminate a license, delete a cloud environment or redesign a support model.
Those actions sit within the technology workstreams.
Every material cost assumption should therefore be connected to a specific operational action. If the business case assumes that an application will be retired, the plan should identify the retirement owner, dependencies, target date, contract implications, data-retention requirements and evidence of shutdown.
If the savings depend on reducing a vendor agreement, the program should know when the reduction can occur and what notice must be provided.
A cost target without an executable technology action is only an assumption.
Evidence-based cost exit
TSA exit should be supported by evidence that the buyer can operate independently. Cost exit should be supported by evidence that the old cost has been removed or formally accepted.
That evidence may include:
- Confirmation that legacy infrastructure has been decommissioned
- Vendor acknowledgement of contract termination or reduction
- Updated license counts and commercial baselines
- Cloud billing showing that resources were deleted or resized
- Confirmation that user accounts and devices were removed
- Closure of support services and operational monitoring
- Final invoices reflecting the expected change
- Documented approval for any cost that must remain
This does not mean every cost must disappear on the exact TSA exit date. Some costs will naturally lag because of contractual commitments, retention requirements or operational safeguards.
But the remaining cost should be understood, owned and time-bound.
Independence is only part of the outcome
A successful separation must protect business continuity and establish operational independence. Those will always be the first priorities.
But the transaction economics also matter.
If the TSA has ended while duplicate environments, licenses, contracts and support arrangements continue, the separation is operationally complete but financially unfinished.
The right question is not only:
“Have we exited the TSA?”
It is also:
“What has actually stopped, what are we still paying for, and who owns removing the remaining cost?”
That is the difference between tracking a TSA exit and completing the separation.