IT TSA Exit Planning in 2026: The Execution Playbook for Carve-Outs That Finish On Time

An IT TSA exit is the process of replacing every technology service the seller agreed to provide after close (email, ERP, network, identity, service desk, data centre, application hosting) with capability the buyer owns and operates. The Transition Services Agreement buys time. It does not buy a plan. And in our experience running large-scale separations, the gap between the TSA that gets signed and the separation programme that actually has to be run is the single most expensive misjudgement in the deal.

This guide is the execution model: how to sequence the exit, how to calculate whether your date is achievable before you commit to it, how each class of service actually behaves under separation, and how to stop stranded costs from quietly eating the value the deal was supposed to create.

What Is an IT TSA Exit, and Why Does It Decide Deal Value?

A Transition Services Agreement is a contract in which the seller continues to run agreed services for the divested business for a defined period after close, typically 6 to 24 months. The IT portion is almost always the largest, the most interdependent, and the last to be planned.

The exit is the moment the divested business stops consuming those services and runs on its own stack.

That moment matters financially for three reasons:

• TSA service fees run until you leave. They are usually priced at cost-plus, and they escalate.
• The seller cannot remove its own cost base until you are gone. Stranded cost sits on the seller’s P&L for every month the exit slips.
• Neither side can pursue its own technology agenda while tethered. The buyer cannot modernise what it does not control. The seller cannot decommission what it is still obliged to provide.

PwC’s analysis of TSA exit acceleration puts the value at roughly 5% to 7% uplift from exiting early, with total deal uplift reaching 8% to 11% when combined with other value levers. That is not a rounding error. On a mid-market carve-out, it is frequently the difference between the deal hitting its model and quietly missing it.

The uncomfortable part: that uplift is available to everyone. Very few capture it, because the exit is treated as an IT task rather than a governed programme with a critical path.

Why Do IT TSA Exits Slip?

We see the same four failure modes, in roughly the same order, on almost every deal.

1. The service inventory is written by lawyers, not by operators

TSA schedules are negotiated under time pressure by people optimising for deal close, not for separation feasibility. The result is a schedule that lists services at the wrong altitude. “IT infrastructure services” appears as a single line when that line contains 40 discrete dependencies with different owners, different vendors, and different lead times.

You cannot exit a service you have not decomposed. The first real inventory usually appears months after signing, and it is always larger than the schedule implied.

2. Nobody owns the exit

The deal team disbands at close. The seller’s IT organisation has no incentive to accelerate, because it is being paid to provide the service. The buyer’s IT organisation is simultaneously trying to stand up a company. Between them sits a set of decisions nobody is empowered to make.

Deloitte’s work on IT TSA acceleration notes that a typical exit involves more than 1,500 interdependent design decisions. Decisions at that volume do not get made by goodwill and a fortnightly steering call. They get made by a governance structure with named decision rights and a clock.

3. The sequence is wrong

Teams start with what is easy, such as collaboration tools, endpoints and the visible wins, and leave identity, ERP, and data separation until the back half. Those are precisely the services that gate everything else. By the time the hard work starts, the dependency chain has no slack left in it.

4. Extensions are cheaper than confrontation

When the date approaches, an extension is the path of least resistance. It requires no difficult conversation and no accountability. It also resets urgency to zero. The pattern is consistent: the first extension is easy, the second is assumed, and the TSA becomes a permanent operating model with a temporary contract wrapped around it.

Exit Velocity: The Calculation Nobody Runs Before Signing

Here is the arithmetic that should be run before the TSA schedule is agreed, and almost never is.

Exit velocity = (number of in-scope services) ÷ (months available minus stabilisation buffer)

Take a carve-out with 180 discrete in-scope IT services, a 12-month TSA, and a sensible 2-month buffer at the end for stabilisation and acceptance. That is 180 ÷ 10 = 18 services fully exited, tested, and accepted every month, starting immediately.

Now compare that to what actually happens. Months one and two go to mobilisation and inventory. Months three and four go to design and vendor procurement. First real exits land in month five. The programme now needs 180 services in six months, or 30 per month, against a demonstrated run rate of perhaps six.

That gap does not close. It is discovered in month seven, escalated in month eight, and resolved with an extension in month nine.

Run this calculation before signing. If the required velocity exceeds what your programme can credibly staff and govern, you have three honest options: negotiate a longer TSA, reduce in-scope services by accelerating pre-close separation, or fund the programme at the level the velocity actually demands. Choosing none of them is also a choice. It is just one you make by default, twelve months later, at a much higher price.

How Should You Sequence an IT TSA Exit?

