Technical Due Diligence for M&A: The 40-Point Checklist

An acquisition can look brilliant on paper and still be hiding its most expensive problems in the codebase.

We've seen it from inside diligence engagements at Applore: the target has strong revenue, loyal customers, impressive growth and an attractive product, and underneath the commercial story sits outdated architecture, undocumented infrastructure, fragile integrations, security weaknesses, a mountain of technical debt, or a platform that two engineers understand and nobody else can touch. None of it appears in the financial statements. All of it appears after the transaction closes, on the buyer's budget.

That's why technical due diligence in M&A deserves to be a core part of the acquisition process, not a final formality squeezed in before signing. The objective was never to prove the target has perfect technology; almost nobody does. It's to identify the material risks, understand their financial and operational impact, determine whether the technology can actually support the business plan you're paying for, and estimate what the fix-up will cost. Get that right and technology risk gets priced into the deal. Get it wrong and it gets priced into your next three years.

This is the 40-point framework we use. Steal it, adapt it, and if the deal is big enough, bring in people who've run it before.

What technical due diligence actually is

Technical due diligence is the structured evaluation of a target's technology assets, architecture, software, infrastructure, engineering practices, security, data, team and technology risks before an acquisition or investment. In plain terms, it answers the questions that decide whether the deal maths hold: What technology are we actually acquiring? How reliable is it, and can it scale? How secure is it? How much technical debt is buried in it? Does the company even own its software? Can the team support it after key people cash out? What will integration cost, and where are the hidden liabilities?

The findings feed directly into valuation, transaction structure, warranties, integration planning and post-acquisition investment. This is deal work, not IT housekeeping.

And here's the pattern that makes it non-negotiable: a company can acquire technology without acquiring technology capability. The impressive product where only two engineers understand the platform. The "cloud-native" business is quietly held together by undocumented manual processes. The SaaS company whose recurring revenue sits on infrastructure that cannot survive its own growth projections. The product is stuffed with third-party components whose licenses restrict exactly what the buyer planned to do with it. Diligence makes these visible while they're still negotiable.

The 40-point checklist

Section 1: Technology strategy 

Start at the top, because everything downstream depends on it. Understand the technology's role in the business: is it supporting operations, or is it the product and the moat? The answer changes how hard every subsequent finding hits. Review the technology roadmap for major planned initiatives that become your investment obligations the day after closing; buyers routinely inherit half-finished replatforming projects nobody mentioned in the data room. Assess strategic alignment: a stack that works for the target's current business can be completely wrong for your growth expectations, and that gap is a cost. Build the initial risk register across scalability, security, reliability, debt, people, infrastructure and IP; you'll refine it through every section below. And estimate technology investment requirements over the next 12 to 36 months, because the purchase price is only the entry fee. Total cost of ownership is the real number, and it belongs in the model before the offer, not after.

Software architecture 

Map the current architecture properly: applications, services, databases, integrations, infrastructure, until the buyer understands how the system works as a whole, not as a collection of vendor logos on a slide. Evaluate architecture quality: is it modular, maintainable, resilient? Tightly coupled systems are future change orders wearing a diagram. Assess scalability against the projections in the deal model specifically: users, transactions, data volumes, geographic expansion. If the business plan assumes 5x growth and the architecture assumes the status quo, someone is paying for the difference, and it's you. Trace system dependencies, internal and external, because the surprise dependency is a classic integration killer. And evaluate technical debt honestly: debt is not automatically a deal breaker, every real company carries some. The question is whether it blocks growth, inflates operating costs or creates unacceptable risk. Debt in a low-traffic internal tool is noise; debt in the core revenue platform is a valuation conversation.

Section 3: Codebase and engineering

Sample the important repositories and assess maintainability, structure, testing and documentation; you don't need to read everything, you need to read the code that makes the money. Review development practices: how the team plans, builds, tests, releases and maintains. Check test coverage across automated, regression and integration testing, because low coverage means every post-acquisition change carries breakage risk, and integration is nothing but changes. Assess CI/CD: manual deployments and inconsistent releases are operational risk you'll inherit at the worst possible moment. And, the point that has sunk more integrations than any architecture flaw, is identifying key-person dependency. If critical knowledge lives in one or two heads, your transaction risk has names, and the retention plan for those names belongs in the deal terms, not the post-merger scramble.

Section 4: Cloud and infrastructure 

Understand the cloud architecture: AWS, Azure, GCP, private, hybrid, and how deliberately it got that way. Test infrastructure scalability against the growth plan, not the current load. Analyse infrastructure costs line by line; uncontrolled cloud spend is both a margin problem you're buying and, usefully, a proxy for engineering discipline generally. Review reliability: uptime history, incident records, disaster recovery, monitoring. A target that can't produce its incident history is telling you about its incident history. And check for infrastructure as code: reproducible, documented infrastructure integrates and recovers; hand-built infrastructure is one departed sysadmin away from being archaeology.

Section 5: Data and databases 

Map the critical data: customer, financial, operational, product, analytics, because in many acquisitions the data is a large share of what you're actually buying. Review database architecture: technologies, replication, backup, scaling, maintenance. Assess data quality ruthlessly, since poor data both devalues the platform and inflates every future migration. Evaluate data governance: access controls, ownership, retention, lineage, which also previews the compliance conversation. And scope the data migration: what must move, transform, clean or integrate post-close, because data migration is where integration timelines go to die, and it's far cheaper to know that during pricing.

