16. Identifying separation and integration complexity during DD

The deal looked clean. The buyer was acquiring a division with its own management team, its own P&L, and a product line that rarely crossed into the parent’s other businesses.

The first diligence readout said separation would be “straightforward.” Then the team mapped five workflows: order-to-cash, procure-to-pay, payroll, close and consolidation, and customer support. The division shared the parent’s SAP instance, used parent-owned customer IDs, ran payroll through a regional HR platform, and depended on a shared data warehouse for revenue reporting. The call center tool was separate, but its knowledge base sat on the parent’s tenant.

Nothing was unusual. That was the point.

In many deals, separation and integration complexity is not a single red flag. It is a set of ordinary dependencies that turn a clean transaction into a program with a different clock, different TSA terms, and different cash needs.

The primary decision in diligence is this:

Should the deal be treated as a clean integration or separation, or as a dependency-heavy program that needs changes to timing, TSAs, one-time cash, and Day-1 commitments before signing?

Why this decision matters before price is locked

Complexity found after close becomes execution noise. Complexity found before signing becomes underwriting.

The same technology dependency can hit the deal in four ways:

• Timing: separation or integration moves from a 6-9 month plan to a 12-18 month program because core workflows depend on shared systems, shared data, or seller capacity.
• TSA cost: the buyer pays for longer service terms, higher project support, exit extensions, or seller change requests.
• One-time cash: the business needs tenant splits, ERP carve-out work, identity redesign, data remediation, or interim tooling before value work can start.
• Day-1 stability: payroll, billing, close, customer access, or cyber controls depend on handoffs the seller is not prepared to support.

If diligence does not classify the deal correctly, the model keeps the wrong clock. The purchase price assumes clean execution. The TSA is negotiated as a utility. The integration or separation team inherits a dependency map no one priced.

The common mistake: asking whether systems are “separable”

Most systems are separable if you spend enough time and money. That answer is not useful.

The better question is: what must remain connected, for how long, under whose control, and at what cost?

That wording changes the work. It forces the team to move from architecture opinion to operating evidence:

• Which workflows must work on Day 1 without interruption?
• Which applications, data feeds, and roles support those workflows today?
• Which dependencies require seller action, not just buyer effort?
• Which dependencies block value capture, TSA exit, or regulatory control?
• Which decisions must be made before signing because they affect price, covenants, or TSA terms?

The answer is rarely “high complexity” or “low complexity.” It is usually a deal posture: clean, contained, or dependency-heavy.

A practical classification: clean, contained, or dependency-heavy

Use a three-posture test during diligence. It is simple enough for a deal team and specific enough to change terms.

Clean

Treat the deal as clean when the target or acquired business has dedicated core systems, documented interfaces, transferable contracts, and limited dependency on seller or buyer platforms for Day-1 operations.

Typical signs:

• one ERP instance or a clearly dedicated ERP company code with clean master data boundaries
• dedicated identity tenant or well-scoped user population
• applications and licenses that transfer without consent issues
• no more than 10-15 critical interfaces requiring Day-1 continuity
• finance, payroll, billing, and customer support workflows owned by the business being acquired

Clean does not mean easy. It means the dependencies do not set the deal clock.

Contained

Treat the deal as contained when the business has a few shared services or systems, but the dependencies are visible, contractable, and not on the path to near-term value capture.

Typical signs:

• shared ERP or HR system, but with clear legal-entity, cost-center, and data boundaries
• seller support needed for 6-12 months, with named service owners and measurable service levels
• a limited number of shared integrations that can be replicated or replaced without changing the operating model
• no known dependency that blocks the first two close cycles, payroll runs, customer invoicing, or key reporting

Contained deals need discipline. They usually do not need a full thesis reset.

Dependency-heavy

Treat the deal as dependency-heavy when shared technology, shared data, or unclear ownership controls the timeline for Day 1, TSA exit, or value capture.

Typical signs:

• multiple ERP instances or parent-owned master data across customers, products, vendors, or chart of accounts
• shared identity, network, data warehouse, or reporting layer with weak boundaries
• more than 25-30 critical interfaces across systems, with many undocumented or person-owned
• seller-only knowledge for configurations, batch jobs, security roles, or month-end reporting
• TSA term under 9 months while ERP, payroll, finance, or customer support separation is not scoped
• synergy plan depends on early system consolidation, data access, or process standardization

