Integration is where deal strategy becomes operational reality. In private equity, “integration” can mean three different jobs: separating a carved-out business from a parent, integrating an add-on into a platform, or rationalizing a product portfolio over time. Each has its own risks, timelines, and definitions of success. The common failure mode is treating integration as a generic IT project rather than an underwriting topic with customer-facing consequences.
13.1 Carve-out Tech Separation: TSA Risks, Stranded Costs, Timelines
Carve-outs are integration problems in reverse. Instead of connecting two independent companies, you are disentangling a business that has often relied on shared people, shared systems, shared networks, and shared vendor contracts for years. The first diligence objective is therefore not “what is the architecture,” but “what is shared.” The second objective is to convert shared dependencies into a separation plan that is realistic about time, cost, and operational risk.
Start by building a separation dependency inventory across six layers: identity and access, infrastructure and networks, application runtime, data and analytics, security and compliance, and operating tooling. Keep it evidence-driven and owner-assigned. When the target says “we are mostly standalone,” test it by tracing real workflows: how a new employee gets access, how production changes ship, where logs go, how billing runs, and how support investigates issues. In carve-outs, the truth usually lives in these workflows.
Identity and access: The most common carve-out blocker is reliance on the parent’s identity provider and directory. If employees authenticate through the parent’s SSO, then email, ticketing, source control, cloud consoles, and production access may all depend on it. Separation requires a new identity plane, a migration plan for accounts and groups, and a clear break-glass path during cutover. Underwrite timing based on the number of systems tied to SSO and whether role mappings and access reviews exist today. Also confirm whether customer-facing SSO is entangled with the parent’s identity infrastructure; this can create unexpected customer disruption if not isolated early.
Infrastructure and networks: Many carved-out products run in the parent’s cloud accounts, shared VPCs, shared clusters, shared monitoring, or shared CI/CD runners. Even when the product is “its own environment,” DNS zones, certificates, IP allowlists, and security tooling are often centralized. Separation means deciding what to replicate versus replace and sequencing changes to avoid downtime. A practical diligence question is: can the business run production safely if the parent turns off network connectivity tomorrow? If not, a TSA will be required and the deal should price both duration and risk. For regulated or large-enterprise customers, also validate how allowlists and private connectivity are managed, because these frequently depend on parent-owned network constructs.
Application runtime: Shared runtime dependencies often appear as “internal services” owned by the parent: centralized identity APIs, shared messaging platforms, logging gateways, shared ETL services, or shared enrichment services. These can be hard to replace quickly because they are embedded in application code. Underwrite whether each dependency can be isolated behind an interface, mocked temporarily, or replaced with a vendor service, and estimate the engineering effort required. Ask for an example of a recent incident and note which parent systems were needed to diagnose or mitigate it; runtime dependencies are often discovered first during emergencies.
Data and analytics: Carve-outs frequently share warehouses, BI tools, customer master data, and centralized reporting. Separation requires clarity on data ownership and entitlements and a migration approach that preserves customer reporting continuity. If customers expect historical analytics, the carve-out must either migrate history or communicate a reporting reset. Also underwrite whether privacy commitments can still be met during migration, especially if data is intermingled across business units. If the business relies on parent-owned data enrichment or third-party datasets contracted at the parent level, confirm whether those rights transfer or require renegotiation.
Security and compliance: Control systems often sit with the parent: vulnerability scanning, SIEM, incident response playbooks, security training, audit scope, and vendor risk management. Separation is therefore governance as much as technology. The carved-out entity must have its own control owners, evidence collection, and security operations model. If enterprise customers require SOC 2, confirm whether the carve-out can rely on the parent’s report temporarily and what conditions apply. Be explicit about what happens when the carve-out exits TSA: will audit evidence and tooling remain, or does the company need to rebuild the control system from scratch?
Operating tooling: Ticketing, CRM workflows, documentation platforms, and project trackers are routinely shared. These tools matter because they carry institutional memory and run the business day to day. Underwrite migration risk based on custom workflows and whether data can be exported cleanly. A rushed migration that loses ticket history can spike support burden and slow incident response for months. Also confirm whether customer communications (status pages, email domains, in-app messaging) are parent-controlled, because those are “trust surfaces” during a separation event.
Convert the dependency inventory into a TSA map. A TSA is not just “services for X months.” It is a set of specific dependencies with defined service levels, interfaces, data-sharing constraints, and exit criteria. Poor TSAs fail because they are vague, do not include operational details, or underestimate the work required to exit. In diligence, insist that each TSA item has a named owner on both sides, an escalation path, and a measurable definition of acceptable performance. Ambiguity becomes operational pain the first time an outage happens and responsibilities are unclear.
Assess TSA risk through four dimensions. Criticality: does the dependency affect uptime, security, or revenue operations? Controllability: can the carve-out influence the parent’s performance and priorities? Complexity: how entangled is the dependency and how hard is replacement? Data sensitivity: does ongoing data sharing create privacy or competitive concerns? High criticality plus low controllability is the classic danger zone, and it often deserves explicit deal protections, such as stronger TSA SLAs, longer transition windows, or dedicated separation funding.
Stranded costs are the silent carve-out killer. They appear when shared costs previously absorbed by the parent suddenly land on the new entity, often at a higher per-unit rate. Common categories include: cloud commitments that cannot be transferred, tooling licenses negotiated at scale, security and compliance vendor contracts, and centralized IT services. Also watch for “people stranded costs,” where key operational capabilities were provided by parent teams and must now be hired or outsourced. When the thesis depends on margin improvement, quantify stranded cost impact early so you do not confuse “post-close gross margin compression” with operational underperformance.
Timelines must be built from critical path dependencies, not from wishful dates. Plan in three horizons. Day 1 readiness: the business can operate without service interruption, even if some services remain under TSA. Day 100 stabilization: identity, monitoring, and core operational systems are stable, with measured reliability. TSA exit: each dependency has been replaced or replicated so the parent can be fully disconnected. Underwrite risk by asking for “exit proofs” for the hardest dependencies, such as a pilot identity cutover, a production workload running in the new cloud account, or a migrated ticketing dataset with preserved history.
A practical separation plan also distinguishes “clone” work from “change” work. Clone: replicate the parent’s capability in a new environment (new IdP, new monitoring stack, new CI runners). Change: modify product or process to remove dependency (replace an internal service, refactor a data pipeline, redesign provisioning). Cloning is usually faster but may import cost inefficiency; changing is slower but may reduce long-term cost and risk. Underwrite which approach is used for each dependency and ensure the plan does not attempt too much “change” work before Day 1.
Communicate carve-out separation in investor terms. Separation feasibility: high/medium/low based on dependency complexity. Critical TSAs: the few that threaten uptime or customer trust. Exit cost and timing: ranges tied to engineering capacity. Stranded cost impact: expected margin effect and timing. This translation prevents a common carve-out surprise: discovering post-close that “technology transition” is the primary value risk in year one.
13.2 Add-on Integration: Product Integration vs Technical Integration
Add-on acquisitions often begin with a simple story: cross-sell, bundle, and expand into new segments. The integration risk is assuming that “connect the systems” equals “unlock the synergy.” In practice, there are two distinct integration tracks. Product integration: what the customer experiences. Technical integration: what the systems do behind the scenes. You can achieve one without the other, but you cannot claim synergy without clarity on both.
Product integration: This is about workflows, packaging, and value delivery. It answers questions like: will customers perceive one coherent solution, and will the combined offering reduce friction and increase outcomes? Product integration can be light-touch (unified login and navigation) or deep (shared data model and end-to-end workflows). The key is defining the minimum viable customer-facing integration required to unlock the deal thesis, then sequencing deeper work only when adoption proves it is worth the cost.
Technical integration: This is about identity, data flows, deployment, observability, billing/entitlements, and security posture. It answers questions like: can the products interoperate safely, and can we operate them without doubling operational burden? Technical integration often requires foundational work when the add-on has different tenancy assumptions, weaker reliability practices, or a different security bar. In diligence, treat “technical integration” as a cost and risk program, not a side project.
Start by clarifying the integration thesis in one sentence, then translate it into measurable outcomes. For example, “bundle add-on analytics into the platform by reducing implementation effort and enabling a unified SKU.” That implies specific requirements: shared identity and permissions, data flow from platform events into analytics, entitlements that match packaging, and a support model that does not require custom work per customer. If those requirements are not feasible, the thesis must be staged and the financial model should reflect the stage gates.
Distinguish between three integration goals, because each implies different depth and timeline. Commercial integration: shared sales motion and bundled packaging. Experience integration: unified login and consistent admin concepts. Platform integration: shared data plane and shared operating tooling. Many deals can win with commercial and experience integration first and platform integration later, but only if the operating model explicitly supports that sequencing and prevents “integration requests” from becoming an unbounded backlog.
Product integration diligence should start from the customer journey. Pick two high-value workflows the combined product is meant to improve and map the seams: mismatched permissions, duplicate configuration, inconsistent terminology, and data latency that makes “integrated insights” unreliable. Each seam corresponds to scoped work that must be staffed and sequenced. Also define what happens to existing customers of the add-on: do they migrate into the platform experience, or do they remain on a separate path with incremental cross-sell? The answer changes support load and roadmap priorities.
Technical integration diligence should start from platform primitives. Identity: SSO, SCIM, role mapping, audit logs. Data: entity identifiers, event models, lineage. Operations: monitoring conventions, paging, incident logging, release governance. When primitives differ, integration becomes a platform program, not just glue code. A practical early deliverable is shared tenant identifiers and a consistent way to correlate events and incidents across systems; without that, customer support cannot see the “whole story” during outages or escalations.
A common trap is attempting deep technical consolidation before operational maturity is aligned. If the add-on has a manual release process or weak testing, integrating it tightly can import risk into the platform. In that case, start with federation: keep runtimes separate, connect via APIs and events, unify identity and support visibility, and harden the add-on before deeper consolidation. Federation can still unlock commercial value if packaging and onboarding are well designed.
Do not underestimate entitlements and billing. When the platform and add-on have different pricing models, a bundle can require product work: metering, feature flags, license enforcement, and a clean admin experience for who is entitled to what. If entitlements are handled manually, support cost increases and renewals become negotiation-heavy. Underwrite whether the combined offering can be enforced automatically and audited, especially if enterprise procurement requires clear entitlement evidence.
Govern integration is like a product. Create a single intake for integration requests, require each request to state the customer impact and the tradeoff, and keep an explicit “integration debt” register for shortcuts taken during the first releases. Without this, teams accumulate one-off connectors, bespoke mappings, and special-case entitlements that feel small individually but become a permanent maintenance burden. A good signal is a monthly review that retires debt items and measures integration health through support tickets, incident links, and adoption over the quarter.
Finally, define success at three levels. Customer success: adoption of the combined workflow and reduced onboarding friction. Operational success: incident and escalation rates that do not rise with “double stack” complexity. Economic success: incremental gross margin of bundled deals after integration costs. Without these, integration becomes perpetual activity without measurable return.
13.3 Platform Strategy: When to Consolidate vs Keep Products Separate
Platform strategy is where integration decisions become long-lived. Many software portfolios begin with multiple products, multiple codebases, and multiple segments. Over time, leadership faces a choice: consolidate into a single platform, or keep products separate and integrate at the seams. Both can be correct. The wrong move is committing to consolidation without a clear value case and without recognizing migration and disruption risk.
Use a decision framework built around five questions. Customer value: will consolidation materially improve outcomes or reduce friction for target segments? Commercial value: will it improve win rates, pricing power, or expansion? Operational value: will it reduce incidents, support burden, and duplicated engineering? Feasibility: can it be executed with available talent without destabilizing the business? Timing: does the holding period allow benefits to show up before the program becomes a sunk cost?
Consolidation is most justified when customer workflows truly span products and when the portfolio is already paying a large “platform tax”: multiple identity systems, multiple permission models, multiple data models, and multiple reliability programs. Keeping products separate is often right when products serve distinct personas, when switching costs are high, or when one product is still evolving rapidly. In those cases, federation—shared identity and consistent governance, with selective data and UI integration—often delivers most of the benefit without full migration risk.
Distinguish three levels of “platform.” Commercial platform: unified packaging and account plans. Experience platform: unified login, navigation, and admin concepts. Technical platform: shared services and data plane. Many portfolios can become a strong commercial and experience platform without consolidating codebases, which can be more achievable within a PE time horizon. The key is to avoid pretending that “single UI” equals “single platform” if the operational and data seams remain unresolved.
If you do consolidate, avoid “big bang” programs. Consolidation should be a sequence of reversible steps. Standardize primitives first (identity, audit logging, billing/entitlements, observability), then integrate data at the model level for trustworthy cross-product reporting, then consider deeper runtime consolidation only where it eliminates real duplication. Sequence migrations by segment: new customers first, then legacy cohorts with more edge cases. Underwrite whether leadership can protect platform work from constant feature escalations, because consolidation always competes with revenue demands.
Also underwrite the migration experience explicitly. Customer migrations require data portability, configuration mapping, retraining, and support capacity. If the company cannot migrate customers predictably, consolidation becomes a churn risk rather than a synergy. A practical diligence question is: “What percentage of customers could we migrate in a quarter without materially increasing the support backlog?” If the answer is unknown, plan to start with pilots and invest in migration tooling before scaling the program.
Define what “done” means within the holding period, such as unified identity and admin, a shared reporting layer, and one or two integrated workflows that materially reduce onboarding effort. A platform does not need to become a single codebase to create value, but it does need a clear target state, ownership, and measurement to avoid becoming a permanent initiative.
13.4 Templates: Integration Risk Matrix, Day 1/day 100 Tech Plan
Integration succeeds when it is managed like underwriting: clear dependencies, explicit owners, measurable outcomes, and realistic sequencing. The templates below are intentionally lightweight so they can be used inside a deal process.
Integration risk matrix template: For each major risk, capture these fields as a short bullet list.
- Integration area: identity, data, runtime, CI/CD, observability, billing/entitlements, security/compliance, support operations.
- Dependency: what the integration relies on and who controls it.
- Failure mode: what could go wrong in customer terms.
- Impact: revenue at risk, customer experience risk, operational cost impact.
- Likelihood: high/medium/low based on evidence.
- Owner: accountable leader and delivery team.
- Mitigation: the smallest action that materially reduces risk.
- Timing: when mitigation must be complete relative to Day 1, renewals, or TSA exit.
- Proof: what evidence will confirm the risk is addressed.
Day 1 technology plan template: Day 1 is about business continuity and trust. Assign owners and confirm each item has a verification step.
- Access continuity: employee identity, production access, and support tooling function without interruption.
- Security baseline: MFA for privileged access, break-glass procedure, and logging of admin actions.
- Monitoring continuity: dashboards and alerting for core workflows are active; on-call coverage is defined.
- Incident communications: customer communication path is clear, including status page ownership if applicable.
- Data continuity: critical pipelines and reporting refresh schedules are stable; known data issues are documented.
- Billing continuity: renewals and invoicing can proceed; entitlement exceptions are logged.
- TSA governance: TSA dependencies have owners, service expectations, and escalation paths.
Day 100 technology plan template: Day 100 is about stabilization and measurable momentum toward the integration thesis.
- Dependency burn-down: exit or harden the top TSA or cross-product dependencies; publish an exit timeline with proofs.
- Unified visibility: tenant-level monitoring, incident logging, and release tracking operate in a single view.
- Security uplift: vulnerability remediation cadence, access reviews, secrets hygiene, and an audit evidence plan.
- Support reduction: ship fixes for the top ticket drivers tied to integration seams.
- Data governance: standardize metric definitions and lineage for cross-product reporting.
- Integration milestones: deliver the minimum viable customer-facing integration that unlocks the thesis, then measure adoption.
- Cost controls: establish cloud and tool cost attribution; reduce duplication where safe.
- Operating cadence: run a weekly integration forum with decision rights, a change log, and explicit tradeoffs.
Integration readiness diligence is ultimately about preventing self-inflicted damage. Carve-outs fail when TSAs are vague and exit work is underestimated. Add-ons fail when technical integration is confused with customer value. Platforms fail when consolidation becomes an unbounded program. Keep integration grounded in outcomes, evidence, and feasible sequencing, and the deal’s strategic intent can be executed without breaking what customers already trust.