Section 6: Cybersecurity

Review the security architecture: authentication, authorisation, encryption, secrets management, network controls, monitoring. Investigate the incident history: previous breaches, vulnerabilities and, critically, the quality of remediation, since how a company fixed its last incident predicts how it will handle its next one, on your watch. Assess vulnerability management: scanning, patching, penetration testing cadence. Map compliance requirements: regulatory, contractual and industry-standard obligations transfer with the business, whether or not anyone priced them. And evaluate third-party security risk across the critical vendors, because you're not just acquiring the target's security posture, you're acquiring its supply chain's.

A hard truth worth stating here: an undisclosed breach or a severe unpatched vulnerability discovered in diligence is one of the few findings that can and should reopen price. Take this section seriously.

Section 7: IP and software ownership

The shortest section and the one with the most binary outcomes. Verify software ownership outright: confirm the target legally owns what you're buying, and don't accept the assumption. Audit open-source usage: dependencies, licenses, obligations, because a copyleft license in the wrong place can create commercial restrictions on the exact product you're acquiring. Review third-party commercial licenses for transferability; licenses that die at change-of-control are a post-close ransom note. And check IP agreements with employees and contractors, since code written by a contractor without an assignment clause may not be the target's to sell. We've seen this exact issue surface at signing week. It's not a fun week.

Section 8: Engineering organisation

Assess team structure: size, roles, leadership, specialisation. Identify capability gaps the buyer will need to fill, and price the hiring. Evaluate retention risk, because technology transitions fail when key engineers leave, and acquisition announcements are precisely when key engineers update their profiles; retention packages for critical people belong in the deal design. And review institutional knowledge: documentation, architecture records, runbooks. A well-documented platform survives departures; an undocumented one is a key-person dependency wearing a team photo.

Section 9: Integration and the roadmap

Estimate integration complexity across applications, identity, data, infrastructure, APIs, security and operating processes, in weeks and money, not adjectives. And finally, convert everything into a post-acquisition technology roadmap, because a diligence report that's only a list of problems is half deliverable. The full version sequences the findings: immediate risks, first 90 days, first six months, strategic modernisation, long-term platform investment. That roadmap is what the integration team actually executes, and building it is where diligence stops being an audit and becomes strategy, the same operating philosophy we apply across our AI business transformation consulting work: diagnosis first, then a sequenced plan someone can run.

What the report must contain, and the red flags that change deals

A useful diligence report helps executives decide, which means it leads with an executive summary of overall technology condition, then covers strengths worth preserving, material risks, technical debt, security findings, the architecture and team assessments, integration complexity, an investment estimate and the recommended roadmap. If a report buries the answer to "should this change our price?" on page 40, it's a document, not a deliverable.

And some findings deserve to be called what they are. The red flags that materially change deal economics: no clear software ownership, critical undocumented systems, severe security vulnerabilities, no reliable backups, single-person dependency, unsupported software versions, uncontrolled cloud costs, severe debt in the revenue platform, poor data quality, weak access controls, no disaster recovery, unclear third-party licensing, architecture that can't support projected growth, and high attrition risk. A red flag doesn't automatically mean walking away; it means the risk gets understood, priced and contractually addressed. The deals that go wrong are rarely the ones with red flags. They're the ones where nobody looked.

One framing rule ties the whole exercise together: connect every finding to business value. The question is never just "is the architecture outdated?" It's "what happens to revenue, customers, operating costs and growth if we don't address it?" Run diligence as a pure IT audit and you'll produce technically accurate findings that no deal team can use. Run it as a business assessment with technical depth and every finding lands where decisions get made.

After the close

Diligence should flow straight into post-merger planning: decide what to keep, integrate, replace, modernise and retire, and resist the urge to change everything at once, because phased integration beats heroic integration in every case we've seen. Customer-facing systems deserve particular caution; aggressive migration there converts technology risk into revenue risk in real time.

This is also where our own practice is built to help. Applore's Technology Strategy work specifically includes M&A technology diligence alongside board advisory, digital strategy and CTO-as-a-Service, and the connection between those offerings is deliberate: the diligence findings become the architecture decisions, modernisation programmes and integration plans that follow, and it's far better when the people who found the risks help sequence the fixes. Our broader technology consulting practice carries that from strategy through execution, because an acquisition doesn't end when the report is delivered. That's when the real work starts.

Conclusion

Technology can be an acquisition's greatest asset and its biggest hidden liability, often simultaneously. A strong technical due diligence process replaces assumptions with evidence across architecture, ownership, security, infrastructure, data, team and integration complexity, and gives leadership what it actually needs: better decisions on valuation, transaction risk, investment and post-merger priorities.

Because the best diligence never just answers "is the technology good?" It answers the question the deal actually turns on: what are we acquiring, what risks come with it, and what will it take to make this technology support the next stage of the business?

If you have a transaction in motion, or a target you're circling, talk to Applore. We'll run this 40-point framework against the target with experienced technical judgment behind every point, deliver findings sequenced into a roadmap your integration team can execute, and tell you plainly which risks should move the price, which need contractual protection, and which are just normal software being normal software. In M&A, that clarity before signing is the cheapest insurance you will ever buy.