Dependency-heavy does not mean the deal is bad. It means the deal needs different underwriting.

The five evidence asks that separate story from fact

You can classify the deal quickly if you ask for evidence tied to workflows rather than system lists.

1) A Day-1 critical workflow map

Ask for one page per workflow: order-to-cash, procure-to-pay, payroll, record-to-report, customer service, and any industry-specific workflow that drives revenue or compliance.

For each workflow, require:

• applications involved
• system of record
• upstream and downstream data feeds
• owning team
• manual workarounds
• seller or buyer dependency

If management can name systems but cannot map the workflow, the deal team does not yet know what must be protected on Day 1.

2) The interface register for critical systems

Ask for source, target, data type, frequency, method, monitoring, and owner. A screenshot of an integration diagram is not enough.

The key test is ownership. If a batch job fails during the first month-end close, who fixes it? If the answer is a person in the parent who is not named in the TSA, the risk is not technical debt. It is a missing service obligation.

3) A shared-services and shared-platform dependency list

Ask for dependencies on parent or buyer platforms across:

• ERP and finance
• HRIS and payroll
• identity and access management
• network, endpoints, and security tooling
• data warehouse, BI, and management reporting
• contact center, CRM, and customer portals
• procurement, AP, treasury, and tax systems

The list should distinguish “runs on shared platform” from “depends on shared data or shared people.” Many teams catch the first and miss the second.

4) TSA draft assumptions before the TSA is drafted

Ask management to define service scope, duration, volume, support model, service levels, data access, project support, exit rights, fee escalators, and change request mechanics.

This is where complexity becomes cash. A cheap TSA with no project support can cost more than a premium TSA with clear exit support. If the buyer needs seller engineers to extract data, replicate interfaces, or support test cycles, that work must be written into the deal mechanics.

5) The first 100-day change calendar

Ask what changes are already planned around close: ERP upgrades, payroll cycles, data warehouse migrations, cyber remediation, vendor renewals, site moves, major releases, and finance close dates.

A dependency-heavy deal with a quiet change calendar may be manageable. A contained deal with payroll cutover, ERP patching, and quarter-end reporting in the first 45 days may not be.

Decision triggers that should change the deal posture

Use triggers that force a decision. “Complexity exists” is not enough.

Trigger 1: Core finance or payroll depends on seller systems beyond the proposed TSA term

If record-to-report, AP, AR, treasury, tax, HRIS, or payroll cannot exit within the proposed TSA term plus one close-cycle buffer, the plan is underwritten on the wrong date.

What it changes:

• extend the TSA or narrow the Day-1 commitment
• add seller project support and data extraction rights
• fund interim finance, HR, or payroll tooling
• reset any synergy tied to finance process standardization

Trigger 2: Master data boundaries are unclear in ERP, CRM, or procurement

If customer, product, vendor, employee, or chart-of-account data is shared without clear ownership and extract logic, Day-1 continuity may be fine while Day-100 value stalls.

What it changes:

• make master data separation a priced workstream
• add a value gate before pricing, procurement, cross-sell, or reporting synergies start
• require a seller data covenant if the seller owns source systems

Trigger 3: Seller-only people own the runbook

If critical workflows depend on parent employees who are not transferring and are not named in the TSA service model, the buyer is buying undocumented operating knowledge.

What it changes:

• include named knowledge-transfer sessions, runbooks, and hypercare support in the TSA
• hold back aggressive cutover milestones until runbooks are tested
• budget contractor or managed-service backfill before close

Trigger 4: TSA exit requires system build and operating model build at the same time

If the buyer must stand up ERP, identity, security, reporting, service desk, and IT operations before exit, and the target IT team is small, the timeline is not just a technology timeline. It is a capability build.

What it changes:

• split stabilization from exit work
• add program capacity and external delivery support
• sequence value capture after operating ownership is in place

Trigger 5: The value plan assumes early integration of systems that should be isolated

If synergy depends on connecting CRM, ERP, data platforms, or identity in the first 100 days, but diligence shows weak data controls, fragile interfaces, or cyber gaps, early integration can add risk faster than it adds value.

