Technology Carve-Out Diligence: Can the Business Stand Alone Before the TSA Expires?

The central question in technology carve-out due diligence is whether the acquired business can operate independently before its transition services expire. A system inventory and high-level TSA schedule cannot answer it. The buyer must define the standalone boundary, identify material dependencies on the seller, decide how each dependency will be resolved, and fund a milestone-based separation plan.

Diligence should produce four concrete outputs:

1. A credible Day One operating state.
2. A complete estimate of one-time separation costs.
3. A realistic standalone technology run-rate.
4. A service-level plan for exiting each TSA before expiration.

Without these outputs, the deal team does not have a reliable view of standalone readiness.

Start with the standalone boundary, not the seller's system list

A carve-out can appear to be an operating business while still depending heavily on its parent. Shared identity services, applications, integrations, databases, cybersecurity operations, vendor agreements, infrastructure, reporting processes, and personnel may all sit outside the transaction perimeter.

The first diligence task is to define what the business must control, contract for, or reliably receive to operate independently. Although its guidance concerns antitrust divestiture remedies, the Federal Trade Commission makes a relevant operational point: when parts of an ongoing business are excluded, the parties should explain how the buyer will fill each gap, at what cost, and how quickly. The FTC also says back-office functions, including databases and other IT functions, are often more important and more complicated to transfer than expected. ^[1]

The standalone boundary should address six dimensions:

This is broader than an application register. A 2026 purchase agreement filed on SEC EDGAR defined IT transition scope to include infrastructure, authentication and access services, business applications, cybersecurity, monitoring, backup, data, configurations, interfaces, history, logs, and reports required for business continuity. ^[5] BCG similarly identifies systems, infrastructure, data, intellectual property, contracts, and the people operating them as essential parts of technology carve-out diligence. ^[7]

The practical output is a standalone boundary statement: a concise definition of the services, capabilities, assets, rights, data, and roles that must be under buyer control at TSA exit. That statement becomes the reference point for scope, cost, contract negotiations, and execution.

Give every dependency an explicit disposition

Once the boundary is defined, the buyer needs a dependency ledger. Each row should represent a business service or technology capability, not merely an asset. One application may support several services with different owners, data requirements, and exit dates.

Every material dependency should receive one of five dispositions:

• Transfer: Move the relevant asset, contract, data, configuration, or employee into the carved-out business.
• Replace: Implement a buyer-controlled platform or capability.
• Transition: Receive the service temporarily from the seller under a TSA while preparing the permanent solution.
• Outsource: Contract with a third party for the enduring service.
• Accept: Tolerate a temporary constraint or reduced capability with explicit approval.

For each dependency, record the business owner, technical owner, Day One state, final state, prerequisites, consent requirements, estimated cost, target date, and acceptance evidence.

This exercise exposes what broad labels conceal. An ERP provided under a TSA may depend on seller identity services, interfaces to banks and payroll providers, master-data processes, reporting tools, security monitoring, specialist administrators, and recurring data feeds. Exiting the application service without resolving those dependencies does not produce a functioning standalone capability.

A February 2026 TSA filed on SEC EDGAR expressly recognized service interdependencies and required an exit and migration plan covering responsibilities, migration phases, safeguards against disruption, knowledge transfer, contingencies, employee data extracts, and cutover timing. ^[3] A July 2026 TSA addressed omitted services, third-party consents, data-extraction and transfer costs, and the recipient's obligation to have sufficient resources to perform or replace the services when the transition period ended. ^[4]

The TSA should follow from the dependency analysis. It should not substitute for it.

Separate the four cost categories

Carve-out underwriting often begins with historical corporate allocations. Those figures may provide context, but they are not a standalone technology budget.

A carve-out information statement filed on SEC EDGAR stated that the business could incur costs not included in historical allocations and that actual standalone costs would depend on factors including its organizational structure and technology and infrastructure decisions. ^[6] BCG also notes that allocated technology costs may not represent the expenses required for standalone operations and, in highly integrated environments, may imply much lower future costs than the buyer will incur. ^[7]

The buyer should model four categories separately:

1. Historical allocations: Amounts charged by the parent before separation.
2. One-time separation costs: Migration, implementation, data cleansing, testing, infrastructure, vendor setup, consulting, knowledge transfer, dual running, and decommissioning.
3. TSA charges: Payments to the seller for temporary services, including extension premiums and pass-through costs.
4. Standalone run-rate: Recurring costs after TSA exit, including software, infrastructure, managed services, internal talent, security, support, and governance.

Combining these categories can distort both EBITDA expectations and liquidity requirements. A low historical allocation does not prove that the standalone run-rate will be low. A manageable future run-rate does not mean the separation program is adequately funded.

The model also needs a downside case. In one February 2026 TSA, extension pricing for ERP-related services increased across successive 90-day periods from 105% to 110%, 115%, and 120% of the reference amount. ^[3] The specific economics will vary by agreement. The underwriting implication is to model late exit by service, including extension pricing, duplicate operating costs, additional delivery support, and potential disruption.

Reverse-plan from each service-level TSA expiration date

A TSA should be managed as a portfolio of temporary services with distinct dependencies, durations, costs, and exit conditions, not as one general deadline.

For each service, work backward from its expiration date through the milestones required for a safe exit:

