Carve-outs: the systems a business shares with its parent

Some businesses arrive in a deal as a company with its own systems. Others arrive as a piece of something larger: a product line sold out of a group, or a company that has spent years running on a parent's cloud account, login service, payment account and engineers. On the org chart the line is clear. In the systems it often is not.

A buyer in that position is paying for a business that does not yet exist on its own. The product works today because the parent quietly provides parts of it. The question for diligence is which of those parts the buyer will have to rebuild, buy or borrow, in what order, at what cost, and what happens to customers while that work is under way.

This is the reviewer's view of a carve-out: how shared systems are found, which must be separated before closing, which can run for a time under the seller's support, and what the first months after closing tend to look like.

Why a carve-out is a different review

In an ordinary acquisition the target's systems come with it. The review asks whether they are sound, owned and fit for the buyer's plan. In a carve-out a further question comes first: where does the business end? The answer is rarely written down. The asset list in a draft purchase agreement names products, domains and contracts. The systems underneath were never built with a sale in mind, so they cross that line in dozens of places.

Three things make the work slower than a standalone review, and none of them can be rushed:

• The team being sold often does not know what the parent provides. Engineers know their application, not always who runs the identity service or which group contract covers the email platform.
• The seller's interests are split. The parent wants a clean sale but also wants to protect its own systems, data and remaining businesses. Access to shared systems is often narrower than the reviewer would like, and has to be negotiated through the parent's IT and security teams under the access protocol.
• Cost figures describe an allocation, not a business. The carve-out financials usually carry a share of group costs. What the product will cost to run on its own, with its own accounts and contracts, is a different number, and the technology review is often where the gap first shows.

Our engineering partner PERETZ looks at the same problem from the other end, after the deal, in What Happens to the Website After an Acquisition?: domains, accounts, integrations and customer data that turn out to belong to someone else once a business changes hands. In a carve-out that discovery has to happen before signing, because the buyer's plan and price depend on it.

Drawing the perimeter of the business

The first deliverable in a carve-out review is a map of the perimeter: everything the product needs to run, marked by who owns it today and who will own it after closing. We build it from the product outward. Start with what a customer touches, the application, the login page, the invoice, the support email. Then follow each part back to the account, contract, server or person behind it.

Each item lands in one of three groups:

• Dedicated. Used only by the business being sold and already held in a form that can transfer: its own repository, its own cloud account, a contract in the right legal entity.
• Shared and separable. Used by the business and by the parent or a sister company, but a copy, a split or a new contract is a known piece of work.
• Shared and entangled. So bound into the parent's systems that separating it is a project in its own right: one database holding several businesses' customers, a group login used by all products, a payment account in the parent's name.

The map runs across all six layers of our review. Ownership and IP decide what can transfer at all. Infrastructure and cost holds most of the shared accounts. Data and privacy holds the hardest separations. Security and access shows who can still reach the product after closing. Team and knowledge shows who actually runs it.

Where shared systems hide

Some shared items are obvious from the first call. Others surface only in a configuration file or a billing export.

Cloud accounts and infrastructure

The product often runs in an account or organization that belongs to the parent, sometimes in the same network as other businesses, sometimes on a shared database cluster. Logging, monitoring, backups and security tooling may be group services. Group cloud discounts do not travel with the product.

Code repositories and shared libraries

The product's code may sit in the parent's source control, sometimes inside one large repository with other products. Even when it has its own repository, it may depend on internal packages for login, billing, logging or design components that the parent maintains. Builds may run on the parent's pipeline with the parent's secrets. Mobile apps are often published under the parent's developer account, with signing keys held by group IT.

Licenses held by the parent

Commercial software, data feeds, fonts, SDKs and SaaS tools are frequently bought under group agreements. Whether a license can be assigned or must be bought again is a point for counsel. The reviewer's job is to list each one the product depends on, what breaks without it, and what a standalone contract would roughly cost.

Customer data and identity

This is usually the hardest area. Customer records may live in a shared CRM, a shared billing system or one database across products. Customers may log in with a group account they also use elsewhere. Consent and privacy notices may name the parent entity. Splitting the data means deciding, record by record, which customers belong to the business being sold, and some will belong to both.

Domains, email and payment accounts

A product served from a subdomain of the parent's domain cannot simply be transferred. It needs a new address, redirects and a plan for search history. Transactional email may be sent from the parent's domain, on the parent's sending reputation. Payment accounts are often held by the parent's legal entity. A new merchant account means new underwriting, and stored card details held by the processor can only move with the processor's cooperation.

People who work for both

Engineers, support staff and IT people may split their time across businesses, and some of the knowledge the product depends on sits with people who will stay with the parent. Who transfers is an employment matter for counsel and the deal team. The reviewer's part is to show which roles the product cannot run without, and where that knowledge is written down, if anywhere. Our note on key-person risk covers how that is rated.

Before closing, or under transition services

