The Carve-Out IT Separation Playbook: Sequencing the Work That Actually Frees You

IT separation is where carve-out value is realized or quietly lost. The workstream order, not the cutover date, decides which one you get.

Almost every divestiture closes with a signed transition service agreement and a confident separation timeline. Few of those timelines survive contact with the application estate. In our separation work across financial services, industrials, and software, the programs that exit their transition service agreements on schedule share one trait, and it is not budget or headcount. They sequenced the IT work correctly before the first system moved. The ones that slip almost always started executing in the wrong order, stood up systems nobody could decommission, and discovered the real dependency graph three months too late.

The separation is not a single event. It is a chain of dependent workstreams where identity gates application migration, application migration gates data separation, and data separation gates TSA exit. Get the chain order wrong and every downstream date moves. Deloitte's divestiture research finds that separation programs routinely underestimate IT complexity more than any other function, and that IT is the workstream most likely to force a TSA extension. That extension is where the carve-out thesis erodes.

What most separation plans get backwards

The common failure is treating IT separation as a portfolio of parallel projects. The slide shows identity, network, applications, data, and end-user compute as five swim lanes running side by side toward a shared cutover date. It looks efficient. It is wrong. These workstreams are not parallel; they are a directed graph with hard precedence, and pretending otherwise produces a plan that cannot be executed in the stated time.

Identity is the root of that graph. Until users, groups, and service principals exist in the standalone tenant, no application can be cut over, because the application has nobody to authenticate. Microsoft's tenant-to-tenant migration guidance lays out a multi-phase cutover spanning accounts, mailboxes, OneDrive, Teams, and SharePoint, with cross-tenant collaboration required throughout the transition. Teams that schedule identity as a three-week task and applications as a parallel three-month task have already missed their date. They just do not know it yet.

The second mistake is scoping from the data room inventory. That inventory was accurate at signing minus six months, and it counts what procurement bought, not what the business runs. We routinely find the live application footprint is 25 to 50% larger than the documented one, with the gap concentrated in department-procured software-as-a-service and in undocumented integrations between systems. You cannot separate what you have not found, and you find it by reading single sign-on logs and accounts-payable records, not by trusting the spreadsheet.

The dependency chain that sets your real timeline

A defensible separation plan is built backward from TSA exit, not forward from signing. Each service on the TSA has an exit date, and that exit date is only credible if every upstream dependency clears first. Here is the order that holds up:

• Identity and directory first. The standalone tenant, the directory, federation, and privileged access must exist before anything authenticates against them. For estates above 5,000 users or with a heavy Teams and SharePoint presence, treat this as a four to six month workstream, not a sprint.
• Network and connectivity second. Standalone landing zones, transit routing, and the temporary cross-entity links that let TSA services keep flowing. Cloud account splits in AWS Organizations or Azure look simple and then stall on IAM policy refactoring and shared-service untangling.
• Applications third, in disposition tiers. Replicate, replace, retire, or retain on TSA. Sequence by dependency depth, not by business priority. The system everyone wants moved first is often the one with the most upstream dependencies.
• Data separation fourth, and continuously. Master data, shared customer records, and retention-bound historical data each need distinct handling. Data separation surfaces late and runs long.
• End-user compute and decommissioning last. Devices, collaboration, and the formal shutdown of retained services close the chain and stop the TSA meter.

Skip a layer or run them truly in parallel and the rework cost shows up at cutover, which is the most expensive place to discover it.

A counter-take on TSA scope

Conventional separation advice says minimize the TSA to accelerate independence. We disagree, and the disagreement is not academic. Aggressive TSA minimization forces the standalone entity to build or buy capability under deal-clock pressure, at premium prices, with requirements that are still half-formed. The result is usually a worse target estate and a higher total cost of separation.

The counter-take we offer is that the right TSA is longer and narrower than the deal team wants, not shorter and broader. Buy enough runway to make defensible architecture choices, and scope each service tightly so the meter only runs on what you genuinely depend on. We have seen carve-outs deliberately negotiate twelve to eighteen month TSAs instead of six, then use the runway to land sound identity and data decisions. They finished with lower total cost and a cleaner estate than peers who raced to a six-month exit and paid extension penalties anyway. The first TSA extension is typically priced at 105 to 150% of the base rate and climbs from there by design. Paying that penalty because you underscoped the engineering work is the most avoidable cost in the entire program.

