The Complete Guide to Technical Due Diligence for Acquisitions

When a buyer commissions technical due diligence on a company, the review determines whether the systems that company runs on, the code it owns, and the people who keep both working can support the acquisition thesis, and what it would cost to close the gap. In other words, it answers a question financial diligence cannot reach: not what the company earns, but whether the technology producing those earnings can carry the growth the buyer is underwriting.

Targets fall into three groups, and the assessment looks different in each:

1. Software companies: The product is the software, and the codebase is the asset being bought.
2. Tech-enabled businesses: They sell a service or a physical product, but built software to deliver it. For example, a lender's origination platform, a medical group's patient portal, an agtech company's telemetry system. There is proprietary code, and nobody sells it.
3. Companies running on bought software: An ERP holding the operation together, a vertical SaaS product purchased years ago, integrations written by a consultant who has since moved on. Little or nothing built in-house.

The last two groups account for most mid-market acquisitions, and they tend to carry more risk per dollar of revenue because technology ownership is often operational rather than strategic.

A technical mismatch between the thesis and the asset surfaces gradually. Roadmap dates move, integration costs grow, and the gap becomes visible in the second year of a hold rather than the first week.

At Making Sense, we run these assessments for private equity firms and strategic acquirers, and also for owners preparing to sell, where the question is what to fix before going to market and whether the fix returns more than it costs. This guide is written from the buy side, and it covers what we evaluate as part of our tech due diligence practice, how we score findings, what we ask the target for, and what a useful report looks like when it reaches the people signing off on the deal.

At a glance

Technical due diligence on an acquisition target should assess seven criteria:

1. Infrastructure
2. Scalability and performance
3. Platform flexibility
4. Documentation and processes
5. Skill and knowledge management
6. Security and compliance
7. AI adoption and readiness

The same criteria apply to software companies, tech-enabled businesses, and companies running mostly on software they bought. The final report should translate those findings into the following elements: an executive summary, an assessment matrix, detailed findings by criterion, a priority roadmap, and a record of methodology and scope limitations.

Questions this guide answers

1. What does technical due diligence cover in a software acquisition?
2. How is it different from financial and legal diligence?
3. How should the codebase itself be evaluated?
4. How do you evaluate delivery readiness?
5. How do you evaluate AI dependency and exposure?
6. How are findings scored, and why does confidence level matter?
7. What should you request from the target?
8. What does the interview process look like?
9. How long does it take?
10. What should the report contain?
11. Who should conduct an independent technical assessment?
12. How do findings become a value creation plan?
13. Frequently asked questions

What does technical due diligence cover in a software acquisition?

The seven criteria listed above are the ones Making Sense uses in every software acquisition due diligence assessment, and each is scored independently. Some affect what the company can build next, others affect what a buyer inherits on day one. Other firms organize the same territory with more or fewer dimensions; what matters is that the scope is declared and the scoring stays consistent across targets. 

1. Infrastructure

How resilient are the systems the business depends on, and how quickly can they recover when something fails? We assess how much runs in the cloud versus on the company's own hardware, whether failover is actually configured or only planned for, what monitoring and alerting exist, whether backups have been restored in a test, whether the environment could survive the loss of an entire data center, and how much of it could be rebuilt from scripts instead of by hand. For a buyer, the question is how much operational exposure exists today and what investment may be required to reduce it.

An untested recovery process is the gap that matters most here, because it leaves the buyer exposed to downtime and data loss that nobody discovers until it happens. 

2. Scalability and performance

Can the technology support the growth assumed in the investment thesis without performance deteriorating or costs rising disproportionately? We assess whether the company has ever tested the system under the volume it is projecting, what response times look like for the slowest customers rather than the average one, what the current ceiling is before something needs to be rebuilt, what the company has committed to in its own service agreements, and what it costs to serve one additional customer. 

For a software product, a platform may handle higher volumes technically while becoming significantly more expensive to operate, putting pressure on margins as the business grows. For companies relying on purchased systems, the same risk can sit in licensing agreements, where per-seat or per-transaction pricing may become materially more expensive as volume increases.

3. Platform flexibility

How much friction stands between what exists today and what the thesis requires next. We assess how easily the current technology can accommodate new products, integrations, acquisitions, markets, or operating changes without disproportionate time, cost, or rework. That means looking at how separable the pieces of the system are, whether the test environment matches production closely enough to trust, how current the underlying components are, how the system connects to anything outside it, and how a release actually reaches customers. 

