4. What good looks like in IT due diligence

The bidder went into final round confident. The seller had commissioned a reputable tech diligence report. Sixty pages, mostly green. The headline: “modern stack, scalable cloud, no major risks.”

The investment committee model assumed $14M of year-one EBITDA uplift from pricing discipline and procurement savings, starting in quarter two. The integration narrative was simple: “connect systems, consolidate vendors, and rationalize the rest later.”

Week eight after signing, the integration lead asked one question: “Where does order-to-cash actually run?”

It wasn’t the CRM. It was a heavily customized ERP with pricing logic embedded in hundreds of stored procedures, a batch interface layer nobody had documented, and one engineer who “knew how it all worked.” To connect the target into the buyer’s environment, security required MFA, device posture controls, centralized logging, and privileged access tooling the target didn’t have. Day-1 still happened. Value didn’t. The first 100 days became a stabilization program and the synergy clock slipped two quarters.

The failure wasn’t that diligence missed a technical detail. It missed the only thing that matters in a deal: what you can safely commit to, by when, and at what cost.

The primary decision is this: do you define “good” IT due diligence as coverage (a tour of the stack), or as underwriting (a set of decisions that change price, timing, and Day-1 posture)? Coverage feels comprehensive. Underwriting changes outcomes.

Define “good” in deal terms

Good IT due diligence answers five deal questions with evidence attached.

1. What gates the value in the model? (and when do those gates open)
2. What must not break on Day-1? (and what fails first when you’re wrong)
3. What one-time cash is mandatory? (to operate safely and execute the plan)
4. What is true run-rate IT cost? (normalized for the operating model you will impose)
5. Who will execute the first 100 days? (and what happens if key people leave)

If diligence can’t answer those five, you don’t have a diligence product. You have a report.

The five artifacts that prove you have “good” diligence

You can grade a diligence workstream in 30 minutes by asking for five artifacts. Each one is decision-shaped. Each one moves either price, timing, or risk.

1) A one-page “value gates” view

This is the opposite of an application inventory. It is a short list of the 3–5 technology conditions that must be true to deliver the thesis on the model’s timeline.

What good looks like

• Each gate is tied to a value lever and a date (“pricing discipline in Q2 requires customer/product master + a quoting workflow we can control by Day 60”).
• Each gate has current-state evidence, an owner, and a realistic path to “open” the gate.
• The page includes a fallback plan (“if the gate won’t open by Day 60, we narrow scope to the top 50 accounts and build a manual bridge”).

What goes wrong

• Gates are phrased as opinions (“data maturity is strong”) instead of conditions you can test.
• Gates are missing the hard ones: identity, network boundaries, data definitions, and reporting ownership.
• Timing is implied, not explicit, so the deal model keeps its original ramp by default.

Decision trigger: If the deal’s top 2–3 value levers depend on gates you cannot validate with evidence in diligence, you should assume the timing is wrong and move it in the model.

2) A run-rate IT cost bridge (budget → actual → normalized)

Most diligence packs include an IT budget. That is not run-rate. Good diligence produces a bridge that explains what changes at close and what the buyer will add.

What good looks like

• A bridge from IT budget to actual cash spend (including “non-IT” contractors who keep systems running).
• Cloud spend shown as a trend with known step-ups (credits expiring, renewals, reserved capacity ending).
• A “normalized” run-rate that includes the buyer’s non-negotiables (security tooling, service desk model, monitoring, licensing true-ups).

What goes wrong

• “Run-rate IT cost” equals the IT cost center, excluding shadow IT, contractors, and shared services.
• Cloud costs are taken from one invoice, not from a 6–12 month export with anomalies explained.
• Savings are listed without offsets (parallel run, migration tooling, security uplift, training).

Decision trigger: If you can’t produce a bridge from budget to normalized run-rate, assume there is at least one material delta hiding in contractors, cloud, or shared services. Protect the model and the purchase agreement accordingly.

3) A Day-1 dependency and failure-mode map

Day-1 is not “systems are up.” Day-1 is “the business can operate and close the books.” Good diligence makes dependencies explicit and tests the failure modes.

What good looks like

• A plain-English Day-1 definition for this business: orders, cash, payroll, customer support, regulatory reporting.
• A dependency map that names where identity, network, email, ERP access, and critical data feeds sit (seller vs buyer vs third party).
• A short list of “if this fails, here is the fallback” actions with owners (not a generic cutover plan).

What goes wrong

• Day-1 is treated as a schedule, not as a readiness gate.
• Identity and access are waved away (“we’ll sort SSO post-close”), then become the gating item for everything.
• The team learns about undocumented interfaces when they break during the first month-end close.