The question is not how short the TSA can be. It is how long you need to make choices you will not regret, and what that runway is worth against the penalty for guessing wrong.

The stranded cost nobody budgets

Separation budgets account for migration. They rarely account for what the seller keeps paying. When the carve-out exits a shared platform, the seller is often left with a license, a support contract, or a reserved-capacity commitment sized for two entities and now used by one. Those stranded costs do not disappear at cutover. They sit on the seller's books until the next renewal, and in our experience they run 10 to 20% of the original shared spend for the year following separation.

Vendor contract novation is where this concentrates. Every material software contract needs review for assignment clauses, change-of-control provisions, and the pricing impact of splitting one enterprise agreement across two companies. Some vendors treat the separation as a repricing event. Budget a 15 to 30% software cost increase across the standalone estate as a planning assumption and negotiate down from there. The teams that model stranded cost and novation pricing early are the ones whose business case still holds at the one-year mark.

Rehearse the cutover, then rehearse it again

A cutover plan that has never been rehearsed is a hypothesis. The rehearsal is what converts it into a schedule you can defend. Three rehearsals are not excessive for the systems that carry revenue: enterprise resource planning, customer relationship management, identity, and financial close. Each rehearsal exposes a dependency that nobody documented, and each one produces a defect list with named owners and a retest date.

The cadence we use is a tabletop walkthrough first, a technical dry run on non-production data next, and a full production rehearsal in a window that matches the real cutover. Programs that skip rehearsals because they ran out of time are the same programs that run out of time on the live event, except then revenue is on the line and rollback is real. Communications planning belongs here too. Electronic data interchange partners, payment processors, and the auditors who own SOC 2 and ISO 27001 scope changes all have lead times measured in weeks.

Governance that keeps the meter honest

The discipline that separates clean exits from grinding ones is unglamorous: a weekly TSA exit council with authority to approve scope changes without escalation. The council reviews the exit schedule, flags any service slipping at least four weeks before its scheduled exit, and approves extensions only with a documented root cause and a new committed date. TSAs reviewed monthly drift. TSAs reviewed quarterly extend. Reviewed weekly, they exit.

Meter the TSA as well as schedule it. Both parties should see actual consumption, not just contracted scope. We have watched sellers keep provisioning services the buyer abandoned months earlier, and buyers keep paying, because nobody was watching the meter. The cost of a missed exit usually exceeds the cost of the engineering work that would have prevented it by 3 to 5x once premium pricing, opportunity cost, and management distraction are counted. That ratio is the entire argument for spending on sequencing discipline up front.

Where outside advisors help, and where they do not

External advisors earn their fee in three places: discovery at a speed the internal team cannot match, TSA negotiation where the pattern is rare inside any single company, and cutover orchestration where the playbooks travel. They are least useful executing the standalone systems themselves. That work belongs to the team that will operate it afterward, because the people who configure a system should be the people who run it.

The anti-pattern to refuse is the build phase staffed with generalists who rotate off before stabilization, leaving the standalone team to inherit systems they never configured with documentation written for billing rather than operations. Where advisors do execute build work, require named individuals through a hypercare window of 60 to 90 days after cutover, with knowledge-transfer artifacts the receiving team has signed off.

Start the program here

The separation programs that hit their numbers all did the same unfashionable things early. If you are scoping one now, start with these moves:

1. Build the dependency graph before the project plan. Map which workstreams gate which, and sequence identity and network ahead of everything that authenticates or routes through them.
2. Rediscover the estate from single sign-on logs and accounts payable, and assume the live footprint is 25 to 50% larger than the data room said.
3. Negotiate the TSA for runway and tight scope, not for the shortest headline duration, and price the first extension into the business case so nobody is surprised by it.
4. Model stranded cost and vendor novation pricing now, while you still have leverage, not at the renewal after cutover.
5. Stand up a weekly exit council with real decision authority and a metered view of consumption, and rehearse every revenue-carrying cutover three times before the live one.

None of this is novel. All of it is hard under deal-clock pressure. The firms that treat IT separation as a sequenced engineering program, not a portfolio of parallel projects racing to a date, are the firms whose carve-outs deliver the value the deal promised.