In 2019, a few weeks of personal code and data investigation at First American Financial killed a roughly one hundred million dollar acquisition before it cleared the boardroom. The target had presented well. The data room was clean, the architecture diagrams looked credible, the security questionnaire was complete, the capability claims aligned to the deal thesis. The standard process would have moved to confirmation. Instead, the technical review went directly into the production codebase and the underlying database, and surfaced a gap between the presentation and the reality material enough to change the recommendation to the board. The savings relative to what the platform would have actually delivered post-close, before counting the integration cost First American was already absorbing on its existing portfolio, were on the order of one hundred and twenty million dollars.
That outcome is the entire argument for taking M&A technical due diligence seriously as a discipline separate from routine architecture review. The work that gets a deal repriced or killed is not the work that produces a tidy risk summary. It is the work of reading code, querying databases, and interviewing engineers under conditions a buyer rarely controls cleanly, against a clock the seller is pushing, with a decision at the end the buyer cannot reverse once the wire transfer clears.
timeline title M&A Technical Due Diligence, From LOI to Board Decision LOI signed : Access negotiation begins : Diligence advisor engaged Week 1 : Data room review : Architecture document baseline : First engineering interviews Week 2-3 : Code-level and data-level investigation : Production database queries : Adversarial security review Red flag found : Reprice signal or walk signal triage : Findings escalated to deal team Week 3-4 : Findings synthesis : Quantified remediation costs : Board recommendation Board decision : Proceed, reprice, or walk : Walk away, the 120M call
How the First American walk-away actually happened
The headline number compresses the story too neatly. What actually happened inside First American Financial was several weeks of work that looked, from the outside, like standard diligence. Document review, architecture walkthroughs with the target’s engineering leadership, interviews with the technical team, the usual rhythm of a buy-side process. The difference was a deliberate decision early to not accept the data room as the basis for the recommendation. The data room was the seller’s curated narrative. The recommendation had to come from the technical reality the seller had not curated.
That meant asking for access most diligence processes do not ask for. Direct read access to the production codebase, not summaries. Direct query access to the database, not aggregate reports. Conversations with individual engineers, conducted separately from the technical leadership’s narrative. The seller resisted some of this, and the negotiation over access was its own workstream. A buyer that does not push for code and data access early loses the only leverage they have to test what the data room is asserting.
What surfaced was a familiar pattern in modern clothing. The architecture diagrams described a service-oriented platform. The production reality was a small number of monolithic applications with service-shaped wrappers on top, sitting on a database whose schema had drifted significantly from what the documentation showed. Data quality at the row level did not match what the aggregate reports claimed. The same record was represented in incompatible ways across systems that were supposed to be the single source of truth. Operational knowledge of how the most important batch jobs ran was concentrated in two engineers, neither of whom was structurally locked in to stay through an integration period. The capability claims that justified a meaningful portion of the valuation depended on data assets that, on inspection, were not the assets being described.
None of that was concealed in a deceptive sense. The information was sitting in the code and the database the entire time. It was hidden in the sense that documentation-level review does not surface it. The recommendation to walk was straightforward once the picture was complete. The harder part was earlier, in the choice to spend the time and political capital to go past the data room in the first place.
The broader context mattered. First American had acquired more than eighty companies in the prior decade and was carrying roughly seven hundred software applications across fifteen-plus subsidiaries. The enterprise architecture team I was part of spent months auditing that estate. That work meant I had already seen, at full scale, what acquired technology looks like once the deal closes and the consolidation work begins. The cost is almost never on the financial model the deal team built.
M&A diligence is a different animal than routine architecture review
Most technologists who get pulled into an M&A diligence process apply the playbook they use for internal architecture review. That playbook produces a thorough document, a list of recommended improvements, and a multi-quarter remediation roadmap. It is the wrong artifact. M&A diligence has three structural properties that change the work entirely.
The first is the compressed timeline. A target’s CTO can take eighteen months to remediate technical debt. A buy-side diligence advisor has two to four weeks against a closing calendar that does not move. You are not building a complete picture of the system. You are testing the specific claims that justify the deal thesis, finding the discrepancies that materially affect price or risk, and producing a recommendation the deal team can act on inside the window they have.
The second is adversarial access. Routine architecture review happens inside an organization that wants the work to succeed. M&A diligence happens across organizational lines, under NDA, against a counterparty not incentivized to surface anything that does not have to be surfaced. Document requests get partial fulfillment. Code access gets negotiated and limited. Engineer interviews happen with the target’s technical leadership in the room. The buyer’s advisor has to read what is in front of them with the awareness that the curation is itself a signal. The things the seller shows easily and the things the seller resists are both data.
The third is the irreversible decision at the end. An internal review that recommends a remediation plan can be revised next quarter. An M&A diligence recommendation runs into a wire transfer. Once the deal closes the buyer owns the technical debt, the key-person risk, the security exposure, and the integration cost. The walk signal has to be identified before the close, because there is no walk option after it. A diligence process that ends with “some issues, broadly acceptable” is often worse than no diligence at all. It gives the deal team cover to proceed without forcing the hard conversation the findings should have triggered.
The five things acquirers actually probe first
A buy-side diligence process that produces real findings concentrates the available time on five areas, in roughly this order of leverage.
Codebase health, evaluated by reading it. Not the summary, not the metrics dashboard the target produces, the code itself. What patterns were used, where the duct tape sits, how recent the meaningful changes are, what the test coverage looks like in the parts of the system that handle money or customer data. This is work a generalist diligence firm cannot do well, because the reading happens at speed and the judgment about what matters requires having operated systems at this scale. A target whose codebase the buyer’s advisor can read with confidence is a different asset than one that requires three weeks of warm-up before anything meaningful can be said about it.
Architecture coherence, evaluated against the production reality. The architecture diagram in the data room is a hypothesis. The diligence work is to test whether the production system actually matches it. Are the services described as services actually services, or are they monoliths with REST endpoints bolted on. Does the data flow described in the documentation match what the database queries show. Are the integrations on the map the integrations that actually run, or have three more been added that nobody updated the diagram for. The First American walk-away turned on this question more than any other. The diagrams were professional and clean. The production system was something else.
Team-versus-code coupling, often called bus factor. Every engineering organization has individuals whose departure would create operational disruption. In most acquisition targets that risk is concentrated in one or two people who hold critical institutional knowledge in their heads. The diligence question is whether those individuals will stay through the integration period. The acquisition changes their equity position, their reporting structure, and their sense of ownership. If they probably will not stay, and the remaining team cannot operate the systems without them, the buyer has acquired a platform with a hidden dependency the purchase price did not account for.
Data quality and ownership, especially when the deal thesis depends on the data. Any platform putting AI or data capabilities at the center of its value proposition should expect the diligence team to dig past the model and into the data underneath it. What is the AI actually operating on. Where did that data come from. What contractual rights attach to it. Is it clean enough at the row level to support the capability being claimed, or is it clean only at the aggregate report level. A capability claim resting on a weak data foundation does not survive a serious review. The First American target’s data quality at the row level, on inspection, did not match what the aggregate reports asserted. That single discovery was enough to recompute the value of the acquisition.
Security and compliance debt, evaluated as future liability. Any material vulnerability in the target’s codebase becomes the buyer’s liability the moment the deal closes. The breach risk transfers to the combined entity, with the buyer’s customer base, regulatory obligations, and customer trust now in scope. Unpatched dependencies, weak authentication, inadequate encryption, undisclosed past incidents, all of it is discoverable if the review is structured to find it. In regulated industries the compounding is worse, because compliance obligations transfer with the asset.
The signals that walk a deal versus the signals that price it down
The most useful skill in M&A diligence is distinguishing reprice signals from walk signals. The two look similar from a distance and require different responses, and the diligence advisor’s job is to be clear about which is which.
Reprice signals are quantifiable issues with bounded remediation cost. Technical debt that can be inventoried and priced. Security gaps that can be closed in known timeframes. Integration work that can be modeled. Documentation deficits addressable by a team transition plan. These findings do not end the deal. They reshape it. The right output is a quantified deduction from the purchase price, a structured escrow, a reps and warranties insurance term, or a holdback to fund the post-close remediation work. The deal still happens. The economics shift to reflect the work the buyer now knows they will inherit.
Walk signals are findings that change the nature of the asset. The data does not match the capability claims, and the capability is what is being acquired. The architecture cannot scale into the growth thesis without a rewrite that consumes the expected return. The operational knowledge sits in one or two people who will not stay, and the systems cannot be operated without them. The AI capability that justifies the premium is a wrapper over a public API any developer with credentials could replicate. These are not findings the deal economics absorb. They say the asset is not the asset the buyer thought they were buying. The recommendation is to walk, and the discipline is to make that recommendation cleanly without trying to bridge findings that should not be bridged.
The First American target had walk signals, not reprice signals. The data quality, the operational concentration, and the capability claims were not issues the purchase price could be adjusted around. The asset was structurally different from what the deal thesis assumed.
What a seller can do, briefly
This post is written for the acquirer’s chair, but a note for the other side. Sellers who do not want their platform to look like the First American target should not start preparation when the banker engagement letter is signed. The window to fix anything closes by then. The longer-runway approach, including a twelve to eighteen month preparation timeline, is covered in technology exit preparation. The buyer’s diligence team will surface what is there. The only question is whether what is there has been remediated before they look, or whether it gets priced into their bid.
The diligence is the highest-leverage step in the transaction
Most of the work in an acquisition produces marginal improvements in the deal. Negotiating the purchase price up or down by a few percentage points. Tightening contract terms. Adjusting the earnout. Technical due diligence is in a different category. It is the only workstream that can change the recommendation from proceed to walk on the basis of findings the deal team would not otherwise see.
The diligence process at First American that produced the walk recommendation was not exotic work. It was the standard playbook for code-level, data-level, and team-level review, applied with discipline against a target whose presentation was tighter than its reality. That playbook is the M&A advisory work I run for buy-side clients, and the technical assessment framing it sits inside is structured around the kind of code-level investigation that surfaces what a checklist process misses. If you are approaching a deal and want to understand what a rigorous buy-side review looks like before the LOI is signed, reach out directly.