For systems built in-house, the question is how difficult it is to modify and extend the platform safely. For vendor-supplied systems, flexibility depends on what the company can configure itself, what requires vendor involvement, and how far the current setup has been customized from the standard product.

Tech-enabled businesses usually depend on both, and the biggest constraint often sits in the integrations connecting the systems they built with the systems they bought.

4. Documentation and processes

How much of the knowledge required to run and change the technology exists beyond the people who currently manage it? We assess whether the systems themselves are documented, whether there are written standards for how work gets done, whether anything checks that those standards are followed before code ships, whether there is a record of why the big architectural decisions were made, and how the technology team coordinates with the rest of the business. 

For a buyer, weak documentation increases transfer risk. If important knowledge exists only with a small number of people, departures after close can lead to delays, rework, and additional cost as the acquiring team reconstructs how the systems work.

5. Skill and knowledge management

How dependent is the business on specific people or outside providers to keep its technology running and moving forward? We assess how a new hire gets up to speed, whether more than one person can work in each critical part of the system, where access and decision rights sit, and whether the knowledge would survive a departure or a change of vendor. 

For a buyer, high concentration creates continuity and transition risk. When one person controls critical systems, infrastructure, or product knowledge, the acquisition carries that dependency with it. The same applies when essential knowledge sits with an outside provider and the internal team lacks the documentation or training needed to take over.

6. Security and compliance

What security or compliance risks could the buyer inherit at close? We assess both the safeguards protecting the company's systems and data and the processes around them: whether data is encrypted in storage and in transit, who can reach what, whether one customer's data can ever surface in another's account, whether there is a usable record of who did what, whether vulnerability scanning runs automatically on every change, where the company stands on the certifications its buyers will ask for, and how a real incident gets handled. 

For a buyer, gaps in this area can create remediation costs, operational disruption, regulatory exposure, or liabilities that need to be understood before the deal closes. The assessment also looks for licensing risks in software the company uses or distributes, including open source components whose terms may create additional obligations. Where those obligations could have legal implications, they should be reviewed with counsel before close.

7. AI adoption and readiness

Is the company positioned to use AI effectively, and what risks is it already taking on through its current use? We assess the quality of the data and whether anyone can trace where it came from, how it moves between systems, what AI or machine learning already runs in the product, whether anyone measures if it works, whether anyone checks for skewed or degrading results, and who decides which models and prompts get used. 

For a buyer, this helps separate realistic AI opportunities from those that would require significant foundational work. It also surfaces current exposure, such as sensitive company data being shared with external AI tools without clear policies or oversight.

Data quality is often the limiting factor. A company may have a strong AI use case but still be unable to execute it if the information it needs is fragmented across systems, inconsistent, or difficult to access reliably.

How is it different from financial and legal diligence?

The three examine the same company through different instruments.

They overlap. The most useful engagements are the ones where the three teams share findings while the work is running, when a technical finding can still influence a term.

How should the codebase itself be evaluated?

Wherever the target owns code, a codebase assessment looks at six areas, each with an observable healthy and risk state that a deal team can follow without reading code. Even in companies that bought almost everything, there is more in-house code than the org chart suggests: reporting layers, integration scripts, portals, workflow automation. 

Several of these risks can be identified quickly with the right evidence. Poorly controlled dependencies, outdated or unsupported components, and gaps in software licensing can all signal future remediation needs. A license review can also identify open source obligations that may create legal, ownership, or compliance issues for the buyer. Where those questions extend into intellectual property rights or contractual obligations, they should be reviewed with legal counsel before close.

Documented processes also need to be verified against what is actually in place. In one assessment, the engineering documentation described the automated testing and release checks in detail, and none of it existed in the codebase. In another, a control meant to keep each customer's data separate had been written and documented, but was never switched on in the application, so it never ran. For a buyer, that distinction matters because a documented process does not necessarily mean the underlying risk has been addressed. 

An independent code review can assess maintainability, technical debt, testability, and other risks within the codebase. Technical due diligence adds the broader context around infrastructure, delivery, security, and ownership needed to understand what those findings mean for the acquisition.