1. Target-state decision: Select the enduring platform, architecture, provider, and operating owner.
2. Commercial readiness: Execute contracts, obtain consents, and secure licenses and implementation capacity.
3. Environment readiness: Configure infrastructure, security, identity, integrations, and support processes.
4. Data readiness: Identify source data, cleanse it, define retention requirements, perform trial migrations, and reconcile results.
5. Operational readiness: Train users and support teams, transfer knowledge, establish monitoring, and rehearse incident procedures.
6. Cutover readiness: Complete integrated testing, contingency planning, rollback preparation, and business-owner approval.
7. Exit acceptance: Verify reconciliation, performance, access, control operation, documentation, and ownership before terminating the service.

This is more useful than a broad post-close workstream called "IT separation." The FTC's retrospective review of merger remedies found that several divestiture buyers needed more transition time than anticipated, particularly when they had to merge or replace information technology systems. ^[2] KPMG's March 2026 separation report maps an end-to-end process that includes pre-Day One readiness, Day One cutover, TSAs, and TSA exits, and explicitly distinguishes Day One from the post-TSA state. ^[8]

Each service also needs objective exit criteria. "Migration complete" is not enough. Better criteria include:

• Required historical and open transactional data have been migrated and reconciled.
• User identities, roles, and privileged access have been tested and approved.
• Critical interfaces have passed end-to-end testing.
• Backup, recovery, monitoring, and incident escalation are operational.
• Business owners have completed acceptance testing.
• Support teams have documentation and demonstrated operational knowledge.
• Cutover and rollback procedures have been rehearsed.
• Seller data access has been removed or reduced as required.
• Residual defects and constraints have named owners and accepted workarounds.

The planned exit date should follow from these conditions. It cannot replace them.

Decide before Day One what cannot wait until Day Two

Not every system must be replaced before closing. Much of the implementation may occur during the TSA period. But delaying foundational decisions consumes the runway needed to execute them.

Before Day One, the buyer should know:

• Which major systems will transfer and which will be replaced.
• Which business processes will change in the standalone model.
• What identity, network, device, security, and support model will apply.
• Which data must move at closing, during transition, or at final exit.
• Which vendor contracts and licenses require assignment, consent, or replacement.
• Which seller employees or contractors hold critical operating knowledge.
• Who has authority to make target-state decisions after closing.
• What funding, internal capacity, and external delivery support are committed.
• Which services require extension rights or contingency plans.

Together, these decisions form the initial separation architecture. They need not settle every implementation detail, but they must support procurement, staffing, sequencing, and cost estimates.

The Private Capital Technology Decision Playbook provides a broader model for structuring technology decisions under investment and execution constraints. In a carve-out, each decision must also be tied to a seller dependency and a fixed transition runway.

Translate technical findings into deal decisions

A useful diligence report does not stop at observations such as "systems are shared" or "data migration may be complex." It explains what each finding changes commercially.

A material dependency may affect:

• Valuation: Higher standalone costs or delayed benefits can change the earnings profile and value-creation case.
• Purchase-agreement terms: Assets, data rights, cooperation obligations, personnel access, documentation, consents, and migration support may need explicit treatment.
• TSA scope: Omitted services, service levels, change procedures, data extracts, security responsibilities, and termination mechanics may need clarification.
• Extension rights: Services with high migration or consent risk may require predefined extensions and known pricing.
• Closing requirements: Certain access, transfers, staffing commitments, or continuity measures may be necessary for Day One.
• Post-close funding: The separation program needs a funded budget, not an unfunded list of recommendations.
• Governance: Decisions, risks, and acceptance criteria need named executive owners.

Cybersecurity findings may require separate treatment because separation changes identities, networks, access paths, monitoring, and accountability. EES's guide to cybersecurity due diligence for private equity explains how to connect those findings to transaction protections and funded remediation.

Carve-out separation also differs from post-acquisition standardization. In a buy-and-build program, the question is often what to integrate and what to keep local. In a carve-out, the immediate objective is to end dependence on the seller without interrupting the business. The sequencing and risk profile differ, even if the eventual target state includes integration with another company. See Buy-and-Build Technology Integration: What to Standardize and Keep Local for the integration decision.

The standalone-readiness test

Before approving the separation plan, the deal and operating teams should be able to answer yes to these questions:

• Is the required standalone operating boundary documented and agreed?
• Does every material business service have mapped applications, data, infrastructure, contracts, interfaces, security controls, and operating personnel?
• Does every seller dependency have an explicit disposition?
• Are the Day One and post-TSA states defined separately?
• Are historical allocations, separation costs, TSA charges, and standalone run-rate modeled separately?
• Is there a service-level plan reverse-engineered from every TSA expiration date?
• Are critical vendor consents, data rights, licenses, and knowledge dependencies identified?
• Does each TSA exit have measurable technical and business acceptance criteria?
• Are architecture, vendor, talent, data, and governance decisions assigned to accountable owners?
• Has the downside case for late exit been quantified and funded?
• Have material findings been translated into valuation, agreement, TSA, closing, or post-close actions?

A "no" does not necessarily mean the buyer should walk away. It means the uncertainty must be priced, protected, resolved, or consciously accepted.

The diligence deliverable is an executable separation plan

Technology carve-out diligence should leave the buyer with more than a risk register. It should establish what the business needs to operate independently, how each seller dependency will end, what the transition will cost, and who must deliver each milestone.

The work therefore sits between diligence and execution. The team assessing the environment needs to understand architecture, contracts, data, operating processes, talent, cost, and delivery sequencing. Its findings must then survive the handoff from the deal team to management and from signing through TSA exit.

A technology operating partner can connect those stages. Whatever the delivery model, the standard is the same: every material dependency needs a disposition, owner, budget, deadline, and test of completion. Until those are in place, the business is not ready to stand alone.