M&A Technical Due Diligence: The Complete Guide for Acquirers

M&A technical due diligence is the independent review of a target company's technology that an acquirer runs before signing. It tests whether the target's software, infrastructure, security, intellectual property and engineering team can support the deal thesis and the integration plan, and it puts an effort estimate and a timeline on anything that cannot. The findings feed the valuation, the protections in the purchase agreement and the plan for the first 100 days after close.

This guide is for acquirers: corporate development teams, private equity deal teams and operating partners. It covers what the review examines, how the scope changes for strategic acquisitions, platform deals and carve-outs, the mistakes that weaken it, and how findings turn into deal terms. If you are scoping a review for a live transaction, Sphere's technical due diligence assessment delivers quantified, risk-ranked findings and a 100-day plan in four weeks or less.

Why Does Technical Due Diligence Matter in M&A?

Nobody buys a house without an inspection, and nobody expects the buyer to do the inspection personally. An acquisition works the same way. Financial, legal and commercial diligence tell you what the company earns, what it has signed and where it sells. None of them open the code, test the architecture or ask whether the engineering team can deliver the roadmap the deal is built on.

That gap matters because most acquisition models rest on technical assumptions. The platform will absorb add-on acquisitions. The product will integrate with the buyer's own within a year. Users will grow tenfold in three to five years without a rebuild. Technical due diligence turns each assumption into a question with an evidenced answer, and it shows how much operating and engineering investment the target will need after close to deliver on them.

It also protects value in a more direct way. Security gaps, licence conflicts, undocumented systems and key-person dependencies are liabilities that transfer to the new owner at signing. Found before close, they are negotiating points. Found after close, they are the buyer’s problem.

What Does M&A Technical Due Diligence Cover?

Technology is one workstream among several in an acquisition, alongside financial, legal, customer and employee diligence. Within it, six areas carry most of the risk. The depth of each depends on the deal, but a credible review touches all of them and asks for evidence rather than assurances.

Documentation does a lot of work here. Ask for it early, and treat any gap between the documents and the deployed system as a finding in its own right. Access matters just as much: the review team needs the development and deployment environments, not a guided demo. For a line-by-line version a deal team can work through, use our checklist for buying a software company.

Two newer areas now appear in most scopes. If the target markets AI capability, test whether it is proprietary and whether the company owns its data and models, as covered in our guide to evaluating an AI company before you invest. And because so much production code is now written with AI assistants, review how the code was produced as well as what it does; our piece on diligence for AI-built codebases explains what to check.

How Does the Scope Change by Deal Type?

The six areas stay the same. What changes is which questions decide the deal.

Strategic acquisitions

A corporate buyer usually plans to integrate the target, so integration feasibility comes first: stack and cloud compatibility, data and identity migration, overlapping products, cultural differences in how the two teams build software, and which engineers must stay for the integration to work.

Software companies buying software companies sometimes assume their own engineers can run the review. There are two reasons to use an independent team anyway. Competitive information is at stake, and an outside team under NDA keeps the target's code and roadmap away from the buyer's product teams if the deal falls through. An outside team is also more objective, because it has no stake in proving that its own platform is the better one.

Hamilton Thorne, a provider of instruments and software for assisted reproductive technology, faced this when it evaluated an AI company as an acquisition target. Sphere's review ran parallel workstreams across platform architecture, data model, code quality and scalability, AI and ML capabilities, team and leadership, and SaaS readiness and cybersecurity. It confirmed solid AI and ML capabilities but flagged that model development had been outsourced, rated cybersecurity risk as high, and concluded that the buyer's SaaS ambitions would need significant cloud migration investment, which the deal team built into the business case. The Hamilton Thorne acquisition due diligence case study covers the full scope.

Private equity platform and add-on deals

A private equity buyer is underwriting a value creation plan over a defined hold period, so it reads the technology for scalability and capacity. Can the platform absorb add-ons without a rebuild? What engineering, hosting and security capacity will the business need at the scale in the model? Is there a key-person dependency that threatens year one? Our overview of what technology due diligence covers and what investors check compares how PE, venture and strategic buyers read the same findings.

Carve-outs and divestitures

Carve-outs add a problem that other deals do not have: the business being sold often runs on systems that stay with the seller. The review has to map every shared system, dataset, contract and person, then test whether the new company can stand up its own before the transition services agreement (TSA) runs out.

The timelines are tight. In one software division carve-out Sphere supported for a mid-market private equity firm, the parent retained its core business systems, including ERP, CRM, HR, PSA, web, intranet and analytics, and the TSA gave the new company six months to replace them. Many key internal experts left as part of the synergy process at the same time. The software division carve-out case study shows what that window demands. For carve-outs and non-software targets, an IT due diligence checklist covering enterprise systems and infrastructure is the right companion to this guide.

What Mistakes Weaken M&A Technical Due Diligence?

Most weak reviews fail in predictable ways. These are the mistakes we see most often, and each one is easier to avoid than to fix after close.

1. Reviewing only the code. A code review is one input. The review also needs schema and data, documentation, design, performance data, security, and interviews with the people who run the system.
2. Starting without a goal. Without a clear statement of what the buyer wants from the deal, assessors have no standard for deciding which findings matter. Agree the deal thesis and the integration plan before the work starts.
3. Collecting findings without estimates. A list of concerns does not help a negotiation. Every finding needs an effort and timeline estimate, and the full spectrum of changes the buyer will need to make should be visible in one place.
4. Looking only at strengths. Deal momentum makes it easy to focus on why the target is attractive. A useful report gives weaknesses equal weight and breaks each one down individually.
5. Stopping at close. Assess scalability against the growth plan for the years after the deal, not just current load.
6. Treating security as a checkbox. Review access and login controls, vulnerability management and software quality standards directly, and confirm whether the target can be brought to an acceptable standard and with how much effort.
7. Forgetting the people. If the buyer plans to keep the team, assess the engineers it is acquiring, their skills and their concentration of knowledge. Retention plans depend on it.

How Does the M&A Technical Due Diligence Process Work?

A full review of a single software target usually takes about four weeks once access is in place, and narrower scopes finish sooner. The sequence below is how Sphere runs an engagement.

Independence matters throughout. Sphere does not sell implementation services to companies it assesses, so the only obligation in the room is to give the acquirer a complete picture of the risk.

How Do Findings Change the Deal Terms and Integration Plan?

A good report sorts every finding into three groups: what is already fit for purpose or quick to fix, what is fixable with moderate effort, and what is major or structural. That sorting is what lets the deal team negotiate from facts rather than impressions. In practice the findings land in four places:

• Valuation. Remediation the buyer would otherwise absorb is reflected in the offer.
• Terms. Risks that are real but hard to size, such as licence exposure or an unresolved security issue, are handled through representations and warranties, indemnities, escrow or closing conditions.
• Integration plan. Accepted issues are funded in the integration or value creation plan instead of appearing later as surprise work.
• The first 100 days. Urgent items, such as critical vulnerabilities, missing recovery paths and concentrated knowledge, become the first workstreams after close.

To see how a sized finding should be written, and what separates a red flag from a fixable issue, read our walk-through of a technical due diligence report and its sample structure.

The same discipline works from the other side of the table. Founders who run the review on their own company before going to market can fix the quick issues and document the rest before a buyer finds them, which is the logic behind sell-side technical due diligence. For the full methodology, scope options and how to choose a provider, see our complete guide to technical due diligence and code audits.