If you are reading this, you have a carve-out signed or close to signing, and someone has told you the data separation will cost more and take longer than the deal model assumed. They are right. The question now is what you are actually buying, what it should cost, and who should own it.
This is the commercial sibling to the carve-out data separation playbook, which covers the how. This post is for the person evaluating the work. The deal partner sizing the budget. The operating partner deciding whether to build a team or hire a provider. The CFO of the carved entity who is about to own the outcome.
I will keep it honest. Data separation is the hardest technical problem in most carve-outs, and the market for “data carve-out services” is full of vague scopes and optimistic numbers. Here is how to read it.
What data separation scope actually includes
When a provider quotes “data separation,” ask them to name the work. The real scope is five distinct bodies of work, and a quote that does not address all five is a quote that will grow.
Inventory and dependency mapping. Cataloguing what data exists, who it belongs to, and how the systems connect. This is the cheapest phase and the one most often skipped, which is why so many separations blow their budget later.
Entitlement and access separation. Deciding what the carved entity is legally entitled to take, and cutting access cleanly on day one so the parent’s data does not walk out the door and the carved entity’s people are not locked out of what they need.
Historical data migration. Extracting years of financial and operational history from a system built for an integrated business, transforming it to a standalone format, and validating every record so the auditors are satisfied. This is the phase that breaks timelines.
Transitional service agreement support. The bridge between close and full independence. Defining what shared services continue, for how long, and at what cost, then managing the exit.
Standalone infrastructure. Standing up the carved entity’s own ERP instance, reporting environment, and integrations so it can operate without the parent.
A clean engagement names all five and tells you which it owns and which it assumes someone else owns. When the lines are blurry, the cost overruns live in the gaps.
What it actually costs
I will give you ranges from experience rather than invent precise figures, because the honest answer is that the number depends on a handful of drivers more than on any provider’s day rate.
For a mid-market carve-out with moderate complexity, meaning a shared ERP, three to five years of history, and a carved entity representing 20 to 40 percent of the parent’s revenue, I typically see total data separation cost land somewhere in the low seven figures, with the timeline running nine to fifteen months from close to full independence. The figure most deal models start with is roughly half that and six months. That gap is the single most common source of friction I get called into.
The drivers that move the number are predictable.
What pushes it up. A single shared ERP with deeply commingled master data. More years of history, or regulated history that has to be migrated rather than archived. A carved entity that was never run as a standalone profit centre, so its numbers have to be reconstructed. Multiple geographies with different systems. A short TSA window that forces parallel work and overtime. And weak entitlement language in the purchase agreement, which turns every shared data element into a negotiation.
What pulls it down. Clean separation of business units already reflected in the system. A decision to take the same ERP as the parent in a new instance rather than re-platform during separation, which is almost always the right call. A realistic TSA that gives you room to migrate and stabilise instead of cutting over under pressure. And clear decision authority on the company side, so the twenty to thirty entitlement decisions that surface during separation get made in days instead of weeks.
The cost you cannot see in the quote is the cost of getting Phase 1 wrong. Underinvest in inventory and dependency mapping and you rediscover the gaps under pressure during migration, when changes are most expensive. The cheapest phase protects the most expensive one.
Build, buy, or lean on the TSA
There are three ways to get data separation done, and the right answer depends on what you have and how long you have it.
Build an internal team. This makes sense when the carved entity is large enough to justify permanent data and IT leadership, and when the separation timeline is long enough to recruit and onboard. The trap is timing. By the time you have hired a data leader, agreed what “done” means, and let them build a roadmap, you have spent a quarter of a short TSA window. Separation is a finite project with a hard deadline. Hiring for it as if it were a permanent capability often delivers the team after the work needed to start.
Hire an external provider. This is the default for most mid-market carve-outs because the work is intense, finite, and deeply specialised. You are buying people who have separated commingled ERPs before and will not learn on your timeline. The risk is the vague scope I described above, and providers who are strong on infrastructure but light on the data quality and reconciliation work that actually consumes the budget. Buy for the migration and validation expertise, not the headcount.
Lean on the TSA. The transitional service agreement lets the parent keep running shared systems for a period after close, which feels like it defers the problem. It does, and that is the danger. TSA durations are set during deal negotiation when both sides want to look competent, then reality runs longer. Six months is the typical proposal. Twelve to eighteen is the typical outcome. The TSA buys you time to separate. It does not do the separation. Treat it as a bridge with a defined exit, not a parking space.
Most real engagements are a blend. An external provider runs the separation, a small internal team owns decisions and prepares to operate the standalone environment, and the TSA covers the gap until that environment is stable. The mistake is treating any one of the three as the whole answer.
Who should own it on the company side
This is the question that determines whether the money is well spent, and it is the one most often left unanswered until it is a problem.
Data separation needs a single owner on the company side with real authority. Not a coordinator. Not a steering committee. One person who can make the entitlement calls, settle the disputes between finance and operations about whose number is right, and hold the provider to scope.
In practice the right owner is usually the carved entity’s incoming CFO or a dedicated separation lead reporting to them, supported by a data lead who understands the systems. The CFO has the strongest incentive, because they will live with the consequences. Their books have to close on the standalone system. Their auditors will ask why the migrated revenue totals tie. Their board deck has to run on day one.
What does not work is letting the parent’s IT team own it by default. Their incentive is to stop providing services and move on, not to set the carved entity up to thrive. They will do the technical work competently and make the judgment calls in the parent’s favour, because that is who they answer to. The owner has to sit on the side of the business that has to live with the result.
If you cannot name the single owner before the work starts, fix that before you sign a provider. The provider can supply the hands and the method. They cannot supply the authority to decide.
Questions to ask a provider before you engage
Before you sign anyone, put these questions to them and listen for specifics rather than reassurance.
Which of the five scope areas do you own, and which do you assume we own? A good provider draws the line clearly. A weak one waves at “end to end.”
How do you handle shared master data and referential integrity? This is the work that consumes budgets. If they talk only about infrastructure and not about extracting a clean subset of customers, vendors, and chart of accounts while keeping every transaction tied, they have not done this before.
How do you validate the migration? You want automated reconciliation at multiple levels, period totals, account balances, record counts, and sample field comparisons, run iteratively. “We test thoroughly” is not an answer.
What is your assumption on TSA duration, and what happens if it runs short? The answer should reflect that TSAs run long and should include a stabilisation buffer after migration completes.
Who from your team is actually doing the work, and have they separated a commingled ERP before? You are buying experience, not a logo.
How do you price scope change? Separation scope grows. The honest providers tell you that up front and explain how they handle it, instead of quoting a clean fixed number they know will move.
The way a provider answers these tells you more than the quote does. The ones who have done it will give you uncomfortable, specific answers. The ones who have not will give you smooth ones.
The bottom line
Data carve-out services are worth buying, because separating a commingled ERP under a deal deadline is specialised work you do not want a team learning on the job. But buy with your eyes open. Insist on a scope that names all five bodies of work. Budget to the realistic range, not the deal-model optimism. Decide deliberately between building, buying, and leaning on the TSA, and expect to blend all three. Above all, name the single owner on the company side before the work starts, and make sure that owner sits with the business that has to live with the result.
The separation is not a side project running alongside the transaction. It is the transaction. For the integration perspective when you are acquiring rather than carving out, see data integration after add-on acquisitions. For the step-by-step method, the carve-out data separation playbook walks through all five phases.