# Identifying separation and integration complexity during DD > How to spot the technology dependencies that set the separation or integration clock before the deal team locks price, TSAs, and Day-1 commitments. Chapter 16 of 60 in the [M&A Playbook](https://elbantli.com/insights/), section “Pre-deal and tech due diligence”. By [Naoufal El Bantli](https://elbantli.com/), Tech & IT M&A practitioner. Published 2026-03-31, updated 2026-10-05. 10 min read. Source: https://elbantli.com/insights/identifying-separation-integration-complexity-during-dd/ Diligence must decide: **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](https://elbantli.com/insights/tsa-strategy-why-most-deals-get-it-wrong/), and 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](https://elbantli.com/insights/it-contracts-licenses-vendor-lock-in-risks/) - 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 means the dependencies do not set the deal clock, even when the work itself is hard. ### 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 A dependency-heavy deal can still be a good one, but it 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](https://elbantli.com/insights/what-day-1-really-means-for-it/). ### 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 a missing service obligation rather than technical debt. ### 3) A shared-services and shared-platform dependency list Ask for dependencies on parent or buyer platforms across: - ERP and finance - [HRIS and payroll](https://elbantli.com/insights/payroll-hr-systems-global-separations/) - 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](https://elbantli.com/insights/separation-vs-integration-making-right-call-early/) - 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 When a TSA is treated as background support instead of a [time-bound exit program](https://elbantli.com/insights/managing-tsa-dependencies-exit-risks/), operational issues continue to route back to the seller. The seller is paid to keep services running, not to make the buyer independent. The consequence is fee escalation, service fatigue, missed exit dates, and year-one capacity consumed by disentanglement instead of EBITDA programs. ### Day-1 works, but Day-100 value does not Day-1 continuity can coexist with non-portable pricing data, unanalyzable supplier spend, inconsistent customer reporting, or security rules that block connectivity. Day-1 stability can hide these dependencies without removing them, so the value plan stalls after operations are stable. ### The one-time cash estimate excludes dependency removal A model that includes integration management, application work, and advisory support can still omit tenant separation, data remediation, interface rebuilds, testing cycles, license true-ups, and seller project support. Those omissions force a budget reset after close, when repricing options are narrower and operational pressure is higher. ## Turn dependencies into deal terms Solving the full separation or integration is beyond the scope of diligence. Strong teams 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 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 A dependency that lands nowhere has been documented but not underwritten. ### 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, 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 Named ownership 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. ## Map the dependencies before price is locked 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. Complexity will not be eliminated before signing. 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. --- **About the author.** Naoufal El Bantli has delivered multiple IT carve-outs and IT post-merger integrations for private equity and corporate clients. His work spans IT due diligence, separation and integration strategy, ERP transformation, and Day-1 to Day-100 execution. Decision thresholds in this chapter are practical heuristics unless a source is linked. [Connect on LinkedIn](https://www.linkedin.com/in/elbantli/) Topics: [Due diligence](https://elbantli.com/insights/tags/due-diligence/), [Carve-outs](https://elbantli.com/insights/tags/carve-outs/), [Integrations](https://elbantli.com/insights/tags/integrations/) ## Related chapters - [Separation vs integration: making the right call early](https://elbantli.com/insights/separation-vs-integration-making-right-call-early/): A framework for choosing separation, integration, or a staged approach before system dependencies set the Day-1 risk, TSA clock, and synergy path. - [Tech implications of carve-out vs full acquisition deals](https://elbantli.com/insights/tech-implications-carve-out-vs-full-acquisition-deals/): How a carve-out or a full acquisition changes technology scope, Day-1 control, one-time cost, and the path from signing to a stable operating model. - [Day-1 readiness: systems, people, and data](https://elbantli.com/insights/day-1-readiness-systems-people-data/): Day-1 readiness means proving that systems, people, and data work together at close, with evidence-based gates, accountable owners, and fallbacks. Previous: [IT cost structure and budget due diligence](https://elbantli.com/insights/it-cost-structure-budget-due-diligence/) · Next: [How AI is changing tech due diligence](https://elbantli.com/insights/how-ai-is-changing-tech-due-diligence/)