5. Tech DD in PE deals vs corporate deals • EL BANTLI

The same asset can look “clean” in diligence and still blow up two different deal models.

A $400M revenue services business ran a modern stack: cloud-hosted ERP, Salesforce, outsourced infrastructure, and a small internal apps team. The seller’s vendor report said “no major issues.” Two bidders read it and walked away with opposite conclusions:

A strategic buyer planned to integrate finance, identity, and procurement inside 9 months to unlock $28M of synergies and working capital improvement.
A PE sponsor planned to keep the company standalone, fund a pricing and sales productivity program, and do an add-on acquisition in year one.

Both buyers believed they were buying “good technology.” Only one of them had a plan that matched what the technology could support on the timetable the model assumed.

The primary decision is this: are you diligencing to run and improve a standalone asset (PE), or to integrate and standardize it (corporate)? If you use the wrong lens, you don’t just miss risks. You commit to the wrong clock, the wrong one-time cash, and the wrong Day-1 posture.

The deal model decides what tech DD must prove

Tech DD uses the same building blocks in both cases (apps, infra, cyber, data, org, costs). What changes is the “standard of proof” and the output shape.

In PE, the model is a hold-period operating plan. Diligence must answer:

What does it cost to run the tech you’re buying (normalized run-rate, not the budget)?
How much one-time cash is mandatory to make Day-1 and the first 12 months safe?
Does the team have the capacity to execute the value plan without breaking operations?
If you plan add-ons, what is the integration “product” you’re inheriting (identity, data, integration patterns)?

In corporate deals, the model is synergy timing through integration. Diligence must answer:

What has to be integrated, interoperable, or separated by when for the synergies to hit the P&L?
What will block connectivity (identity, network boundaries, security controls, data residency)?
What is the real one-time cost of integration (including parallel run, training, and process redesign)?
What should be left alone in year one to protect Day-1 and the customer experience?

Same fact set. Different underwriting.

Six differences that change the diligence answer

1) Time horizon: “hold period clock” vs “synergy clock”

PE teams are optimizing for value inside a finite window. Even when they invest, they need a clear path to payback inside the hold period.

Corporate teams may own the asset longer, but the integration clock is often harsher: synergies are committed early, and the business expects Day-1 continuity plus fast cross-company execution.

What changes in diligence: PE needs credible sequencing for the first 100 days and first 12 months. Corporate needs credible gating dates for integration milestones tied to synergy timing.

2) Integration intent: standalone, platform, or absorbed

Most PE deals are not “integrate everything.” They are:

Standalone operations with targeted improvements, or
A platform strategy where add-ons must plug in repeatedly.

Most corporate deals have an explicit end-state: shared identity, shared data, consolidated finance, and some level of application rationalization.

What changes in diligence: PE must underwrite repeatability (how hard is it to bolt on the next acquisition?). Corporate must underwrite compatibility (how hard is it to conform to enterprise standards?).

3) The buyer’s non-negotiables (especially security)

Corporate IT typically has hard controls: endpoint tooling, identity standards, logging, incident response, data classification, vendor risk processes. If the target can’t meet the bar, you can’t connect environments on the timeline the business assumes.

PE sponsors may tolerate temporary gaps, but only if they don’t threaten operations or the exit story. A weak security posture becomes expensive later when you’re selling to a strategic buyer or preparing for a lender audit.

What changes in diligence: corporate diligence must treat “connectivity readiness” as a first-class deliverable. PE diligence must treat “exit readiness” as a first-class deliverable.

4) Where the value comes from: cost-out vs growth vs synergies

PE value plans often combine margin expansion (pricing, procurement, SG&A) with selective tech investments (data foundations, automation) and cost takeout.

Corporate value is often synergy-led: consolidate vendors, unify customer coverage, harmonize pricing, standardize processes, migrate to shared platforms.

What changes in diligence: PE diligence must separate mandatory spend (to keep the business stable) from value unlock spend (that accelerates the plan). Corporate diligence must separate “minimum integration to unlock synergies” from “full standardization” that can wait.

5) Governance and decision speed

PE governance can be fast and concentrated (deal partner + operating partner + CEO). Corporate governance is often broader (CIO org, security, architecture review boards, shared services owners). Decision rights and funding can be slower even with strong intent.

What changes in diligence: PE diligence should pressure-test whether the management team can execute with tight oversight. Corporate diligence should pressure-test whether the buyer can actually staff and govern the integration it is assuming.

6) Resourcing model: who does the work

PE teams frequently rely on a small internal tech team plus external support (interims, advisors, MSPs). Corporate teams often assume internal IT will absorb the work—then discover that internal capacity is already booked.