For software the company relies on but does not own, the assessment focuses on vendor dependency and flexibility. We look at whether critical products are still supported, how heavily they have been customized, and how difficult or costly they would be to upgrade, replace, or integrate with other systems. 

For a buyer, the key question is how much control the company has over technology that is critical to its operations. In tech-enabled businesses, this vendor risk needs to be assessed alongside the risks in the software the company has built itself.

How do you evaluate delivery readiness?

Delivery readiness is the company's ability to make changes reliably and at the pace the post-close plan requires. It directly affects how quickly integration, product, automation, and other value creation initiatives can move.

For software the company develops itself, the DORA research program at Google Cloud has spent over a decade measuring software delivery performance. Its framework uses five measures, and in a diligence context each one answers a question the buyer needs answered:

• Deployment frequency. How often can the team put changes into production?
• Lead time for changes. How long does it take for a change to go from written to live?
• Change failure rate. How often does a release cause a problem?
• Failed deployment recovery time. How quickly can the team recover when something goes wrong?
• Deployment rework rate. How much of the team's output is unplanned work to fix what the last release broke? DORA added this as a fifth measure in its 2024 report.

Read together, these signals help determine whether the delivery pace assumed in the investment plan is realistic. Weak delivery performance rarely appears as a line item in a financial model, but it constrains every value creation initiative that depends on changing or shipping software.

For systems the company buys from vendors, the question is how easily the business can make and deploy changes:

• How long does a configuration or system change take?
• Can the internal team make it, or does it depend on a vendor or outside consultant?
• Can changes be tested safely before they reach the live environment?
• Do vendor schedules or heavy customization limit when the business can make changes?
• Are upgrades being delayed because of concerns about disruption or compatibility?

A company may be able to change its own software quickly and still be constrained by a critical ERP or other third-party system. For a buyer, both sides matter because the slowest part of the technology environment can determine how fast the post-close plan can be executed.

We validate these capabilities against operating evidence rather than relying only on self-reported maturity.

How do you evaluate AI dependency and exposure?

AI introduces several forms of dependency and risk that a buyer should understand before close. We focus on four questions:

1. How dependent is the business on external AI providers? If critical products or workflows rely on third-party models, the company is exposed to changes in provider pricing, availability, and terms. That dependency may also be embedded inside software the company buys, where the underlying AI provider is less visible.
2. What company or customer data is being shared with AI providers? We assess whether sensitive information is being sent to external tools, what controls govern that use, and what policies exist around data retention and access.
3. Can the company measure whether its AI systems are producing reliable results? If AI supports a product or critical workflow, the business should be able to monitor quality and detect when performance deteriorates. Without that visibility, the buyer may be inheriting a capability whose reliability has never been properly measured.
4. How is AI-generated code controlled? The DORA 2025 research found that higher AI adoption is associated with greater software delivery throughput as well as greater instability. For a buyer, the relevant question is whether AI-generated code goes through the same quality controls as other code and whether the team understands and can maintain what has been produced.

How are findings scored, and why does confidence level matter?

Each of the seven criteria receives a rating based on the evidence available. Some criteria come back as not applicable, which is a finding in itself: a company that built nothing in-house has no proprietary code to inherit, and none to fix either. The report explains what the rating means, what drove it, and how confident we are in the evidence behind it.

A rating provides a shorthand view of the risk, but the reasoning behind it is what the deal team acts on. A strong score can still include specific gaps that require remediation, which is why every rating is accompanied by the findings and evidence that support it.

Alongside the grade, every finding carries a confidence level:

• Observed. We verified the evidence directly.
• Self-reported. Management described it, but we could not independently confirm it.
• Unknown. There was not enough evidence or access to reach a conclusion.

For a buyer, that distinction matters. A strong security rating based on observed evidence carries more weight than the same rating based largely on management statements. Confidence levels make those differences visible and help the deal team understand where additional verification may still be needed before close.

What should you request from the target?

The document request should go out before interviews begin. Reviewing the material first makes every conversation more productive and provides evidence that can be tested against what the team describes in interviews.

The specific request depends on the target, but it typically covers five areas:

1. Architecture and systems. Architectural documentation, system design documentation, and IT runbooks.
2. Development and delivery. Coding standards, branching strategy, release procedures, and testing strategy with passing criteria.
3. Security and operations. Security policies and runbooks, past security audits, and examples of how real incidents and urgent fixes were handled.
4. Product and requirements. How requirements are tracked and documented, plus public API documentation and user guides.
5. Vendor and licensing. Which third-party systems the business depends on, the contracts and renewal dates behind them, and how those systems are integrated.

