Carve-Out Day-1 Tech Playbook: From Signing to Standalone in 90 Days

Tech separation determines whether a carve-out hits its alignment targets or stalls under TSA dependency. The 90-day path that works.

Carve-outs are an underrated test of an enterprise's technology operating model. The deal team negotiates the alignment; the technology team determines whether they are achieved or evaporate under transition service agreement (TSA) extensions. The first ninety days set the trajectory. In our work across separations in financial services, industrials, and software, the outcomes cluster bimodally: programs that finish IT separation within twelve to eighteen months at or below TSA budget, and programs that grind on for thirty-plus months with TSA cost overruns of 40% or more. Little middle ground exists, and the divergence is almost always traceable to decisions made before day 90.

The macro picture matters too. Bain's 2023 M&A report notes that divestitures generate higher shareholder returns than acquisitions on average, but only when execution is clean. Technology separation is the largest single execution risk in that equation. Deloitte has estimated that IT typically accounts for 30-40% of one-time separation costs in a carve-out, and TSA exit slippage is the single largest driver of cost overrun.

What goes wrong in carve-outs

Three patterns derail carve-outs more reliably than any others. The first is underscoping the application footprint: the divestiture's IT inventory was last accurate at signing minus six months, and entire shadow systems surface in the first week of separation planning. We routinely find that the actual application count is 25-50% higher than the inventory provided in the data room, with the gap concentrated in SaaS tools procured at department level and in integrations between systems that were never formally cataloged.

The second is overcommitting on TSA exit timelines: pressure to look decisive at signing produces TSA durations that turn out to be infeasible, and the inevitable extensions destroy alignment realization. TSA extension fees are typically priced at 105-150% of the base service rate for the first extension and escalate from there, by design, to incentivize exit. When the engineering work to exit was underscoped, the buyer pays the penalty for months.

The third is treating the carve-out as a project rather than as a product launch: the moment of separation is the start of operating standalone, not the end of the program. The standalone entity needs a service desk, an incident response capability, vendor management, security operations, and finance systems that work on day one with no parent backstop. Programs that under-invest in standalone operating capability spend the first six months post-separation in firefighting mode and lose the leadership credibility needed to deliver alignment.

A counter-take worth stating plainly: the conventional advice that buyers should "minimize TSA scope to accelerate independence" is wrong more often than it is right. Aggressive TSA minimization at signing forces the standalone entity to build or buy capability under time pressure, at premium prices, with incomplete requirements. We have seen carve-outs that deliberately negotiated longer, broader TSAs, twelve to eighteen months instead of six, and used the runway to make sound architecture choices. They typically end up with lower total cost of separation and a better target-state estate. The right question is not "how short can the TSA be" but "how long do we need to make defensible standalone choices, and what is that runway worth."

Days 0 to 30: discovery and decision-making

The first month is dominated by inventory and decision-architecture. Three artifacts must exist by day 30:

• An application disposition map. Every system the carve-out depends on, classified as: replicate (build a standalone instance), replace (move to a new vendor or build), retire (shut down at separation), or retain on TSA (use the parent's instance for a defined window). For a mid-sized carve-out this is typically 200-600 applications; for large industrial separations it can exceed 1,500.
• A data dependency map. What data flows in, what flows out, what is shared, what is licensed. Data separation is almost always more complex than application separation and surfaces late if not modeled early. Master data, customer records that exist in both entities post-separation, and historical transaction data subject to retention regulations each require distinct treatment.
• A TSA-by-system schedule. Realistic exit dates, dependency-aware, with named owners on both sides. The temptation to negotiate aggressive durations should be resisted; missed TSA exits are far more damaging than longer ones agreed upfront.

Discovery in this window is not a passive intake exercise. It requires interviewing application owners, pulling SSO logs to find systems nobody admits to using, reviewing accounts payable for unrecognized SaaS vendors, and reconciling against the CMDB. Expect the CMDB to be 60-80% accurate at best.

Days 30 to 60: build and contract

The second month is execution-heavy. Replicate-track systems are stood up in the standalone tenant; replace-track systems are contracted with new vendors and integration scoped; retire-track systems are confirmed and communicated.

Identity is the system that gets the most complexity wrong. Underestimating Microsoft Entra ID (formerly Azure AD) or Okta separation timelines is the single most common cause of TSA extension. Microsoft's own tenant-to-tenant migration guidance describes a multi-phase process spanning user, mailbox, OneDrive, Teams, and SharePoint cutovers, with cross-tenant collaboration patterns required during the transition. Plan identity as a three-month workstream even if the deal team thinks it is a three-week one. Where the carve-out involves more than 5,000 users or significant Teams/SharePoint estate, four to six months is more realistic.

Cloud account separation is the second underestimated workstream. AWS Organizations and Azure subscription splits are not technically difficult in isolation, but the network architecture, IAM policy refactoring, and shared service untangling almost always extend the timeline. AWS's account migration guidance is worth reading early, even if the team has done it before. Reserved instance and savings plan ownership, who keeps which commitments, is a contractual issue that needs to be settled in this window, not at cutover.

Vendor contract novation is the workstream that consumes the most calendar time and produces the least visible progress. Every material software contract needs to be reviewed for assignment clauses, change-of-control provisions, and pricing implications of splitting one enterprise license across two entities. Some vendors will use the moment to reprice aggressively; budget a 15-30% software cost increase across the standalone estate as a planning assumption, and negotiate from there.

Days 60 to 90: cutover rehearsals

The final month is where the program either crystallizes or unravels. Cutover rehearsals, full mock separations of the most critical systems with rollback, expose the integration assumptions that were made in months one and two. Three rehearsals are not too many for ERP, CRM, identity, and financial close systems. Each one will surface dependencies that nobody documented.

The rehearsal cadence we recommend is: a tabletop walkthrough at week nine, a technical dry-run with non-production data at week eleven, and a production rehearsal in a window matched to the planned cutover at week thirteen. Each rehearsal produces a defect list with named owners and a re-test date. Programs that skip rehearsals because "we ran out of time" are programs that will run out of time again on the actual cutover, except with revenue at stake.

Communications planning belongs in this window too. Customers, partners, and regulators need to know what is changing, when, and what action is required of them. EDI partner cutovers, payment processor recertifications, and SOC 2 / ISO 27001 scope changes for the standalone entity all have lead times measured in weeks, not days.

The TSA discipline that pays

The most important TSA principle is that every service has an exit date with a named exit owner on the carve-out side, and that exit date is reviewed weekly. TSAs that are reviewed monthly drift; TSAs that are reviewed quarterly extend. The cost of the extension typically exceeds the cost of the engineering work that would have prevented it, by a wide margin, often 3-5x by the time premium pricing, opportunity cost, and management distraction are accounted for.

The governance structure that works is a weekly TSA exit council with the seller's TSA lead, the buyer's separation lead, and decision authority to approve scope changes without escalation. The council reviews the exit schedule, flags slipping items at least four weeks before the scheduled exit, and approves extensions only with a documented root cause and a new committed date. Extensions agreed without root cause analysis tend to recur.

A second discipline that pays: meter the TSA. Both parties should have visibility into actual consumption of TSA services, not just the contractual scope. We have seen sellers continue to provision capacity for services the buyer stopped using months earlier, and buyers continue to pay for them, simply because nobody was watching the meter.

Where consultants add value, and where they don't

External advisors are most useful in three places: discovery (the inventory the internal team cannot do at the speed required), TSA negotiation (the experience pattern is rare inside any one company), and cutover orchestration (the playbooks travel well). They are least useful in execution of the carve-out's standalone systems; that work belongs to the team that will run them afterward.

A specific anti-pattern: large advisory firms staffing the build phase with generalists who rotate off before stabilization. The standalone team inherits systems they did not configure, with documentation written for billing purposes rather than operations. Where advisors do execute build work, the contract should require named individuals to remain through a defined hypercare window, typically 60-90 days post-cutover, with knowledge transfer artifacts that the receiving team has signed off on.

What success looks like at day 90

A carve-out on track at day 90 has: a disposition decision for every system, a stood-up tenant for replicate-track systems with at least one production workload running, signed contracts for replace-track systems with integration in flight, retire-track systems confirmed, and a TSA exit schedule that both parties' executives have signed in writing.

Quantitatively, the leading indicators we track at day 90 are: percentage of applications with a confirmed disposition (target: 100%), percentage of TSA services with a named exit owner on the buyer side (target: 100%), percentage of identity migration milestones met to date (target: at least 90%), and number of unresolved data separation issues classified as high severity (target: declining week over week).

Programs that hit those marks separate cleanly. Programs that miss them spend the next year explaining why TSAs are extending.

The bottom line

Carve-outs reward early honesty. The teams that separate cleanly are the ones that scoped the work realistically in the first ninety days, even when the deal team wanted faster numbers. Coordination targets are won or lost in that window, not at cutover and not in the year of stabilization that follows. The discipline is unglamorous: inventory, disposition, TSA scheduling, rehearsals, weekly governance. None of it is novel. All of it is hard to do under deal-clock pressure. The firms that treat the 90-day window as the most important phase of the entire program are the firms that hit their numbers.