Sequence by dependency, not by difficulty. Almost every underperforming exit we have seen inverted this.

We structure exits in four waves.

Wave 1: Foundation (Months 0 to 4)

Nothing else can move until these exist. They are prerequisites, not deliverables.

• Identity and access management (directory, SSO, privileged access)
• Network connectivity and segregation from the parent estate
• Security operations, logging, and monitoring
• End-user device management and endpoint protection
• Service desk and ITSM tooling

Identity is the true critical path on most carve-outs. Every application cutover, every data migration, and every user-facing change depends on the target identity platform being live, populated, and governed. Teams that treat identity as a Wave 2 item lose the deal’s timeline in the first quarter without realising it.

Wave 2: Core Business Systems (Months 3 to 9)

• ERP and finance
• HCM and payroll
• CRM and customer-facing platforms
• Core operational and industry-specific applications

These carry the longest lead times, the heaviest data migration, and the hardest cutover constraints. Payroll and financial close cycles will dictate your windows, not your Gantt chart. Wave 2 must start in parallel with Wave 1, not after it. The design and procurement work begins on day one even though cutover cannot.

Wave 3: Infrastructure and Hosting (Months 6 to 14)

• Data centre exit or migration
• Application hosting and cloud tenancy separation
• Backup, disaster recovery, and business continuity
• Integration and middleware layers

This wave is often deferred because it is invisible to the business. It is also where the largest stranded costs and the longest contractual tails live: leases, licences, and support agreements that cannot be exited on short notice.

Wave 4: Residual and Long-Tail (Months 9 to 18)

• Archived data and records retention obligations
• Niche and departmental applications
• Regulatory and audit-trail systems
• Reverse TSAs, where the buyer provides services back to the seller

The long tail is where programmes die slowly. Fifteen unglamorous services with no executive sponsor will hold a TSA open for six months and generate extension fees far beyond their operational significance. Name an owner for the tail on day one and track it with the same rigour as ERP.

How Long Does Each IT Service Take to Exit?

Use these as planning baselines to validate against your actual estate, not as commitments. The variance driver is almost always data complexity and regulatory constraint, not technology.

Service class	Typical planning range	Primary constraint
Email and collaboration	2 to 4 months	Mailbox volume, retention and legal hold
Identity and access management	3 to 6 months	Directory design, application re-integration
Network and connectivity	3 to 6 months	Circuit lead times, site count
End-user computing	2 to 5 months	Device refresh logistics, site geography
Service desk and ITSM	2 to 4 months	Knowledge transfer, staffing model
ERP and finance	9 to 18 months	Data migration, close-cycle windows, testing
HCM and payroll	6 to 12 months	Payroll parallel runs, statutory reporting
CRM and customer platforms	4 to 9 months	Data quality, integration count
Data centre exit	9 to 18 months	Lease terms, migration waves, application coupling
Cloud tenancy separation	4 to 10 months	Tenant architecture, entangled shared services
Backup, DR and continuity	3 to 7 months	Recovery testing and evidence requirements
Security operations	3 to 6 months	Tooling procurement, analyst staffing

Two observations that consistently surprise teams:

ERP is not the longest pole by accident. It is the longest pole because it sits downstream of identity, network, and integration, and upstream of financial close. Its float is borrowed from everything else.

Payroll sets your immovable dates. Statutory reporting and parallel-run requirements mean payroll cutover windows are fixed by the calendar, not negotiable by the programme. Anchor the plan to them.

Stranded Costs: The Seller’s Problem That Starts at Signing

Stranded costs are the expenses the seller continues to carry for a business it no longer owns: shared-services headcount, enterprise licences priced at pre-divestiture volume, facility leases, data centre capacity, and allocated overhead.

The structural trap is timing. TSA revenue partially masks the cost while the agreement runs. The moment the buyer exits, the revenue disappears and the cost does not. A seller who begins cost takeout when the TSA ends is starting the work 12 to 24 months late, and has carried a full year or more of expense against a business that has already gone.

The remedy is unglamorous and effective:

• Size the stranded cost before signing, service by service, with named removal actions and dates.
• Align cost-takeout waves to TSA exit waves, so each exit triggers a pre-planned reduction rather than a new analysis.
• Separate the reducible from the contractually trapped. Headcount and discretionary spend move quickly. Leases, enterprise agreements, and support contracts move on renewal cycles you must plan around, sometimes years out.
• Negotiate licence and vendor terms at signing, when you still have leverage. Volume-based enterprise agreements are far harder to renegotiate after the volume has already left.

Sellers who treat stranded cost as a post-exit clean-up exercise consistently absorb the majority of the deal’s value leakage. Sellers who model it pre-signing treat the TSA as a wind-down schedule rather than a service contract, which is what it actually is.

What Does Day-One Readiness Actually Require?

Day One is not the exit. Day One is the minimum viable operating state that lets the divested business function while the exit runs. Confusing the two produces either a panic-driven over-build before close or a business that cannot invoice on day two.

A credible Day-One IT readiness position requires:

• Legal entity and identity foundations. The new company exists in a directory, users can authenticate, and access is governed.
• Ability to transact. The business can take orders, invoice customers, pay suppliers, and pay employees, even if via TSA.
• Regulatory and security continuity. Compliance obligations do not lapse at close, and the security perimeter is defined and monitored.
• A functioning support path. Users know who to call, and that route resolves issues.
• Clean data segregation boundaries. What the buyer can see, what the seller retains, and what is jointly accessible, documented and enforced.
• A day-one command structure. Named decision-makers, an escalation path, and a cutover control room with defined hypercare exit criteria.

The discipline that separates smooth Day Ones from chaotic ones is not technical. It is the cutover plan and the controls around it: rehearsed, evidence-based, and owned. This is the same programme governance that determines whether any large-scale IT infrastructure modernisation lands, applied under a harder deadline.

TSA Design: Contract Terms That Force the Exit

The TSA is the only lever you hold once the deal closes. Most are drafted to guarantee service continuity, which is necessary but insufficient. The best ones are drafted to make staying expensive and leaving straightforward.

Four provisions do most of the work:

Service-level exit dates, not a single end date. Each service in the schedule carries its own exit date derived from the separation plan. A single cliff-edge date encourages everything to be deferred to the cliff.

Escalating pricing. Fees that step up meaningfully at each extension window convert an easy decision into a governed one. The escalation does not need to be punitive to be effective. It needs to be visible in someone’s budget.

Per-service acceptance criteria. Define in advance what “exited” means for each service: what has been migrated, what has been tested, what evidence is required, and who signs. Without this, exits are disputed at exactly the moment the deadline arrives.

Decision rights and an escalation clock. Name who decides, and specify what happens when they do not decide within a fixed window. With 1,500-plus interdependent decisions in play, an unresolved decision is a schedule risk, and it must escalate automatically rather than by request.

One term that is regularly forgotten: reverse TSAs. In many carve-outs the divested business holds capability the parent still needs. These are rarely scoped with the same rigour, and they hold programmes open long after the primary services have exited.

Programme-Led vs Ad Hoc TSA Exit: What Is the Difference?

Dimension	Ad hoc exit	Programme-led exit
Service inventory	Inherited from the TSA schedule	Decomposed to operational level in the first 30 days
Sequencing	Easiest first	Dependency-driven, wave-based
Ownership	Split between two IT organisations	Single accountable separation lead with mandate over both sides
Decisions	Escalated on request	Named decision rights with an automatic escalation clock
Stranded cost	Addressed after exit	Modelled pre-signing, retired in step with each wave
Extensions	Default response to slippage	Governed exception with a cost owner
Evidence	Assertion that a service has moved	Acceptance testing against pre-agreed criteria
Typical outcome	One to two extensions, cost overrun, value leakage	Exit on or ahead of date, cost base retired on schedule

The distinction is not effort. Both models involve exhausted people working hard. The distinction is whether that effort is applied against a critical path that someone owns.

The Six-Phase IT TSA Exit Playbook

This is the structure we use to run separations end to end.

Phase 1: Diligence and Feasibility (pre-signing). Decompose the technology estate. Build the first credible service inventory. Run the exit velocity calculation. Model stranded cost. Feed all of it into TSA scope, duration, and pricing while there is still leverage to shape them.

Phase 2: Mobilisation (Months 0 to 2). Stand up the separation PMO with decision rights across both organisations. Confirm the service inventory at operational altitude. Assign an owner to every service, including the long tail. Baseline the plan against wave logic and lock the critical path.

Phase 3: Design (Months 1 to 5). Define the target-state architecture for each wave. Procure what needs lead time (circuits, licences, cloud tenancy, security tooling) before the design is fully signed off, because procurement lead time is the constraint that cannot be recovered. Design the identity platform first.

Phase 4: Execution (Months 3 to 14). Run the waves in parallel, not in series. Track exit velocity weekly against the required rate, and treat a shortfall as a schedule breach rather than a status update. Retire the corresponding stranded cost as each service clears.

Phase 5: Acceptance and Exit (rolling). Test against the acceptance criteria written into the TSA. Collect evidence. Obtain sign-off service by service. Formally terminate each service line so fees stop and the seller can act on its cost base.

Phase 6: Stabilisation and Optimisation (Months 12 to 24). Exit hypercare against defined criteria. Close out residual and reverse TSAs. Then, and only then, begin the modernisation the new operating model actually needs. The temptation to modernise during separation is strong and almost always wrong: it adds scope to the one programme in the business that has a contractual deadline.

How TechHarbor Partners Approaches IT M&A Separation

We run separations with senior practitioners who stay through delivery, because the decisions that determine whether a TSA exit lands are made in month seven, not in the diligence deck.

Our IT M&A advisory practice covers the full deal lifecycle:

• Pre-deal technology diligence. A clear-eyed read on the target’s technology, security posture, risk, and true integration cost, including the separation feasibility work that should shape TSA scope and duration before anything is signed.
• Integration and separation planning. A sequenced blueprint for combining or separating two technology estates, decomposed to the operational altitude at which the work is actually executed.
• TSA design and exit. Scope, pricing input, and a credible exit roadmap, governed through to the final service acceptance.
• Day-one readiness. Checklist, cutover plan, and the controls that make a cutover auditable rather than hopeful.
• Post-close execution support. Hands-on delivery of the separation itself, not a plan handed to someone else to run.

That work spans acquisition programmes running several deals a year, multi-region estate consolidations, and separations delivered without interrupting operations through cutover. The pattern that decides these programmes is consistent, and it is the same one that governs any complex, multi-site enterprise transformation: a single accountable owner, a decomposed critical path, decision rights that function under pressure, and senior people who are still in the room when the plan meets reality.

Separation is often harder than integration. There is no option to defer, no gradual convergence, and a counterparty whose interests diverge from yours the moment the ink dries.

Frequently Asked Questions About IT TSA Exits

How long does an IT TSA exit take?

Most IT TSAs run 12 to 24 months, and the exit consumes essentially all of it. Foundation services such as identity, network, end-user computing and service desk typically take three to six months. ERP, payroll, and data centre exits run nine to eighteen months and set the overall duration. The realistic constraint is rarely technology; it is data migration, regulatory testing, and vendor lead times.

What is the difference between a TSA exit and post-merger integration?

Integration combines two technology estates that both continue to exist. A TSA exit separates one estate from another and builds standalone capability where none existed. Integration can be phased and can tolerate a longer convergence. A TSA exit has a contractual deadline, an escalating cost of delay, and a counterparty with no incentive to accelerate.

What are stranded costs in a carve-out, and who carries them?

Stranded costs are expenses the seller continues to incur for a divested business: shared-services headcount, enterprise licences priced at old volume, leases, and allocated overhead. The seller carries them. They should be modelled service by service before signing and retired in step with each TSA exit wave, not addressed after the agreement ends.

Should we extend the TSA if we are behind schedule?

Extend only as a governed exception with a named cost owner and a revised plan that demonstrates the new date is achievable. An extension granted without both of those resets urgency to zero and reliably produces a second extension. Escalating extension pricing, agreed at drafting, is the most effective control against this.

When should IT TSA exit planning start?

Before signing. The service inventory, exit velocity calculation, and stranded cost model should inform TSA scope, duration, and pricing while you still have negotiating leverage. Teams that begin exit planning after close have already committed to a date they have not tested.

Who should own the IT TSA exit programme?

A single accountable separation lead with a mandate that spans both organisations and decision rights written into the TSA. Splitting ownership between the buyer’s and seller’s IT functions is the most common structural cause of slippage, because no one is empowered to resolve the interdependent decisions that dominate the critical path.

What is a reverse TSA?

A reverse TSA is one in which the divested business provides services back to the parent, often where specialised capability, systems, or people moved with the carve-out. They are frequently under-scoped, and because they attract less executive attention, they routinely hold the overall separation open after the primary services have exited.

Close the Gap Between the Deal Model and the Exit Date

Every TSA is written on the assumption that the exit will be managed. Very few deals fund, staff, or govern it as though that were true.

The value is well documented and available to any acquirer disciplined enough to take it: exit early, retire the cost base in step, and release both organisations to pursue their own technology agendas a year sooner than the contract requires. What stands between the model and the outcome is not strategy. It is a decomposed critical path, decision rights that hold under pressure, and senior people who stay until the last service is accepted.

If you are shaping a TSA, running a separation that has started to slip, or carrying stranded costs from a deal that closed last year, book a consultation. Tell us where you are trying to go, and we will tell you honestly what it will take to get there.