For companies that develop little or no software in-house, the emphasis shifts toward the systems and vendors the business relies on, including support agreements, SLAs, integration maps, and contracts covering custom work performed by outside providers.

What comes back is informative even when it is incomplete. A target that produces most of what was requested has a different operating culture than one that produces a handful, and the gaps point to where interviews need to dig. 

What does the interview process look like?

Documents establish what should be true, and interviews help us understand what happens in practice. We schedule a series of focused sessions based on the size of the company, its technology environment, and the questions raised by the deal.

Who participates depends on how the target is structured: In a software company, interviews may involve the CTO, architects, engineering managers, and product leaders. In a business that relies primarily on purchased technology, they may involve IT, operations, and the people responsible for critical vendor relationships.

Sessions typically cover product and architecture, infrastructure and scalability, development and delivery, team and knowledge dependencies, security and compliance, and AI. The number and length of the sessions vary with the scope of the assessment and the complexity of the target.

The review is conducted through authorized access to the target's systems, documentation, and team. The process is designed to gather sufficient evidence without disrupting the business or creating unnecessary friction with a management team the buyer may continue working with after close.

How long does it take?

A Making Sense assessment typically takes two to four weeks, depending on the size of the company, the number of products, and how quickly the target provides access to the information and systems needed for the review. A typical engagement looks like this:

• Week 1: Access setup and initial document review
• Weeks 2 and 3:  Interviews and review of the codebase infrastructure, security, and other critical technology risks
• Week 4:  Findings synthesis, scoring, roadmap development, report delivery, and debrief

Timing within the deal matters as much as duration. The assessment should take place after the letter of intent and before final terms are agreed, while the findings can still influence price, structure, and post-close planning. Started later, it risks becoming confirmation of a decision already made.

Two to four weeks allows more depth than the timeline may suggest. Alongside interviews and document review, the assessment includes direct examination of the technology environment to verify security, software maintenance, licensing, and other risks that could require remediation after close. 

What should the report contain?

A useful report needs to work for two audiences: the people making the investment decision and the teams responsible for acting on the findings. It should include five elements:

1. Executive summary. The overall rating, a plain-language explanation of what drove it, and the two or three findings with the greatest implications for the deal. Whoever signs off on the acquisition should be able to understand the key risks from this section alone.
2. Assessment matrix. All seven criteria and their ratings, on one page. A partner should be able to understand the overall technology risk profile without reading further.
3. Detailed findings by criterion. For each area, the report explains the strengths, gaps, and lower-priority improvements, along with confidence level behind each finding. The detail should be specific enough to understand the risk, its likely impact, and what would need to be addressed.
4. Priority roadmap. Findings ordered by risk, impact, and effort. This turns the assessment into an actionable plan and provides a starting point for the post-close technology agenda during the hold period.
5. Methodology and scope limitations. What was evaluated, what was not, and why. Access limitations are normal under a transaction timeline, and making them explicit helps the deal team understand where conclusions are well supported and where additional verification may still be needed.

Who should conduct an independent technical assessment?

An independent codebase assessment should be led by a team that combines software engineering expertise with M&A experience and can translate technical findings into deal risk, remediation needs, and post-close priorities. 

A code review can identify important risks within the software itself. Technical due diligence adds the broader operating, security, ownership, and remediation context needed to understand what those findings mean for the acquisition.

An internal team can perform this work in some deals. An external review can add:

• Independence perspective. The target is assessed against defined criteria without being influenced by internal architecture preferences or future-state decisions already under consideration.
• Cross-company comparability. Findings can be compared with companies at a similar stage and scale, helping distinguish normal maturity gaps from material risks.
• M&A-specific context. The review considers transfer risk, integration, continuity, and post-close execution alongside the technical findings.
• Remediation sizing. Material findings are connected to the effort, time and cost likely required to address them.
• Documentation the deal team can defend. The deal team receives a clear, evidence-backed record that can support investment committee discussions and post-close planning.