Almost no carve-out separates everything before closing. Some services keep running for the buyer after the deal under a transition services agreement, in which the seller provides an agreed service for a fixed period at an agreed price. How that agreement is drafted, priced and enforced is for counsel and the deal team. We do not negotiate it. What the technology review supplies is the list of what it has to cover and how long each item is likely to need.

Items usually have to be settled before closing when the buyer cannot safely depend on the seller for them even for a short time:

• Ownership of the code and the right to use any shared libraries the product needs.
• Administrative control of the domains, app listings and accounts customers see.
• Named access for the buyer's people to production, backups and monitoring from day one.
• A defined, agreed scope of the customer data that belongs to the business.
• Credentials that the seller's remaining staff should no longer hold, listed with a rotation plan.

Items that often run under transition services: hosting in the parent's account until the migration is done, the group login until customers move, payment processing until a new merchant account is live, group security monitoring, and some support or IT functions. For each, the review should state what exactly the service is, how the buyer will know it is working, what the realistic exit date is, and what help the seller must give at the end, such as data exports or a cutover window. A transition service with no clear end and no exit plan tends to become a permanent dependency on a company that no longer has a reason to prioritize the product.

Where the parent keeps using something that leaves with the business, the review lists those reverse dependencies too.

Severity follows the same scale as any review. Code the buyer cannot clearly own, or customer data with no agreed split, can be Critical. A shared cloud account with a clear migration path is often High: it needs a plan and a budget, not a delay.

Pricing and scheduling the separation

A carve-out carries two kinds of cost that a standalone deal does not, and they are often confused.

One-time separation cost. The work of moving out: new accounts, data extraction, a new login service, a new merchant account, copied pipelines, rewritten integrations, testing, and the people to do it. We estimate it the way we estimate any fix, in engineer weeks by the kind of people needed, as a range with stated assumptions. The high end usually reflects what could not be seen, such as a shared database the parent would not let us read in full.

Ongoing standalone cost. What the product will cost to run each year once it is on its own: cloud at list prices without group discounts, licenses bought at a smaller company's rates, security and monitoring tools the parent used to provide, people who were partly paid by the parent. This number often differs from the allocation in the carve-out financials. Whether and how it affects price is for the deal team and its advisors. The review states the facts and the ranges.

Scheduling depends on order more than on headcount. Identity and data usually come first, because almost everything else depends on knowing which customers and accounts belong to the business. Infrastructure moves follow. Payment changes need overlap time, because live subscriptions cannot stop. As a rule of thumb, separations tend to take longer than the first plan, and transition periods that look generous on paper get used in full. The schedule should show what can run in parallel and where one late item delays the rest. One more caution for counsel: a cost already reflected in price should not also sit in a transition budget or an escrow for the same work.

The first months after closing

The risks in a carve-out shift on the day the deal closes. Before closing, the danger is not knowing what is shared. After closing, it is depending on a seller whose attention has moved elsewhere. Problems we typically see in this period:

• Access removed too early, or too late: the parent's security team closes accounts the product still needs, or leaves former colleagues with production access.
• Data copies that look complete and are not: missing history, broken links between records, attachments left behind.
• A login cutover that locks customers out, or a payment change that drops renewals without anyone noticing for weeks.
• Monitoring and security alerts that used to go to a group team and now go nowhere.
• Certificates, domain renewals and vendor contracts that expire because their reminders went to a parent mailbox.
• Knowledge leaving with people who chose to stay with the parent.

Most are cheap to prevent and expensive to discover, so they belong in the first 30 days of the plan. Our note on turning the diligence report into a 100-day plan covers how findings move into that schedule, and ownership gaps covers the transfer checklist between signing and closing.

A carve-out checklist

Questions worth answering before the purchase agreement is final:

• Is there a written perimeter: every system the product needs, who owns it now and who will own it after closing?
• Has the reviewer seen the shared accounts and databases directly, or only heard them described?
• Can the buyer own the code outright, and are rights to shared internal libraries settled with counsel?
• Who holds the app store accounts, signing keys, domains and DNS, and when do they move?
• Is the customer data split defined, including customers who belong to both businesses?
• Which licenses and contracts sit in the parent's name, and what does each cost on standalone terms?
• Does every transition service have a scope, a measure of service, an exit date and exit help?
• Are separation cost and standalone running cost estimated separately, with assumptions?
• Which people does the product depend on, and do they transfer, stay or need replacing?
• Is there a day-one access and credential plan, with alerts and renewals routed to the buyer?

What to do next

If you are buying a business out of a larger company, share the draft asset list and your plan for the product with the reviewer early. The perimeter map depends on both. Our technical due diligence includes a carve-out read: what is shared, what must be separated before closing, what transition services need to cover, and ranges for separation and standalone running costs, at a fixed fee agreed in writing before we start. If time is short, a red-flag memo identifies the shared items that could stop or reshape the deal.

If you are the parent selling a unit, the same map built in advance gives buyers facts instead of questions. Vendor due diligence can set out the perimeter and the separation plan from the seller's side. Neither path makes a carve-out simple. Both make the work visible before it becomes a surprise.

Questions