A third of carve-outs fall short of the value the deal promised, and the warning signs sit in IT
In this op-ed, the CTO of services partner Altimetrik, Murali Thiagarajan, argues that successful private equity carve-outs depend on building operational resilience and independence, not just completing the technical separation
Too many leadership teams treat a private equity carve-out as a technical separation, when in reality it is closer to a resilience test run against a countdown clock. Research from McKinsey shows that a third of carve-outs fail to deliver the value the deal originally promised, which should not surprise anyone who has tried to separate a business unit while keeping the wheels turning.
A legal completion does not indicate operational readiness and a deal can close months before the business is ready to stand on its own. The carved-out company still has a team that needs to log in, a client base that expects service, applications that must run and networks that must carry the load from day one as a standalone entity.
The same research from McKinsey shows new owners are often obliged to establish that standalone company within six to 18 months, and the transitional services agreement (TSA) that buys them time is unforgiving - miss that TSA exit date and fees for the same services can double or triple. This is when the pressure lands on IT.
A TSA buys time without removing complications
The TSA exists to keep the lights on, preserving access to the parent company's systems and services for a defined window while the new business builds its own. That window creates a false sense of security because the clock keeps running, the cost of overrunning is steep and the temporary support hides how much work separation involves.
But the challenge is rarely limited to one system. Carving out a company means standing up new email environments and identities, reissuing laptops and logins, rebuilding office connectivity and networks, migrating or rehoming data centres, establishing service desks and telephony, transferring applications and applying consistent security controls and each of these must work on day one, for all users, without commercial interruption.
Missed exit dates are a common source of cost overrun, so the teams that exit a TSA most cleanly map the work early, while the safety net is still in place, rather than meeting it as the deadline closes in.
Hidden dependencies surface only when teams remove them
Technical separation is the visible part of the problem, but the real risk sits in the operational dependencies beneath it, where systems are tied to users, permissions, workflows, office locations, networks and the business processes that run on top of them.
In one carve-out I worked on, a standalone business of around 2,000 employees had to be separated across several regions under a major US private equity sponsor, with the IT exit due well within the wider TSA window. The work looked like a list of discrete tasks - migrate mailboxes, reimage and redeploy laptops, stand up a new identity directory, rebuild the network. The risk lay in the connections between them - a user account that worked only through a permission inherited from the parent, or an application that quietly called a shared service due to be switched off. Each gap stayed invisible until the team tried to remove the element it depended on.
What leadership teams often underestimate is how a single omission turns into a day-one disruption. Your users are locked out, an application is unavailable, a support route is left unclear, or security controls are applied unevenly across the new estate. Individually, these read as execution details, but together they decide whether the business can operate on the morning it becomes independent.
A carve-out succeeds only if the company can keep operating while its dependencies are being separated, not once they have been.
Day-one continuity is simply the first proof point
Getting through day one is critical, but it only proves the business can stand up and nothing more. The firmer test is whether the standalone company can run efficiently in the weeks and months that follow, without constant manual intervention to hold it together. This calls for resilience, operational visibility, governance and a cost base that behaves predictably rather than compounding unnecessary surprises. A business that exits the parent environment but cannot run cleanly on its own has not finished the task.
This is now more relevant than ever. Deloitte's 2026 M&A Trends Survey reported that 99 per cent of deal-makers have now incorporated AI into the M&A lifecycle at varying levels of maturity, and companies emerging from carve-outs are expected to automate, modernise and adopt AI while they are still building their operational foundation. A technically separate company can still be operationally unprepared and the foundations laid during separation determine whether it can scale afterwards or whether fragmented data, weak governance and brittle operations leave it at a competitive disadvantage.
Design for the standalone business from the start
The strongest carve-outs are designed for the future standalone business rather than copying the parent environment and dealing with the consequences later. That starts with visibility - understand the current estate, map dependencies early, define the target-state operating model before the migration begins, and protect continuity through the transition. Design for predictable cost and build for scale rather than treating TSA exit as the sole measure of success.
Visibility carries through into how the business runs once it stands alone, because a standalone company needs a clear view of its own performance, the governance it controls and a cost base it can forecast. Separations that skip this leave the new business dependent on manual effort and reactive fixes, which is the polar opposite of what a private equity owner is paying for.
The ultimate test is whether the company can scale once it exits the TSA, as a carve-out that survives separation but does not support growth, has solved the wrong problem.