When selecting a firm, look for a documented methodology and scoring system, relevant experience with the type of company being acquired, and the ability to translate technical findings into business and deal implications. The team should also be able to work constructively with management, because access and cooperation directly affect the quality of the evidence available. If execution support may be needed after close, continuity beyond the assessment can also be valuable.

How do findings become a value creation plan?

The priority roadmap is the bridge between diligence findings and the post-close value creation plan. By ordering findings according to risk, impact, and effort, it gives the buyer a practical starting point for deciding what needs attention first after close.

In one engagement, a private equity firm evaluating a multi-product, multinational company in capital project planning asked us to support its investment thesis with a rapid technical assessment. The review surfaced growing risks and technical debt that had not been properly accounted for, along with areas of the growth plan that required further attention.

In another engagement, a lower mid-market fund pursuing a buy-and-build strategy was evaluating a company in government administration. The assessment identified deficiencies that fed directly into pricing and post-close planning, while the security review surfaced additional risks associated with the software being acquired.

The roadmap then becomes an input to the value creation plan, while the scored baseline provides a reference point for measuring progress across the hold period. We have written separately about how technology diligence feeds value creation from deal through exit, including what the first ninety days should produce. Firms managing several software assets can extend the same approach across the portfolio through technology portfolio management.

Where to start

The value of the assessment depends heavily on how the scope is defined. The framework remains consistent, but the depth of each area should follow the investment thesis and the risks most material to the deal. 

A buy-and-build platform, for example, requires deeper analysis of integration risks and the ability to absorb future acquisitions. A company being acquired for the value of its data requires greater scrutiny of the quality, accessibility, and reliability of that data. The scope should reflect what the buyer expects to do with the business after close.

Evaluating a target? Talk to our tech due diligence team about a specific deal, or what a scoped review should cover for the company you are considering.

Frequently asked questions

What is the difference between a code audit and technical due diligence?

A code audit focuses on the codebase, including maintainability, technical debt, testability, dependencies, and code-level risks. Technical due diligence adds infrastructure, delivery, security, team and ownership, vendor dependencies, and the business context needed to understand what those findings mean for the acquisition. Where most of the software was purchased, a code audit covers only a small part of the exposure.

When should it happen in the deal process? 

After the LOI, before final terms. Findings should inform valuation and structure while there is still room to act on them.

Can we run it internally? 

You can. An external review adds independence from internal stack preferences, comparability against other companies at the same stage, M&A-specific context, and documentation the deal team can put in front of an investment committee.

What if the target will not grant full access? 

Partial access is common and workable. What matters is that the report says clearly which criteria were evaluated on observed evidence and which relied on self-reporting, so the buyer knows the weight each finding carries.

How does it interact with financial diligence? 

Directly, in both directions. Cost per customer, license obligations, and remediation estimates all have financial consequences. The strongest outcomes come from teams sharing findings while the work is running.

Do you assess AI readiness? 

Yes, as a scored criterion covering data quality, data flows, existing AI and ML features, evaluation practice, and governance. Dependency on external model providers is assessed as a distinct exposure with margin and availability implications.

What does a software company technical due diligence review cover? 

Seven criteria: infrastructure, scalability and performance, platform flexibility, documentation and processes, skill and knowledge management, security and compliance, and AI adoption and readiness. Each is scored separately, with a confidence level indicating whether the finding was observed directly or self-reported by the target.

Can a seller commission one? 

Yes, and it is worth doing before going to market. A pre-sale assessment shows owners what a buyer's advisor will find, which turns surprises into either fixes or disclosed items. The useful part is the sizing: knowing what remediation costs lets an owner decide whether the investment returns more than it adds to the sale price.

What if the company does not build software, or builds it without selling it?

The seven criteria still apply in both cases. Where nothing was built in-house, the focus moves to the systems estate: which products are under vendor support, how far configurations have drifted from standard, and who can make a change without calling an outside party. Where there is proprietary software that nobody sells, which is the most common mid-market case, the assessment needs both halves, and the integration layer between what was built and what was bought is where the risk usually concentrates. 

Is the process different for carve-outs? 

The criteria stay the same. Emphasis shifts toward shared services, entangled infrastructure, and what has to be separated or rebuilt before the entity can operate independently.

What happens after the report? 

Acquirers frequently need help executing the roadmap, whether that means closing security gaps, standing up CI/CD, or providing technical leadership during integration. Those engagements are separate from the assessment.