Nobody writes this playbook because every carve-out is different. That is what people say. And it is true in the way that every patient is different, but surgeons still follow protocols.
The patterns in carve-out data separation repeat with remarkable consistency. Legacy ERP systems with shared infrastructure. Commingled customer records across business units. Reporting environments that were never designed to split. Shared reference data that everyone uses and nobody owns. I have seen these same problems across industries and deal sizes for twenty years.
The reason nobody writes the playbook is not that the problems are unique. It is that the problems are messy, deeply technical, and politically uncomfortable. Nobody wants to be the one explaining to the board that a data separation that was scoped at $2M and six months will actually cost $5M and take fourteen months.
So here is the playbook. Five phases. Concrete steps. Common traps that add months and millions to the timeline.
Why carve-out data separation is uniquely hard
Before the phases, it is worth understanding why data separation is the hardest technical problem in any carve-out.
In an acquisition, data flows in one direction. You take the acquired company’s data and integrate it into your environment. The scope is known. The target state is your existing infrastructure.
In a carve-out, data flows in multiple directions simultaneously. Some data belongs to the carved entity. Some belongs to the parent. Some belongs to both. And you need to separate it while both businesses continue to operate.
Add to this the reality of legacy ERP systems. A typical mid-market parent company running SAP or Oracle has spent years configuring the system for an integrated business. Chart of accounts, customer master, vendor master, pricing tables, intercompany eliminations. These were designed to work together. Nobody designed them to come apart.
The carved entity needs to stand on its own. It needs its own financial history, its own customer records, its own operational data, its own reporting. All of this needs to be extracted from a system that was built for integration, not separation.
And it needs to happen on a timeline measured in months, not years, because the transaction has a close date and the buyer has a day-one operating plan.
Phase 1. Data inventory and dependency mapping
This is where most teams underinvest and every subsequent phase pays the price.
Map what belongs to whom
Start with the obvious categories. Financial transactions, customer records, employee data, vendor relationships, intellectual property. For each category, determine which records belong exclusively to the carved entity, which belong exclusively to the parent, and which are shared.
The shared category is where the complexity lives. A customer that buys from both the carved entity and the parent. A vendor that supplies both. An employee who splits time between divisions. A shared service center that processes transactions for the entire company.
For each shared data element, you need a decision. Does it go with the carved entity, stay with the parent, or get copied to both? These decisions cannot be made by the data team alone. They require business stakeholders who understand the operational implications.
Map system dependencies
Beyond the data itself, map how the systems connect. Which modules of the ERP does the carved entity use? What integrations exist between the ERP and other systems (CRM, HRIS, warehouse management, e-commerce)? What reporting tools sit on top of the data?
Draw the dependency graph. Every connection is a thread that needs to be cut, redirected, or replicated. Missing even one dependency will surface as a production failure after separation.
Quantify the data volume
For each data domain, estimate the volume. How many years of financial history? How many customer records? How many transactions per month? These volumes drive decisions about migration approach, timeline, and infrastructure sizing.
A common surprise is historical data volume. A carved entity that represents 30% of current revenue might represent 15% of historical transaction volume because the parent grew through the carved business in earlier years. That asymmetry affects migration timelines.
Typical timeline for Phase 1. Four to six weeks with a dedicated team of three to five people (business analyst, data architect, and business stakeholders from finance, operations, and IT).
Common trap. Treating this as a documentation exercise. The inventory is not a deliverable to be filed away. It is the foundation for every decision that follows. Underinvest here and you will rediscover the gaps under pressure in Phase 3.
Phase 2. Entitlement and access separation
Once you know what data exists and who it belongs to, you need to determine who gets access to what, and when access to shared systems ends.
Define data entitlements
For the carved entity, define what data it is entitled to take. This is a legal and commercial negotiation, not a technical exercise. The purchase agreement should specify data entitlements, but in practice, the language is often vague and the details get resolved during separation.
Key questions. Does the carved entity get a copy of all customer records, or only customers with active relationships? How much financial history transfers? Does the carved entity retain access to shared reporting during the transition? Who owns shared intellectual property embedded in data models and algorithms?
Separate access controls
On day one after close, the carved entity’s employees should have access only to the carved entity’s data. This sounds simple. In a shared ERP environment, it is anything but.
User roles and permissions in systems like SAP are built around organizational hierarchies that assumed the company would remain integrated. Separating permissions without disrupting operations requires careful planning and testing.
The risk of getting this wrong is real. If a carved entity employee retains access to the parent’s financial data after close, you have a confidentiality breach. If a parent employee loses access to data they still need because the permissions change was too aggressive, you have an operational disruption.
Plan the cutover
Define the moment when access to shared systems ends. This is usually tied to the TSA (transitional service agreement) expiration, but the planning starts now. What systems will the carved entity use on its own? What needs to be in place before the cutover? What is the fallback if the cutover fails?
Typical timeline. Two to four weeks, running in parallel with Phase 1 completion.
Common trap. Assuming the purchase agreement resolves all data entitlement questions. It rarely does. Plan for 20 to 30 data entitlement decisions that need to be made during separation, each requiring input from legal, business, and technical stakeholders.
Phase 3. Historical data migration
This is the phase that breaks timelines. Not because it is conceptually hard, but because the volume, complexity, and quality of historical data are almost always underestimated.
Decide how much history to transfer
The carved entity needs financial history for reporting, audit, and regulatory purposes. But how much? Three years is the minimum for most regulatory and financial reporting requirements. Five years is safer. Some industries require seven or more.
The decision is not just about volume. It is about format. Historical data in the parent’s ERP may use chart of accounts structures, cost center hierarchies, or reporting dimensions that will not exist in the carved entity’s standalone environment. The data needs to be transformed, not just copied.
Build the migration pipeline
For each data domain, build a pipeline that extracts from the source, transforms to the target format, and loads into the carved entity’s systems. This is standard ETL work, but the complexity comes from three sources.
Data quality in the source. Historical data in legacy systems is often inconsistent. Definitions changed over time. Codes were reused. Manual adjustments were never systematically documented. Every quality issue in the source system becomes a migration problem.
Cross-entity references. A customer invoice in the parent’s system might reference an intercompany transaction, a shared cost allocation, and a vendor payment that splits between entities. Migrating the invoice without its full context creates orphaned records that break reporting.
Volume and performance. Migrating five years of transactional history for a $200M revenue business means moving hundreds of millions of records. This takes time, infrastructure, and testing that is rarely budgeted adequately.
Validate exhaustively
Every migrated record needs validation. Revenue totals by period need to match between source and target. Customer counts need to reconcile. GL balances need to tie. Any discrepancy needs to be explained and documented because the carved entity’s auditors will ask.
Build automated validation scripts that compare source and target at multiple levels of granularity. Period totals, account balances, record counts, sample-level field comparisons. Run them iteratively as you fix issues and re-migrate.
Typical timeline. Eight to twelve weeks for a mid-market carve-out with moderate complexity.
Common trap. Underestimating shared reference data. Master data tables for customers, vendors, products, and chart of accounts are shared infrastructure in an integrated ERP. Extracting the carved entity’s subset while maintaining referential integrity across all transactional data is painstaking work. Budget twice as long as your initial estimate for this specific sub-task.
Phase 4. Transitional service agreements for data
TSAs are the bridge between close and full separation. For data, the TSA defines what shared services continue, for how long, and at what cost.
Define TSA scope precisely
Vague TSA language creates disputes. “Parent will provide continued access to reporting systems for a reasonable period” is an invitation for conflict. Instead, specify which systems, what level of access, for how many named users, with what SLAs, until what date.
Common data services covered by TSAs include access to shared ERP for transaction processing, shared reporting and BI environments, shared data infrastructure (databases, warehouses, integration platforms), IT support for data-related issues, and shared master data management.
For each service, define the service level, the cost, and the exit criteria. What needs to be true before the carved entity can exit the TSA for that service?
Set realistic durations
TSA durations for data services are consistently underestimated. Six months is the typical initial proposal. Twelve to eighteen months is the typical reality.
The underestimation happens because the TSA duration is set during deal negotiations, when both parties are motivated to appear competent and cooperative. The reality of standing up standalone data infrastructure for a mid-market business while running ongoing operations is more complex and time-consuming than either party expects.
Build the TSA duration based on the Phase 3 migration timeline plus a buffer for the carved entity to validate, test, and stabilize its standalone environment. If migration takes 12 weeks, add 8 to 12 weeks for stabilization. A 6-month TSA for data services is the minimum for a straightforward separation. Plan for 9 to 12 months.
Plan the TSA exit
The TSA exit is a project in itself. Define the criteria for exiting each service. Build a tracker. Assign ownership. Review progress monthly. The most common failure mode is a TSA that expires before the carved entity is ready, creating either a forced cutover with operational risk or an expensive TSA extension negotiation from a weak position.
Typical timeline. TSA negotiation happens during deal execution. TSA management is ongoing from close through full separation.
Common trap. TSA timelines that are optimistic on both sides. The parent wants to stop providing services as quickly as possible. The buyer wants to stop paying for them. Both parties set aggressive timelines that neither can meet. The result is either expensive extensions or premature cutover with operational disruption.
Phase 5. Standalone data infrastructure
The final phase is building the carved entity’s independent data environment. This is where the entity transitions from relying on the parent’s infrastructure to operating its own.
Make the architecture decisions early
The carved entity needs its own ERP (or a configured instance of the parent’s ERP), its own data warehouse or reporting environment, its own integrations with third-party systems, and its own data governance processes.
These decisions need to happen in Phase 1 or Phase 2, not Phase 5. The architecture choices drive the migration target, the TSA duration, and the budget. Deferring them creates a cascade of downstream delays.
The most common decision is whether to implement the same ERP as the parent (faster, lower risk, potentially mismatched to the carved entity’s needs) or to implement a different system (slower, higher risk, potentially better long-term fit). For mid-market carve-outs, I generally recommend the same ERP with a new instance unless there is a compelling reason to change. The goal is to separate cleanly, not to optimize the technology stack during the most complex period of the new company’s existence.
Build and test in parallel with migration
Do not wait for migration to complete before building the standalone environment. Build the target infrastructure in parallel with Phase 3. Use migrated data to test. Iterate.
The testing must cover operational processes, not just data accuracy. Can the finance team close the books on the standalone system? Can operations process orders? Can the reporting team produce the board deck? Test the processes, not just the data.
Plan for day-one operations
On the day the TSA expires and the carved entity cuts over to its own infrastructure, everything needs to work. Transactions need to process. Reports need to run. Integrations need to flow.
Build a day-one checklist that covers every critical process. Test it in a dry run at least two weeks before cutover. Have a rollback plan in case the cutover fails. And have the parent’s cooperation documented in case you need to extend the TSA by even a few days.
Typical timeline. Twelve to twenty weeks, running in parallel with Phases 3 and 4.
Common trap. Ignoring cross-entity reporting dependencies. The carved entity may have been part of consolidated reports, intercompany elimination processes, or shared analytics that the parent still needs after separation. These dependencies often surface late and create urgent work to replicate or replace them. Identify them in Phase 1 and plan for them explicitly.
The real timeline
Every carve-out sponsor asks me the same question. How long does this take?
For a mid-market carve-out with moderate complexity, meaning a shared ERP, 3 to 5 years of history, and a carved entity representing 20 to 40% of the parent’s revenue, the realistic timeline from close to full data independence is 9 to 15 months.
That timeline assumes dedicated resources, clear decision-making authority, and cooperative parties. Remove any of those and add three to six months.
The phases overlap. Assessment starts before close. Migration and infrastructure build run in parallel. TSA management is ongoing. But the total elapsed time from “we need to separate the data” to “we are fully independent” is measured in quarters, not weeks.
Plan accordingly. Budget accordingly. And do not let deal optimism infect the separation timeline.
The bottom line
Carve-out data separation is the hardest technical problem most PE firms will encounter. It is also one of the most consequential. Get it right and the carved entity starts its independent life with clean data, reliable reporting, and a foundation for growth. Get it wrong and the first 18 months of the hold period are consumed by data cleanup instead of value creation.
The playbook is not magic. Inventory the data. Define entitlements. Migrate history. Bridge with TSAs. Build standalone infrastructure. The steps are logical. The difficulty is in the execution, and the execution is difficult because the scope is always larger than expected, the data is always messier than assumed, and the timeline is always tighter than planned.
Start early. Resource generously. And remember that the data separation is not a side project running alongside the transaction. It is the transaction.
For more on post-acquisition data operations, read Post-Acquisition Data Playbook: The First 100 Days. For the integration perspective after add-on acquisitions, see Data Integration After Add-On Acquisitions.
For a weekly brief on PE data operations and transaction readiness, subscribe to Inside the Data Room.