Decision trigger: If Day-1 depends on services the buyer will not control on Day 1 (identity, connectivity, ERP access, data feeds), treat this as a separation/integration design decision now, not a post-close task.

4) A complexity heatmap that explains what makes the deal hard

Complexity is not the number of applications. It is the number of hard couplings and the amount of change you must push through the business in the first year.

What good looks like

• A view of core system boundaries (ERP, CRM/CPQ, WMS, data platform) and how tightly they are coupled.
• A list of the top integration points that would break value capture if they fail, with real ownership (“owned by vendor X” is an owner).
• A clear call on what not to do in the first 100 days (for example: “do not attempt ERP consolidation as a year-one dependency”).

What goes wrong

• The heatmap is a generic “maturity assessment” without any linkage to the integration/separation plan.
• Integrations are treated as arrows on a slide, not as code, contracts, and people.
• The team commits to platform consolidation because it “feels clean,” then spends the first year in parallel run.

Decision trigger: If critical workflows rely on undocumented integrations and a small number of people, treat it as a timing risk, not just a technical risk. Retention and sequencing become mandatory.

5) A capability plan for execution (not an org chart)

In diligence, “team is strong” is meaningless. Good diligence names the few roles and people that determine whether the plan is executable.

What good looks like

• Key-person dependencies are explicit (who knows the ERP config, who owns data definitions, who can change security posture).
• A Day-1/Day-100 resourcing plan: what must be in place by close vs what can be hired post-close.
• A retention and backfill plan priced into one-time cash if needed.

What goes wrong

• The plan assumes the current team will “just integrate” on top of running the business.
• Knowledge sits with one engineer or one vendor, and nobody prices the risk of losing it.
• The buyer discovers after close that the target’s best people are not staying.

Decision trigger: If 2–3 individuals hold the operational knowledge for critical systems, retention is not optional. Price it and put it into the deal plan.

What “good” diligence feels like in practice

Good diligence moves fast, but it does not move randomly. It has an explicit sequence that protects the model and creates options.

Week 1: Force the point of view early

The goal is not certainty. It is an early, defensible call on the gates that could change the deal.

• Run a 60–90 minute value gates working session (deal lead + finance + tech lead).
• Ask for raw artifacts on day one: cloud billing export, incident history, close calendar, contract list, system diagrams.
• Produce a first cut of the five artifacts above, even if incomplete.

Week 2: Prove or disprove the gates with evidence

This is where “green” becomes real.

• Validate the top gates through evidence and owner interviews, not through presentations.
• Build the run-rate bridge and identify the offsets that will show up post-close.
• Write the Day-1 dependency map in plain English and pressure-test failure modes.

Week 3: Turn diligence into a plan you can staff

Now diligence becomes executable.

• Translate findings into model changes: timing, one-time cash, run-rate.
• Lock the first 100 days as a set of decisions (what you will not do is as important as what you will do).
• Confirm the capability plan: named owners, retention, backfill, and external support needs.

In fast deals you may only get two weeks. The sequence still holds. You just compress the depth, not the logic.

The quickest self-check: did diligence change anything?

If you want a blunt test of whether you got “good” diligence, ask three questions:

1. What did we change in the model because of IT? (timing, one-time cash, run-rate)
2. What did we change in Day-1 posture because of IT? (connected vs separate, TSA dependence, security constraints)
3. What did we decide not to do in the first 100 days because of IT? (explicit deferrals)

If the answer to all three is “nothing,” diligence didn’t underwrite the deal. It documented it.

What to do in the next two weeks

If you’re a buyer in diligence:

1. Ask for the five artifacts, not “the report.” Don’t let diligence hide behind volume.
2. Anchor on gates and dates. Write the model’s assumed value gates and make diligence prove them.
3. Demand raw evidence early. Cloud exports, incident history, close calendar, and contracts beat slide decks every time.
4. Build the run-rate bridge with finance. If IT can’t reconcile to cash and normalize it, your model is exposed.
5. Price the people risk. Put retention and backfill into one-time cash when knowledge is concentrated.

If you’re preparing a sale process:

1. Pre-build an evidence pack. Give bidders self-serve proof for the claims you want to make.
2. Write your own run-rate bridge. If you don’t, buyers will, and it will happen late.
3. Be honest about the gates. The cleanest processes are the ones where bidders can price reality early and move faster.

“Good” IT due diligence is not a higher score on a maturity assessment. It is a shorter list of decisions, backed by evidence, that protects Day-1 and makes the value timing real.