You signed a deal to acquire a division. The thesis is sound, the multiple is right, and the strategic fit is clear. Then someone asks a question that changes everything: “Which systems does this division actually own versus borrow from the parent?”
The answer, in most carve-outs, is uncomfortable. The division’s CRM runs on the parent’s Salesforce instance. Customer invoices flow through the parent’s ERP. The website sits on a subdomain of the corporate site, and the analytics data lives in a shared Google Analytics property the division cannot export. Pipeline reporting pulls from dashboards the division has read access to but does not control.
This is the live problem in every carve-out: revenue that appears standalone on the P&L actually depends on systems, data, and processes the parent still owns. If you do not scope what is shared, build what must be standalone, and negotiate transition services for what cannot be ready by close, you inherit a business that cannot operate independently. According to Bain & Company, more than half of carve-out separations experience significant operational disruptions, often because technology and commercial system dependencies were underestimated during diligence.
I have worked through carve-out separations where the Day 1 standalone checklist had over 200 line items, and others where sponsors assumed the business was “already separate” only to discover three weeks before close that customer contracts were signed by the parent entity and could not be assigned without consent. The difference between a smooth separation and a fire drill is a structured framework that identifies dependencies early, assigns ownership, and sequences the build-or-TSA decision for each shared asset.
This article walks through that framework, section by section, with a usable separation matrix you can adapt to your deal.
Revenue that depends on the parent’s systems
A carve-out looks clean in the CIM. Revenue is attributed to a division. Headcount is allocated. EBITDA is calculated with corporate overhead add-backs. But revenue attribution is not the same as operational independence.
The commercial engine of a carved-out division typically relies on shared infrastructure in three areas:
- Customer data and CRM: The division’s sales team logs into a parent-owned Salesforce org. Historical data, pipeline, contact records, and automation workflows belong to the parent.
- Billing and contracts: Invoices are issued from the parent’s ERP. Contracts are signed with the parent as the legal entity. Payment processing flows through parent merchant accounts.
- Digital presence: The division’s website is a subdomain or subfolder of the parent site. Marketing automation, analytics, and ad accounts are shared or parent-controlled.
When these dependencies are not mapped before close, you face a painful choice: either extend transition services indefinitely (at parent pricing, with declining service quality) or scramble to stand up systems while the business operates in a fragile state.
McKinsey research on carve-out value capture notes that separation complexity is routinely underestimated, and that the most common failure mode is treating IT and commercial systems as a “Day 2 problem” that can be solved after close. It cannot. The systems that run revenue need to run on Day 1.
What the division uses versus what it owns
Before you can build a divestiture separation plan, you need an honest inventory of what the division uses versus what it owns. This is the separation scope exercise, and it should happen during confirmatory diligence, not after close.
Categories to Inventory
Walk through each category and document current state:
- CRM and sales tools: Which instance? Who owns the license? Can data be exported? Are there integrations with other parent systems?
- Marketing automation and email: Which platform? Shared or dedicated account? Who owns the subscriber lists?
- Website and domains: Who owns the domain registration? Where is the site hosted? Is content in a shared CMS?
- Analytics and tracking: Shared GA4 property? Shared ad accounts? Shared tag manager containers?
- ERP and billing: How are invoices generated? Where does payment processing sit? Who owns merchant accounts?
- Contracts and legal entities: Which entity signed customer contracts? Are assignments required?
- Data and reporting: Where does operational data live? Who has access? What is the extraction path?
For each item, document the current owner, access level, and whether the division could operate tomorrow if the parent revoked access today.
Pipeline, contracts, and billing continuity
Commercial continuity is the first priority in any carve-out separation. If customers cannot be invoiced, contracts cannot be enforced, or pipeline cannot be tracked, the business cannot function.
Pipeline and CRM
The division’s pipeline is not “the division’s” if it lives in the parent’s CRM. You need a data migration plan that extracts accounts, contacts, opportunities, and activity history into a standalone CRM instance the new entity controls.
Key questions:
- Can historical data be exported, or is it commingled with parent accounts?
- Are there workflow automations that depend on parent-owned fields or integrations?
- Does the sales team need re-training on a new CRM, or can you migrate to the same platform under a new license?
If you are building a standalone CRM, start in diligence. A clean migration takes 4 to 8 weeks minimum, and you do not want your sales team operating blind on Day 1.
Contracts and Legal Entity
If customer contracts were signed by the parent entity, you need assignment or novation. This is not a technology problem, but it affects every system that touches customers. Work with legal to identify which contracts require consent, which can be assigned by notice, and which need renegotiation.
For recurring revenue businesses, this is especially critical. SaaS contracts, subscription agreements, and multi-year commitments may have change-of-control clauses that give customers termination rights.
Billing and Payment Processing
The division needs its own billing infrastructure by Day 1 or under TSA. This includes:
- A standalone ERP or billing system (or a clean instance of the parent’s system under new license)
- Merchant accounts and payment processors in the new entity’s name
- Invoice templates with the new entity’s branding and legal information
Revenue cannot flow if invoices cannot be issued. This is a Day 1 requirement, not a Day 30 project.
Standing up marketing and analytics infrastructure
Beyond commercial continuity, the division needs its own marketing and analytics infrastructure to operate and grow. This is where many carve-outs stumble, because these systems are often shared without clear boundaries.
CRM Stand-Up
If the parent’s CRM cannot be licensed separately, you will need to migrate to a new platform. The stand-up plan should include:
- Platform selection (same platform, new license vs. new platform entirely)
- Data migration scope (accounts, contacts, opportunities, activity history, custom objects)
- Integration requirements (email, calendar, marketing automation, support ticketing)
- User provisioning and training
For detailed guidance on CRM migration during M&A, see this M&A integration playbook for CRM and data.
Marketing Automation
If the division’s email marketing runs through a shared HubSpot or Marketo instance, you need to extract subscriber lists, templates, and workflows. Key considerations:
- Subscriber consent: Do contacts have consent to receive email from the new entity?
- Domain reputation: The new entity will need to warm up sending domains from scratch.
- Automation dependencies: Which workflows depend on parent-owned integrations?
Analytics and Tracking
A shared Google Analytics property cannot be “split.” You need a new GA4 property, new Google Tag Manager container, and new tracking implementation. Historical data stays with the parent.
The same applies to advertising accounts. Shared Google Ads, Meta, or LinkedIn accounts need to be replicated, not transferred. Audience data, conversion history, and optimization learning do not migrate.
Website, domain, and brand ownership
The division’s web presence is often the most visible dependency and the most underestimated separation workstream.
Domain Ownership
If the division operates on a subdomain (division.parent.com) or subfolder (parent.com/division), there is no standalone web presence to transfer. You need to:
- Acquire or register a new domain
- Build a standalone website on new hosting infrastructure
- Implement redirects from the old URLs (negotiated in the purchase agreement)
- Update all external references (directories, backlinks, advertising)
If the division has its own domain but it is registered under the parent’s account, transfer ownership as a closing condition.
Website Build or Migration
A division website that runs on the parent’s CMS cannot be “exported” cleanly. In most cases, you are building a new site. The stand-up plan should include:
- Content audit and migration scope
- Design and branding updates (new entity identity)
- SEO preservation (redirect mapping, metadata migration)
- Hosting and infrastructure under new entity control
This work takes 6 to 12 weeks for a typical B2B division. Start during diligence, not after close.
Brand Assets
Clarify ownership of logos, brand guidelines, photography, and content. If the division used parent brand assets, you need new creative. If the division has its own brand, confirm that trademarks and assets transfer with the deal.
Data extraction and ownership rights
Data is the most contentious area in carve-out due diligence. The parent may resist full extraction, claiming that customer data is commingled or that certain datasets are “corporate assets” not included in the sale.
What Data You Need
At minimum, the division needs:
- Customer master data (accounts, contacts, billing history)
- Transaction history (orders, invoices, payments)
- Pipeline and sales activity
- Product usage data (for SaaS or subscription businesses)
- Marketing engagement history (email, web, advertising)
- Support and service records
Extraction Mechanics
Data extraction is a technical and legal workstream. Technical because you need export formats, data mapping, and import processes. Legal because you need to confirm that the purchase agreement grants rights to the data and that privacy regulations (GDPR, CCPA) permit transfer.
Build data extraction into the purchase agreement as a closing condition or TSA obligation. Do not assume the parent will cooperate after close without contractual obligation.
Historical Data Limitations
In many carve-outs, you will not get complete historical data. The parent may retain commingled records, or extraction may be technically infeasible. Plan for this reality:
- Establish a baseline cutoff date
- Accept that some historical reporting will be incomplete
- Build new data collection processes from Day 1
According to Deloitte’s research on carve-out separations, data and IT dependencies are the leading cause of TSA extensions, often because data extraction scope was not defined clearly during diligence.
The Day 1 standalone checklist
A Day 1 standalone checklist is the operational backbone of your stand-up plan. It lists every system, process, and asset that must be in place for the division to operate independently on the first day under new ownership.
Core Day 1 Requirements
- Legal entity: New entity formed, bank accounts open, signing authority established
- Contracts: Customer contracts assigned or novated, key vendor agreements in place
- Billing: Invoicing system operational, payment processing live, AR/AP processes defined
- CRM: Standalone instance live, data migrated, users provisioned
- Website: Standalone domain live, core content published, analytics tracking installed
- Email: Corporate email on new domain, marketing email operational
- Support: Customer support channels operational (phone, email, ticketing)
- HR and payroll: Employees onboarded to new entity, payroll processing live
TSA-Covered Items
Not everything can be standalone by Day 1. Items under transition services agreement should have:
- Clear service descriptions
- Defined duration (typically 3 to 12 months)
- Exit triggers and timelines
- Pricing (usually cost-plus, with escalation after initial period)
For a detailed approach to planning your TSA exit, see this transition services agreement exit plan.
What a TSA should and should not cover
A transition services agreement is a bridge, not a destination. The purpose is to maintain operational continuity while standalone capabilities are built. But TSAs can become traps if not structured correctly.
What a TSA Should Cover
- Systems that cannot be replicated by close (complex ERP, specialized platforms)
- Services that require knowledge transfer (finance operations, IT support)
- Infrastructure that needs lead time (data center migration, telecom)
- Vendor relationships that cannot be transferred quickly
What a TSA Should Not Cover
- Systems that can be stood up independently before close (website, basic CRM, email)
- Services that create ongoing dependency (sales operations, customer success)
- Data access that should be a one-time extraction, not ongoing service
- Anything where the parent has misaligned incentives to provide quality service
A good TSA has explicit exit criteria and declining service levels after the initial period. You want the parent incentivized to help you leave, not to extend the arrangement.
For a comprehensive integration checklist that complements this separation framework, see this post-merger integration checklist.
The working document that tracks every shared asset
The framework above becomes operational through a separation matrix, a single document that tracks every shared asset, its current state, target state, and ownership. This is the working document your separation management office uses to track progress and flag risks.
Below is a usable carve-out separation matrix you can adapt to your deal:
| Shared Asset | Current Owner | Day 1 Target State | TSA or Build | Workstream Owner |
|---|---|---|---|---|
| CRM (Salesforce) | Parent IT | Standalone instance, data migrated | Build | Sales Ops Lead |
| Marketing Automation (HubSpot) | Parent Marketing | New account, lists migrated | Build | Marketing Lead |
| Website (subdomain) | Parent IT | Standalone domain, new site live | Build | Digital Lead |
| Analytics (GA4) | Parent Marketing | New property, tracking installed | Build | Digital Lead |
| ERP / Billing (SAP) | Parent Finance | Continued access, invoicing functional | TSA (6 months) | Finance Lead |
| Payment Processing | Parent Treasury | New merchant accounts live | Build | Finance Lead |
| Customer Contracts | Parent Legal Entity | Assigned or novated | Pre-close | Legal Lead |
| Support Ticketing (Zendesk) | Parent Support | New instance, history migrated | Build | Support Lead |
| Corporate Email | Parent IT | New domain, accounts provisioned | Build | IT Lead |
| Data Warehouse | Parent IT | Extracted data in new environment | TSA (3 months) | Data Lead |
Each row should be assigned to a workstream owner with weekly status tracking. Items marked “Build” need project plans and resource allocation. Items marked “TSA” need contractual documentation and exit milestones.
Applying the framework
Note: This is an illustrative scenario, not a client outcome or case study.
Consider a private equity sponsor acquiring a B2B software division from a diversified technology company. The division has $40M in ARR, 50 employees, and a clear product focus. The thesis is that under independent ownership, the division can accelerate growth without competing for resources within the parent.
During carve-out due diligence, the deal team discovers:
- The division’s CRM is a shared Salesforce instance with 200+ custom fields tied to parent products
- Customer contracts are signed by the parent entity, and 30% have change-of-control clauses
- The website is a subfolder on the parent’s domain with no standalone analytics
- Billing runs through the parent’s NetSuite, with no clean way to extract historical data
Using the separation matrix framework, the team categorizes each dependency:
- CRM: Build. New Salesforce instance, migrate division accounts only, 6-week project starting immediately.
- Website: Build. New domain registered, standalone WordPress site, 8-week project.
- Billing: TSA. NetSuite access for 6 months while standalone billing is implemented.
- Contracts: Pre-close. Legal workstream to obtain assignments or customer consents.
By close, the division has a functional CRM, a live website on its own domain, and TSA coverage for billing. The integration plan for the first 100 days focuses on completing the billing migration and exiting the TSA.
Separation discipline protects the thesis
A carve-out thesis depends on the division operating independently. If commercial and digital systems remain entangled with the parent, you have not actually acquired a standalone business. You have acquired a dependency.
The framework outlined here, from separation scope through Day 1 checklist and TSA structure, is designed to force clarity early. Map what is shared. Decide what to build versus what to bridge. Assign owners. Track progress weekly.
The carve-out separation matrix is not a planning exercise. It is the operational document that keeps revenue running while you build independence.
To stand up the commercial and digital systems of a carve-out by close, DevriX can run separation execution.