What changes in diligence: PE diligence must underwrite the cost and availability of external execution capacity. Corporate diligence must underwrite the opportunity cost and constraints of internal execution.

What goes wrong when you apply the wrong template

Pattern 1: PE runs “corporate-style” diligence and misses the economics

You get deep architecture maps, “target state” opinions, and a long list of modernization ideas. You do not get the two bridges that move returns:

budget → actuals → normalized run-rate IT cost
findings → mandatory one-time cash → Day-100 plan

The deal closes. The sponsor then discovers that the business is held together by contractors, cloud credits expire 60 days post-close, and the IT team has no bandwidth to run the value plan. The first year becomes stabilization. The model assumed value capture.

Pattern 2: Corporate runs “PE-style” diligence and misses integration gating items

The diligence team underwrites the asset as standalone: costs, risks, and “good enough” maturity. Then the buyer tries to connect networks, unify identity, and integrate finance. Security and data controls block it. The business starts running shadow integrations to hit synergy targets. Incidents rise. Synergies slip.

Pattern 3: Everyone treats vendor DD as a substitute for underwriting execution

Vendor reports are useful. They rarely answer the buyer’s question: “What do we have to do, with our standards and our timeline, to make this work?”

If diligence outputs aren’t decision-shaped for the buyer type, you don’t have diligence. You have documentation.

PE tech DD: underwrite the machine you’re buying

If you’re a sponsor, tech DD is not “is the stack modern?” It’s “can this business execute a hold-period plan without tech becoming the speed limit?”

1) Normalize run-rate IT cost (and identify the offsets)

Start with a bridge. Budget numbers lie in predictable ways:

contractors booked outside IT (critical integrations, reporting, security ops)
cloud spend temporarily low due to credits or one-time migrations
“project” work that is actually steady-state (patching, data fixes, interface support)
corporate allocations that will disappear and be replaced with new costs post-close

Decision trigger: If you can’t explain 90%+ of IT spend with evidence (invoices, payroll, contracts, cloud exports), assume the number will move after close. Price the uncertainty or build a downside case.

2) Test change capacity, not just system health

In PE, the biggest tech risk is often not technical debt. It’s capacity debt.

Diligence should answer:

Who owns the core systems day to day (and what happens if they leave)?
How many “A players” are doing two jobs (run + change)?
What is the realistic throughput for change while keeping the business stable?

Decision trigger: If fewer than 3–4 people can explain the integration map and the monthly close process, retention and backfill are mandatory one-time costs, not nice-to-haves.

3) Tie the value plan to a few technology gates

PE value plans often depend on small, boring tech conditions:

a usable customer and product master for pricing discipline
clean order-to-cash data for sales coverage and churn control
basic observability so you can cut cost without outages
a reporting layer that can track KPI movement weekly

Don’t start with “modernize.” Start with gates and dates.

If/then triggers:

If the plan assumes revenue uplift inside 2–3 quarters, diligence must prove the data foundations exist (or quantify the cash and time to build them).
If you plan major cost-out in IT, diligence must prove the operating model can run with fewer people (documentation, automation, vendor SLAs).

4) Underwrite add-on readiness (if the plan includes M&A)

If your thesis includes add-ons, the diligence question changes from “is the target good?” to “is the target a platform?”

Focus on repeatability:

identity strategy (how quickly can you onboard users and enforce controls?)
integration patterns (APIs, middleware, file drops, tribal scripts)
data model and reporting (how fast can you get consolidated KPI reporting?)
shared services boundaries (what will you centralize across the portfolio?)

Decision trigger: If you can’t onboard an add-on into consolidated reporting inside 60–90 days without heroics, you don’t have a platform. You have a standalone asset with M&A aspirations.

5) Protect the exit story early

Most sponsors don’t buy to own forever. Exit diligence will happen, and tech will be re-underwritten.

PE diligence should flag what will get priced at exit:

cyber posture (logging, endpoint, incident response, vulnerability management)
IP ownership and open-source risk (especially in software businesses)
auditability (close process, controls, access, data lineage)

Decision trigger: If you expect a strategic buyer, underwrite their security and compliance bar now. It is cheaper to build toward it during the hold period than to scramble when you’re selling.

The PE diligence output that actually helps

Aim for a PE-focused “value brief” that an IC and operating partner can act on:

Normalized run-rate IT cost bridge (with the big drivers and offsets)
Mandatory one-time cash for Day-1 stability and the first 100 days
12-month value gates tied to the value plan (with dates and owners)
Capability plan (retain/hire/partner) to execute without breaking operations
Exit readiness risks that will affect price or timing later

Corporate tech DD: underwrite integration and synergy timing

If you’re a strategic buyer, tech DD is not “is IT decent?” It’s “can we connect and integrate on the timetable the business is committing to?”