What it changes:

• move from integrate-now to isolate-and-wrap
• fund data and control remediation as a gate
• delay synergy recognition until the gate is met

What goes wrong when the posture is wrong

Three failure patterns show up after close.

The TSA becomes the operating model

The buyer signs a TSA to preserve continuity, then treats it as background support. Six months later, the separation work has barely started because every operational issue routes back to the seller. The seller is paid to keep services running, not to make the buyer independent.

The consequence is predictable: fee escalators, service fatigue, missed exit dates, and integration teams spending year one on disentanglement instead of EBITDA programs.

Day-1 works, but Day-100 value does not

The business invoices customers and pays employees on Day 1. Everyone declares success. Then the value plan stalls because pricing data is not portable, supplier spend cannot be analyzed, customer reporting is inconsistent, or security rules block connectivity.

Day-1 stability hid the dependency. It did not remove it.

The one-time cash estimate excludes dependency removal

The model includes integration management, some application work, and advisory support. It misses the expensive middle: tenant separation, data remediation, interface rebuilds, testing cycles, license true-ups, and seller project support.

The first budget reset usually arrives after close, when the buyer has less room to reprice and more pressure to protect operations.

How best teams handle it before signing

Strong teams do not try to solve the full separation or integration in diligence. They force the right deal posture early and make it traceable.

They build a dependency heatmap tied to value gates

The heatmap ranks each critical workflow on two axes:

• dependency on seller or buyer-controlled systems
• impact on Day-1 stability, TSA exit, or value capture

The output is not a maturity score. It is a decision list: what can be integrated or separated early, what must be wrapped, and what must stay under TSA until a named gate is met.

They convert dependencies into deal mechanics

Each dependency should land in one of five places:

• purchase price or value haircut
• TSA scope, duration, service level, or exit support
• one-time cash budget
• Day-1 readiness gate
• Day-100 value gate

If a dependency lands nowhere, it has not been underwritten. It has only been documented.

They put owners on the clock

Dependency-heavy deals fail when ownership is split across corp dev, legal, IT, and operations without a single economic owner.

Before signing, best teams assign:

• deal lead: posture decision and economics
• technology diligence lead: evidence and dependency map
• legal lead: TSA and covenant mechanics
• integration or separation lead: Day-1 and Day-100 gates
• finance lead: one-time cash, run-rate, and timing changes

This is not governance for its own sake. It keeps the dependency map connected to the price, the contract, and the first 100 days.

A simple decision rule for the deal team

Use this rule in the diligence readout:

If the target has dedicated core systems, transferable contracts, and fewer than 15 critical Day-1 interfaces, treat the deal as clean unless a value lever proves otherwise.

If the deal has shared systems but clear data boundaries, named owners, and a TSA path of 6-12 months with project support, treat it as contained and price the known work.

If the deal has shared ERP or payroll, unclear master data boundaries, seller-only runbook knowledge, more than 25-30 critical interfaces, or TSA exit under 9 months without a scoped build plan, treat it as dependency-heavy. Change the clock, the TSA, and the one-time cash before signing.

That call should be explicit in the IC memo. “No major technology issues” is not a posture.

Monday-morning actions

In the next 10 business days, the deal lead should run a short posture sprint with technology, finance, legal, and the integration or separation lead.

1. Pick the six workflows that must not break. Start with order-to-cash, procure-to-pay, payroll, record-to-report, customer service, and security operations.
2. Map systems, data feeds, owners, and seller dependencies for each workflow. Keep it to one page per workflow.
3. Classify the deal as clean, contained, or dependency-heavy. Do it before the TSA and model are locked.
4. Turn the top 10 dependencies into economics. Timing change, TSA term, one-time cash, run-rate impact, or Day-100 gate.
5. Write the posture into the IC memo and TSA term sheet. If the dependency affects value or continuity, it belongs in the deal record.

The point is not to eliminate complexity before signing. You won’t. The point is to stop pretending a dependency-heavy deal is clean because Day 1 can be made to work.

Clean deals move fast because the systems allow it. Dependency-heavy deals can still create value, but only when the buyer prices the clock, contracts the help, and funds the work before the first post-close fire drill.