A data room is not a description of a company. It is an argument. Every folder in it was assembled by people whose job was to close the deal, and what made it inside is what survived that filter. The architecture diagram is the one an engineer redrew for the process, not the one taped to the wall. The cost model reflects the accounting the seller chose, not the cash the buyer will spend. None of this is fraud. It is curation, and curation is the whole point.
The things that actually predict what an acquisition will cost to integrate are, by construction, the things a data room is built not to show: how the software was really built, who holds the system in their head, what it costs to run once you strip out the seller's accounting choices, and how tightly the whole thing is wired to itself. I have never signed a deal as a principal, and I am not going to pretend I have run one from the buyer's chair. But I have sat on both sides of the exercise technology diligence most resembles. At a fintech whose 1,500-plus financial-institution partners run us through security and engineering review constantly, I live on the answering side; and I run the third-party risk program that puts other systems through the same microscope. Tech diligence runs on those mechanics, and from that seat the pattern is consistent: financial diligence gets the valuation approximately right, and technology diligence gets the integration bill wrong by a wide margin, because it stops at the artifacts.
Pre-signing technology diligence is not a document review. It is the work of quantifying four things the data room will not quantify for you — technical debt, run cost, architecture risk, and key-person risk — and asking the handful of questions that turn each from a vibe into a number the deal model can absorb before signing, rather than a surprise the CIO inherits in year one.
Read the artifacts as claims, not facts
The first discipline is to treat everything in the room as a claim with an owner, and then to go find where the claim is actually settled. Architecture is settled in the codebase and the incident history, not in the diagram. "We deploy continuously" is settled in the deployment logs, and "the platform scales horizontally" is settled by asking what broke the last time it actually had to.
So the diligence that works happens in three places the folder tree cannot reach. The management meetings, where you ask the engineers questions the deal team did not prepare them for and watch who answers. Read-only access to the systems themselves — the cloud console, the CI/CD history, the ticket backlog, the on-call schedule — which tells you more in an afternoon than the whole data room does. And the incident history, unredacted, because how a team wrote up its worst week tells you whether the culture can be integrated or will scatter on contact. If the seller will not grant read-only access under NDA to a named technical reviewer, that refusal is itself a finding, and usually the most valuable one you will get for free.
Technical debt is interest, not a backlog
The most common mistake in technology diligence is to ask for the backlog and count the tickets. A backlog is a wish list; technical debt is not the backlog. It is the interest the company pays every quarter for the shortcuts already taken — the fraction of engineering capacity that goes to keeping the existing thing alive instead of building the next thing. That interest is what you are actually buying, and it does not appear as a line item anywhere.
You can size it without reading a single line of code, because the delivery signals give it away. I look at the four DORA metrics from the Accelerate research — deployment frequency, lead time for changes, change failure rate, and time to restore service — not as a maturity badge but as a debt gauge. A team that deploys monthly, takes weeks to ship a change, fails a third of its deploys, and measures recovery in days is not lazy; it is servicing a heavy debt, and that servicing cost transfers to you at close. The single most predictive question I ask is blunt: what percentage of engineering time last quarter went to maintenance, incidents, and toil versus new capability? If nobody can answer it, that is the answer.
The signals that consistently front-run a painful integration:
- A change-failure rate the team has quietly normalized. When "roll it back and try again Monday" is the culture, the debt lives in the deployment path, and every integration change you make will inherit that same failure rate.
- A test suite people route around. Ask whether engineers trust the tests. If the honest answer is that they merge past red builds, you are buying manual regression risk that scales with every change you make post-close.
- A single senior engineer who reviews everything. A bottleneck at code review is key-person risk wearing a process costume, and it caps how fast the combined org can move.
- Dependencies pinned years back. A runtime or framework frozen on an end-of-life version is deferred work with a hard deadline, and the deadline is usually a security or compliance one you will own.
Run cost is not the number on the P&L
The cost of running the target's technology shows up on the income statement as a number, and that number is almost never the number you will pay. It has been shaped by accounting choices that are perfectly legal and specifically unhelpful to a buyer trying to model the future. I am not your controller, and the accounting treatment is the CFO's and the auditor's to settle — but the shape of it matters to anyone estimating post-close cash, so it is worth knowing where the gaps hide.
Three reconstructions recover the real run rate. First, strip the transfer effects: the reserved instances, committed-use discounts, and enterprise agreements that made the cloud bill look lean are frequently non-transferable or reset on a change of control, so the standalone bill can step up the day after close. Second, unwind the allocations — shared parent-company services, a founder-CTO drawing a below-market salary — because a carve-out inherits none of them. Third, and the one technologists routinely miss, understand how much engineering the target capitalized. Under ASC 350-40, software built for internal use can be capitalized during the development stage rather than expensed, which flatters current EBITDA and moves real, recurring cash cost off the income statement. A target that capitalizes aggressively can show healthy margins while spending heavily to stand still. The way to see through it is to rebuild cost bottom-up as a unit economic — cost to serve one customer or one transaction — using a framework like TBM to map spend back to services. If the seller cannot produce a unit cost, you have learned something important about how they run the business.
Architecture risk is the integration bill you pay in year one
Architecture risk is the category most likely to be underpriced, because it stays invisible until you try to connect the acquired system to yours. The question is not whether the architecture is good in the abstract. It is: how many things are wired to how many other things, and how long will you have to run both stacks in parallel before you can cut over? Every month of parallel run is a month of double infrastructure, double on-call, and a data-sync bridge that someone has to build and own. That duration, far more than any diagram, is the integration budget.
The findings that extend the parallel-run clock are consistent. One database that every service reaches into directly, so nothing can move without moving everything. Business logic living in stored procedures or a vendor's low-code platform rather than in code you can read and port. Undocumented data flows that only reveal themselves when you turn one system off and something three hops away breaks. A hard dependency on a single cloud provider's proprietary services, where "we're on AWS" quietly means welded to fifteen managed services with no abstraction layer. I categorize the application portfolio the way Gartner's TIME model does — tolerate, invest, migrate, eliminate — before signing, because the migrate and eliminate columns are where the post-close labor lives, and a seller's roadmap never labels anything "eliminate." Contract-level lock-in belongs in the same review: a core vendor whose exit terms are punitive is an integration constraint priced into the deal whether or not anyone modeled it.
Key-person risk is the finding the data room can't fake
Every other category can be dressed up. Diagrams get redrawn, metrics start from a flattering quarter, costs get reallocated. Key-person risk is the one that resists staging, because it lives in people's heads and reveals itself the moment you ask the right question in the room. In a lot of mid-market targets the architecture is not in the wiki. It is in one or two people, and if either of them takes the earn-out and leaves, you did not buy a system — you bought a codebase you cannot safely change.
The test is simple and I run it every time. Ask the team to walk you through the worst incident of the last year, and ask it while the person who actually fixed it is not the one talking. If the room goes quiet, you have found the bus factor. Then look at the machine identities, which is where key-person risk hides in its most dangerous form. The service accounts, API keys, and automation credentials that run the business are frequently understood by exactly one engineer, undocumented and over-privileged. This is not hypothetical for me; governing non-human identity is a large part of what my team does, and when we built AgentOS we treated every agent and service credential as an identity with a named owner and a lifecycle precisely because the alternative is this failure mode. In diligence it becomes a specific question set:
- Who can deploy to production, and what happens if that person is unreachable? If the answer is one name and a personal laptop, the deployment pipeline is a key-person risk, not an asset.
- Which credentials would break the business if rotated, and does anyone know why? A credential nobody dares rotate is a credential nobody understands, and you inherit both the fear and the ignorance.
- What is documented well enough to survive the departure of its author? Runbooks, on-call playbooks, and architecture decision records are the difference between an integrable team and a retention-hostage situation.
- What is the retention plan for the two people who hold the system? If there isn't one, the integration timeline is a fiction, and the number that matters is what it costs to keep them.
Diligence for the invoice, not the exhibit
The point of all this is not to kill deals. It is to price them honestly, so the integration budget approved before signing is the one the work will actually require — instead of the overrun that surfaces in year one and gets blamed on execution. Four disciplines carry most of the weight. Insist on read-only access to the running systems, and treat a refusal as the finding it is. Quantify technical debt as the run-rate drag it is, not the backlog it pretends to be. Rebuild run cost bottom-up as a unit economic before you trust the P&L. And find the two people who hold the system before you find out the hard way that they've left.
If you have run technology diligence from either side of the table — as the acquirer's reviewer or the target answering the questions — I want to hear which question told you the most. Leave a comment: what did the data room fail to show you, and what did you learn to ask because of it?
