Multi TSA Portfolio
An exit sequenced on the dependencies.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
TSA dependency mapping is the discipline that decides the order and the timing of every exit. The buyer who maps which service feeds which, and which milestone cannot start until another finishes, exits on the critical path rather than in the order the service catalog happens to list. A dependency map is one of the first artifacts that turns day one readiness into a defensible plan rather than a wish.
A TSA service catalog arrives as a flat list. Payroll, email, the ERP, the data warehouse, the helpdesk, each with a charge and an end date. Read as a list, it invites the buyer to exit the cheapest or the easiest service first. That instinct is wrong, because the services are not independent. Exiting one before its dependents are ready can strand the dependents on a system that no longer exists, and the buyer discovers the link only when something breaks.
Dependency mapping replaces the list with a network. Each service becomes a node, and each link records that one service relies on another to function. The map shows, for example, that the buyer cannot exit the seller's identity service until every application that authenticates through it has been migrated, because exiting identity first would lock users out of systems the buyer still depends on. The link was always there. The map makes it visible before it causes an outage.
The map also exposes the difference between a service that can exit early and one that gates everything behind it. A service with no dependents can leave the moment its own replacement is ready. A service that a dozen others rely on sits on the critical path, and its exit date drives the schedule for everything downstream. Knowing which is which is the whole point of the exercise, and it cannot be read off a flat list.
Most TSA dependencies fall into three kinds, and a useful map labels each one. Service to service dependencies, where one service feeds another, such as the order system that pushes invoices into the finance system. Data dependencies, where a migration must finish before a system can stand on its own, such as the customer records that must land in the new platform before the old one can be switched off. Resource dependencies, where the same people or test environments are needed by more than one workstream at the same time.
The three kinds constrain the sequence in different ways. A service to service dependency is usually firm: the feed exists or it does not. A data dependency carries a duration, because the migration takes weeks and the dependent exit cannot be scheduled until the migration window is known. A resource dependency is the one teams forget, because it does not appear in any contract. Two workstreams that both need the only person who understands the legacy interface are in conflict, and the map is where that conflict gets seen and resolved before both slip.
Labeling the kind matters because each is managed differently. A service dependency is broken by building the replacement feed. A data dependency is managed by sequencing and validating the migration. A resource dependency is managed by the program office reconciling the plan against the people available. A map that records only that a link exists, without saying what kind it is, tells the buyer there is a problem without telling anyone how to solve it.
Once the links are mapped, the critical path is the longest chain of dependent exits, and it sets the earliest date the buyer can be fully off the TSA. Every service on that chain must finish before the next can begin, so any slip on the path slips the whole exit. Services off the path have slack: they can move within a window without changing the end date. The buyer who knows which services have slack and which do not can spend management attention where it actually changes the outcome.
The critical path also reveals where an extension is really being bought. If a single service on the path is going to miss its date, every service behind it waits, and the buyer pays extension fees not just on the late service but on everything held up behind it. Seeing that cascade in advance is what lets the buyer decide whether to add resources to the bottleneck, renegotiate that one service, or accept the extension with open eyes rather than discovering the bill at the deadline.
Tie the critical path to the milestone plan so the two views agree. The milestones that gate a service exit should map directly onto the dependency chain, and the dashboard the committee reads should show progress against the path, not against a flat percentage. When the dependency map, the milestone tracker, and the cost view all tell the same story, the buyer has a program that can be steered rather than merely reported on.
The dangerous dependencies are the ones nobody declared. A reporting feed that quietly pulls from a system scheduled to be retired. A batch job that runs overnight against the seller's environment and is invisible until it fails. These do not appear in the service catalog because the seller never thought to list them, and they surface only when a workstream begins detailed planning and asks where every input actually comes from. The map is the place that question gets asked systematically.
Hunt for hidden links by working backwards from each system the buyer must stand up. For every input that system consumes, ask which TSA service or seller environment provides it today, and whether that source is scheduled to disappear before the input is replaced. The questions are tedious and the answers are often uncomfortable, but a hidden data dependency found in planning is a schedule adjustment, while the same dependency found at cutover is an outage and a dispute.
Record the hidden links the moment they surface and feed any that could threaten a milestone into the risk register. A newly discovered dependency that extends the critical path is a material change to the plan, and the governance committee should hear about it as a decision to be made, not as a footnote. The discipline of capturing every link as it is found is what stops the map drifting from the program it is meant to describe.
A dependency map is only useful while it matches reality, and reality moves. A dependency that looked firm at signing often softens once the team understands the system well enough to break the link cheaply. A link assumed to be one way turns out to run both ways. Review the map at every governance checkpoint, and treat a change to the critical path as an event the committee must register rather than a quiet edit the program office makes alone.
Use the map to test every proposed acceleration. When a workstream proposes to pull a service exit forward, the map answers whether the predecessors will be ready in time and whether any resource conflict is created downstream. An acceleration that ignores the dependencies is not an acceleration, it is a future outage with an earlier date. The map lets the buyer say yes to the changes that hold together and no to the ones that only look faster.
Carry the finished map into the lessons learned record at program close. The dependencies that mattered, the hidden links that were missed, and the sequence that worked are the most transferable knowledge a carve-out produces. Feeding that into the next exit means the following carve-out in the portfolio starts with a dependency map that already reflects how these systems actually connect, which is how a portfolio compounds its operating advantage over time.
It is the exercise of recording which TSA services depend on which others, and which exit milestones cannot start until another finishes. The map turns a flat list of services into a sequence, so the buyer exits in the order the dependencies allow rather than the order the catalog happens to list.
Because exiting a service in the wrong order can strand another service that relied on it. Mapping the dependencies first lets the buyer find the critical path, sequence the exits safely, and avoid paying extension fees on a service held hostage by a predecessor that was never scheduled to finish in time.
Service to service dependencies, where one service feeds another; data dependencies, where a migration must complete before a system can stand alone; and resource dependencies, where the same people or environments are needed by more than one workstream at once. Each type constrains the exit sequence differently.
At every governance review, because dependencies change as the program learns. A dependency that looked firm at signing often softens once the team understands the system, and a hidden dependency surfaces only when a workstream begins detailed planning. A stale map sequences the exit on yesterday's assumptions.
The milestones that sit on the dependency chain, tracked on evidence.
Read the article →Turning a dependency sequence into a step by step cutover plan.
Read the article →Where a newly discovered dependency becomes a tracked risk.
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 →
Fixed-fee proposal in 48 hours. Senior team on day one. 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 →