1) Make the integration posture explicit per value lever

Corporate deals fail when “integrate” is a vibe, not a choice.

For each synergy lever, write the minimum required integration outcome:

cross-sell requires customer identity, shared account ownership rules, and quoting workflow interoperability
procurement synergies require vendor master alignment and approval flow control
working capital improvements require order, invoice, and inventory data consistency

Everything else can be a phase-two discussion.

Decision trigger: If you can’t name the minimum integration outcome for each synergy lever, you are about to overbuild the integration and still miss the synergies.

2) Start with identity, network boundaries, and data flows

These three topics determine whether you can connect environments safely:

identity and access model (SSO, privileged access, joiner/mover/leaver)
network segmentation and connectivity approach
critical data feeds and interface inventory

They are also the topics most likely to be “out of scope” in generic DD. That’s a mistake.

If/then trigger: If Day-1 requires any connectivity, diligence must treat security controls and identity as gating items, not recommendations.

3) Validate synergy gates with evidence, not statements

Corporate integration programs are full of assumptions that sound reasonable and fail in practice:

“They’re on Salesforce.” (Which instance? How customized? What data quality?)
“ERP is stable.” (How long is close? How many manual steps? What breaks?)
“Data is good.” (Good enough for what use case, by when?)

Diligence needs raw artifacts: close calendars, incident logs, cloud billing exports, interface lists, security findings. The goal is not a perfect inventory. It’s enough evidence to set the right clock.

4) Quantify one-time cash including parallel run and process work

Corporate models often undercount the “soft” costs that drive delays:

parallel run of systems during migration (licenses, support, dual operations)
training and process redesign (the work that makes a new system usable)
data cleanup (the work that makes reporting and pricing real)

Decision trigger: If integration requires changing core processes and data definitions across both companies, expect the critical path to be people and process, not technology.

5) Define the buyer’s minimum security bar for connectivity

Most corporate buyers have security controls that are not negotiable. Diligence should translate those into a small number of yes/no questions:

Can the target support your endpoint tooling?
Can you ingest logs into your SIEM with the required coverage?
Can you enforce MFA and privileged access controls for admins?
Are there regulatory constraints that prevent data movement?

If the answer is “no,” you have two choices: delay connectivity or fund remediation early. Pretending it will be solved “during integration” is how you end up with shadow IT and incident risk.

The corporate diligence output that actually helps

Aim for a corporate-focused “integration brief”:

Synergy gates and dates (what must be true to hit the committed timing)
Connectivity readiness (identity, network, security controls) and required remediation
Integration sequencing (what you will not attempt in the first 100 days)
One-time cash and parallel run costs with owners and funding assumptions
Target architecture fit (where standardization is required vs optional)

How to calibrate diligence depth: practical triggers

Use a few deal facts to decide where to go deep.

If TSA < 9–12 months (carve-out): treat identity, network, ERP access, and interface inventory as first-class diligence topics. TSA dates are not schedules; they are readiness gates.
If revenue synergies are in the first 2–3 quarters: go deep on customer master, CRM/CPQ, pricing data, and analytics definitions. Don’t waste week one mapping data centers.
If you’re buying a “platform” for add-ons: go deep on onboarding, integration patterns, and reporting consolidation. Your first add-on will be your real diligence test.
If the target runs multiple ERPs or heavily customized core systems: assume timing risk. Build a phased plan that avoids making ERP replacement a year-one dependency unless the business can tolerate it.
If security posture is below the buyer’s bar: decide explicitly whether you are delaying connectivity or funding remediation. Ambiguity becomes shadow integrations and risk.

What to do in the next two weeks

If you want diligence to actually change outcomes, run these actions on a short clock.

Write the buyer-type brief in week one (deal lead + tech lead). PE: value brief. Corporate: integration brief. If you can’t fit it on one page, you don’t yet know what matters.
Force three numbers early (finance + tech DD lead). Timing of value/synergies, mandatory one-time cash, and normalized run-rate IT cost. Put them in the model while it can still move.
Pressure-test Day-1 posture (CIO/security lead + integration lead). What must not break, what will be connected vs separate, and what controls are non-negotiable.
Name the first 100 days in terms of gates, not tasks (integration lead). “Customer master usable,” “close calendar stable,” “identity controlled,” “reporting consolidated.” Owners and dates.
Decide the resourcing model (deal team + IT leadership). PE: what you will outsource vs build, and the cost. Corporate: what internal teams will actually do the work, and what stops them.

PE and corporate deals fail for different reasons, but the mechanism is the same: the diligence output doesn’t match the model. Fix the lens early, and the rest of diligence becomes faster and more decisive.