TSA Exit Acceleration
Leave nothing running behind you.
Senior operators on day one. Fixed-fee engagements. The first conversation is always free.
TSA decommissioning is the controlled teardown of the seller infrastructure, accounts, and access the divested business used during the agreement, done once you have safely migrated off it. Skip it and you leave servers billing, accounts open, and your data sitting in someone else's estate long after you thought the engagement was over. Treat it as the final, planned stage of the TSA exit strategy, not an afterthought.
Most exit attention goes to migration: standing up your own systems and moving onto them. That is the visible, satisfying half, and it is where teams declare victory. The other half is decommissioning, the deliberate shutdown of everything the seller was running for you once you no longer need it. It gets neglected precisely because it happens after the business has already moved, when the urgency has drained out of the room.
Neglect has a price. Seller servers and cloud environments keep accruing cost until someone formally turns them off, and a TSA charge often runs until the service is cut, not until you stop using it. Accounts left open are a security exposure. Integrations left connected are a path for data to keep flowing where it should not. The seller environment does not clean itself up, and what is left running is your liability, not theirs.
The exit is genuinely finished only when the seller estate that supported the carved-out business is dark, its accounts are closed, and its data is settled. Until then you carry cost, risk, and an open thread on the engagement. Treating decommissioning as a planned stage with its own owner and deadlines, rather than a tidy up someone will get to eventually, is what closes the exit for real.
The teardown list is longer than the obvious servers. Start with compute and storage: the virtual machines, databases, file shares, and cloud accounts the seller provisioned for the business. Each carries a running cost and often holds a copy of your data, and each needs an explicit decision to retire it rather than a quiet assumption that it stopped mattering once you migrated.
Then the access layer. Every account the business used on a seller managed system, every service account and API key, every VPN path and federated login that let your people into the seller's environment or the seller's people into yours. Identity deprovisioning is a workstream in its own right, and decommissioning is where the residual access that survived the cut gets found and closed for good.
Finally the connective tissue. Integrations and data feeds that moved information between seller and buyer systems, monitoring and backup jobs that still point at retired infrastructure, DNS entries and certificates tied to seller domains, and the supporting tooling nobody thinks of until it alerts. A complete decommissioning inventory captures all of it, because the item left off the list is the one that keeps billing or stays open as a door.
The cardinal rule of decommissioning is order. Tear down a seller environment before your own replacement is proven and you have removed your only fallback at the worst possible moment. The disciplined sequence is migrate, validate against real workloads, run in parallel for a defined window, and only then decommission. Each step confirms you are safe to lose the seller system before you actually lose it.
The parallel window is the safeguard worth paying for. Keeping the seller environment available, but no longer in active use, for a short defined period after the cut gives you a known good state to fall back to if something in your own systems surfaces a problem. The cost of a few extra weeks of standby is small against the cost of discovering a gap after the only copy of a working system has been wiped.
Decommission in dependency order, not all at once. Some systems feed others, and switching off an upstream component can break something downstream you have not yet retired. Working from a dependency map, retiring leaf systems first and shared infrastructure last, keeps the teardown from cascading into an outage. The teardown is as much an engineered sequence as the migration that preceded it.
No seller system gets wiped until its data has a disposition. Every data set sitting in the seller environment falls into one of three buckets, and the buyer has to decide which before anything is switched off. Get this wrong and you either lose information you needed or leave information behind that should never have stayed in the seller's hands.
Retain what is yours. Before any teardown, confirm you hold a complete, verified copy of everything the business needs: operational data, records you are obliged to keep, and history you will want later. Return what is the seller's, where the environment held data that belongs to them or to retained parts of their business. Destroy what should not persist, with certification: data the seller holds about you that has no reason to remain once you have your copy.
Certified destruction matters because the alternative is an open compliance and security exposure. Your data sitting on decommissioned seller media, or in a backup nobody deleted, is a breach waiting to happen and a regulatory question you cannot answer. Documented proof that each data set was retained, returned, or destroyed turns the data side of decommissioning from a loose end into a closed, defensible record.
Decommissioning has a commercial close as well as a technical one. Who bears the cost of teardown, data extraction, and any seller wind down work should have been settled in the TSA before signing, because a silent agreement lets those charges land on the buyer as a final invoice after the work is supposedly done. Reconciling the last service charges against the actual cut dates is part of leaving clean.
Confirm the meter has actually stopped. A service formally exited should generate no further charge, yet seller billing systems do not always catch up, and a decommissioned environment can keep appearing on an invoice. Checking that each retired service has dropped off the bill, and challenging anything that lingers, is the difference between a TSA that ends and one that quietly keeps costing money for months.
Finish with a documented close: an inventory of what was decommissioned, when, by whom, and with what data disposition, plus written confirmation from the seller that the environment is retired and the charges have ended. A buyer that migrates carefully, tears down in order, settles its data, and closes the contract exits with nothing left running behind it. Building that final teardown into the plan is part of our TSA Exit Acceleration work.
It is the controlled shutdown of the seller infrastructure, accounts, and access the carved-out business used during the TSA, once you have migrated off it. Servers are retired, accounts are closed, integrations are severed, and data is retained, returned, or destroyed under a documented plan. The aim is that nothing the seller ran for you keeps running, billing, or holding your data after exit.
Because tearing down a seller environment before you have confirmed your own is fully live and stable risks an outage with no fallback. The disciplined sequence is migrate, validate, run in parallel briefly, then decommission. The cut moves you onto your own systems. Decommissioning is the deliberate cleanup that follows once you are certain you no longer need the seller's.
It depends on what the agreement says, which is why it should be addressed before signing. Wind down costs, data extraction charges, and any teardown the seller performs can land on the buyer if the TSA is silent. A clear exit provision that defines who bears decommissioning cost prevents a final invoice that arrives after you thought the engagement was finished.
Every data set gets one of three dispositions: retained by you because you need it, returned to the seller where it is theirs, or destroyed with certification. The buyer needs a complete copy of everything it requires before any seller system is wiped, and documented proof of destruction for anything that should not persist. Doing this after teardown is too late.
Finding the undocumented systems before the seller goes dark.
Read the article →Removing every seller identity and access path at the cut.
Read the article →Reconciling entitlements so you neither lose access nor pay twice.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Senior operators on day one. Fixed-fee engagements. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →