The34group

Guide · Carve-outs

Carve-out IT separation, and the TSA exit.

In most carve-outs the IT clock sets the whole timeline, and the transition service agreement is where the value quietly leaks away. Here is the operator's guide: what to replace on day one, what to run on the TSA, what to build after, and why exiting early is a deal objective, not housekeeping.

Written by the team · Updated June 2026 · 7 min read


01 · The carve-out, in numbers
~40%
of carve-outs fail to meet performance expectations, most often from poor planning for the transition period.
McKinsey
~12mo
is the typical IT and infrastructure TSA, the longest workstream in the deal, stretching past 15 in complex separations.
PwC
8-11%
deal value uplift has been achieved by exiting TSAs early, much of it from a year of business value captured sooner.
PwC

The IT clock sets the whole timeline.

A carve-out has many workstreams, but one of them paces all the others. IT and infrastructure is the longest TSA, around twelve months on average and past fifteen in complex deals, and almost every other function depends on systems IT controls. So the date you can get off the seller's systems is, in practice, the date the separation finishes.

That is also why so many carve-outs disappoint. About 40% fail to meet performance expectations, most often from poor planning for the transition period, and roughly a third never create the value first ascribed to them. The fix is not more diligence. It is treating IT separation and the TSA exit as the spine of the plan, from day one.

« The day you get off the seller's systems is the day the carve-out is actually finished. »


02 · Why IT runs longest

Why IT runs longest, and gates the rest.

01

Everything else waits on the systems

Finance closes the books in an ERP. Sales runs on a CRM. The warehouse runs on a WMS. Until those are separated, no other function is truly standalone, so IT does not just take the longest, it gates the rest of the carve-out.

02

The estate is entangled, not modular

The seller built its IT for one company, not two. Shared applications, shared identity, shared network and a data centre that holds both businesses do not split on a clean line. Untangling them is the work, and it is rarely as scoped as the deal model assumed.

03

The TSA is a meter, not a safety net

Every month on the seller's systems is a month of TSA fees, a markup, and a business you do not yet control. The TSA keeps the lights on, but it bills for the privilege and it caps how fast you can integrate or change anything.

04

Stranded costs sit on both sides

The seller is left with IT costs tied to a business it no longer owns and cannot easily shed until you exit. That pressure, plus your own fees, is why a drifting IT timeline quietly erodes the value the deal was supposed to create.


03 · The sequence

The TSA-exit sequence.

Five moves, in order, from close to clean exit. Each one ends with a TSA service switched off.

STEP 01 / 05

Map the estate and set the exit date first

Before anything moves, inventory what the carved-out business actually runs on: applications, data, identity, infrastructure, and every dependency on the seller. Then fix the target TSA exit date and work backwards from it. The IT clock is the long pole, so the date you set here is, in practice, the date the whole separation finishes. Set it deliberately, not by default.

STEP 02 / 05

Stand up the foundations for day one

On the day the deal closes the business has to keep operating, so the non-negotiable layer comes first: identity and email, network and security, the devices people work on, and the finance systems that have to close a month. This is the minimum that lets the company run as itself from hour one, even while heavier systems still sit on the TSA behind it.

STEP 03 / 05

Migrate the heavy systems off the TSA in waves

ERP, the data warehouse, and the core line-of-business applications come off the seller in sequenced waves, not one big-bang cutover that risks the whole business at once. Sequence by dependency and by risk, migrate and reconcile the data as you go, and never schedule a core cutover into a peak trading window. Each wave that lands is a TSA service you can switch off.

STEP 04 / 05

Exit each TSA service the moment its replacement holds

Treat the TSA as a list to burn down, not a comfort blanket to keep. As each replacement proves itself in production, formally exit that service so the fees and the markup stop and the dependency on the seller is gone. Exiting early, sometimes in half the agreed term, is where a large share of the value uplift comes from, so it is a deal objective, not an afterthought.

STEP 05 / 05

Decommission, settle stranded costs, and hand over

Once a service is off the TSA, shut down the old access, close out the data, and work with the seller to retire the stranded costs left behind. Then hand the new estate to the team that will run it, with the documentation, the alerts and the ownership. A separation is done when the business runs on its own systems and nobody is still paying the seller to keep a light on.


04 · Replace, run, or build

Replace day one, run on the TSA, or build after.

Every system in the estate falls into one of three buckets. Sorting them early is what keeps the business trading on day one without dragging the whole stack into a single risky cutover. Read the buckets in time order, soonest first.

Replace day one

Build it before, or at, close

Non-negotiable, before close

Anything the business cannot trade without, anything cheap and fast to stand up clean, and anything you would never want to inherit from the seller.

Typically
  • Identity, email and collaboration
  • Network, endpoints and security
  • Finance and payroll able to close a month
Run on the TSA

Rent it, briefly, then exit

Temporary, exit fast

Heavy, entangled systems that are too risky to cut over on day one. The TSA buys time to do it properly. The point is to exit fast, not to settle in.

Typically
  • ERP and the core finance backbone
  • The data warehouse and reporting
  • Deeply shared line-of-business apps
Build after

Defer until the business is stable

Deferred, not separation

The improvements that are not separation. Real upgrades, consolidation and new capability that can wait until the company is standalone and steady.

Typically
  • Platform modernisation and consolidation
  • New analytics and AI capability
  • Process redesign on the new stack

The honest trap is the third bucket leaking into the first two. Modernisation feels urgent under deal pressure, but a carve-out is hard enough without rebuilding the platform at the same time. Separate first, improve once the business is standalone and stable. Some deals go further and replace day one rather than take an IT TSA at all, which is the right call when the estate is small or clean enough to stand up fresh.


05 · Why early exit pays

Exit the TSA early to unlock the value.

The TSA keeps the business running, but it is a meter, not a safety net. Every month on the seller's systems is a fee plus a markup, a cap on how fast you can integrate, and stranded costs sitting on the seller's side. The instinct to keep the TSA as a comfort blanket is exactly what lets the value leak.

The numbers back the urgency. PwC has measured an 8 to 11 percent deal value uplift from exiting TSAs early, with around 5 to 7 of those points coming simply from capturing a year of business value sooner, and the rest from dropped markup and synergies that only become reachable once you are off the seller. Some acquirers exit in half the agreed term.

So we plan the separation as a burn-down of TSA services with a real exit date attached, not an open-ended dependency. This is also where a focused, embedded team earns its place: a defined, time-boxed job with a clean end. See how we work in how we work.

« Keep the TSA as a comfort blanket and you pay for the privilege of leaking the value the deal was meant to create. »



06 · Frequently asked

Frequently asked.

Why does IT set the timeline for the whole carve-out?

Because every other function depends on systems IT controls. Finance closes in an ERP, sales runs on a CRM, the warehouse on a WMS, so none of them is standalone until IT is separated. IT and infrastructure is also the longest TSA workstream, around twelve months on average and longer in complex deals, which is why it gates the rest.

The practical consequence is that the IT exit date is, in effect, the separation finish date. Set it first and deliberately, then build the rest of the plan backwards from it.

What should we replace on day one versus run on the TSA?

Replace anything the business cannot trade without and anything cheap to stand up clean: identity, email, network, security, devices, and finance able to close a month. Stand that up before or at close so the company runs as itself from hour one.

Run the heavy, entangled systems on the TSA, ERP, the data warehouse, deeply shared applications, where a day-one cutover would put the whole business at risk. The TSA buys time to migrate them properly. The discipline is to treat it as temporary and exit each service as soon as its replacement holds.

Why exit the TSA early if it is already paying for continuity?

Because every month on the seller's systems costs a fee and a markup, caps how fast you can integrate, and leaves stranded costs on the seller's side. PwC has measured an 8 to 11 percent deal value uplift from exiting TSAs early, much of it simply from capturing a year of business value sooner.

So an early exit is a value lever, not housekeeping. We plan the separation as a burn-down of TSA services, and an aggressive but safe exit date is one of the deal's objectives from the start.

Big-bang cutover or phased migration?

Phased, in almost every case. A single big-bang cutover of ERP and the core systems puts the entire business at risk on one date, and a slip lands in the worst possible week. We sequence the heavy systems into waves by dependency and risk, migrate and reconcile data as we go, and never cut a core system over into a peak trading period.

Day-one foundations are the exception: identity, network and the basics have to be live at close. Everything heavier comes off the TSA in controlled waves behind them.

Can we run a carve-out IT separation with our own team?

Often, yes, and a defined, time-boxed separation is exactly the kind of work a focused team can own. Bring us in when the IT clock is setting a timeline you cannot afford, when the estate is more entangled than diligence assumed, or when you want to exit the TSA early and need operators who have done it before.

We build the separation, run it through to TSA exit, and hand the new estate to your team to run. The aim is a business standalone on its own systems, not a dependency on us.


A capable team can run much of this. Bring us in when the IT clock is setting a timeline you cannot afford, when the estate is more entangled than diligence assumed, or when you want to exit the TSA early and need operators who have separated systems before. We build the separation, run it to a clean TSA exit, and hand the new estate to your team to own.

A TSA clock you need to beat?

No deck, no gate. A working session on the real estate and the real exit date, with the operators who would run the separation.

Start a conversation office@the34group.com