Home / M&A IT services / M&A technology due diligence
For deals built on software

Technology due diligence for M&A: know if the software can carry the deal

Before you sign, you’ll know whether the target’s software can carry your growth plan: how much tech debt sits in the code, what it will take to scale, and where the team, the security or the AI story falls short. Clear findings your deal team can price in, in as little as 3–5 days.

At a glance
When it runs

Before the LOI through signing, or before a sale

Timeline

3–5 days to 3 weeks

What you get

Findings ranked by deal impact, a scorecard, remediation costs and a roadmap

Built for

Deal teams buying software and tech-enabled companies

Where technology due diligence sits in the deal
01

Diligence

02

Day 1

03

TSA exit

04

Integration

Vance St. Capital
Shamrock Capital
Solace Capital Partners
Demopolis Equity Partners
Owner Resource Group
Slate Capital Group
Assured Healthcare Partners
LLR Partners
Yellow Wood Partners
Avalt
Bertram Capital
Technology due diligence, defined

What is technology due diligence?

Technology due diligence is a review of the technology a target builds and sells, before you buy it. We look at the code, the architecture, the infrastructure it runs on, how the team ships software and how secure the product is. You find out whether the technology can support the growth in your investment thesis, and what it will cost if it can’t.

It goes deeper than a standard review of a company’s IT. For a software company, a SaaS platform or any business that runs on software it built itself, the product is the asset. So this is software due diligence as much as IT: senior technologists reading the code and the delivery data, not just interviewing management.

Technology vs IT due diligence

  IT due diligence Technology due diligence
Reviews
IT due diligence

The systems the business runs on: ERP, network, help desk, security and IT spend

Technology due diligence

The software the business builds or sells: code, architecture, delivery and product security

Typical target
IT due diligence

Any company: manufacturing, distribution, services

Technology due diligence

Software, SaaS and tech-enabled companies, or any company with custom-built apps

Key question
IT due diligence

What will this IT cost to fix, separate or integrate?

Technology due diligence

Can this technology scale with the plan, and what will that cost?

We talk to
IT due diligence

IT leaders and key users

Technology due diligence

The CTO, product and engineering leads

Most deals need one or the other. Some need both, and we run them together.

Explore IT due diligence
What we review

What our technology due diligence covers

Our software due diligence covers six tracks, assessed for scalability, security and modern engineering practice. Each track ends with its own AI check, so the AI in the product is never reviewed on its own.

How the software is built
Track 01

Software development

Agile, DevSecOps and CI/CD

QA and test automation

Code and artifact management

Dependency and container scanning

Code review

AI check

AI coding assistants, MLOps pipelines, model validation and red-teaming.

The product and the security around it
Track 02

Information security

Governance: ISO 27001, SOC 2, NIST CSF

Identity and access: MFA, SSO, role-based access

Data protection: encryption and DLP

Threat detection and response

Incident response and third-party risk

AI check

AI risk management (NIST AI RMF, EU AI Act) and model risks: bias, adversarial attacks, theft.

Track 03

Application architecture

Cloud-native design: microservices, containers, serverless

Frameworks and languages

Database and data strategy

APIs and integrations

Application security: OWASP, SBOM, SAST and DAST

AI check

Embedded AI and ML services, vector databases, guards against prompt injection and data leakage.

Track 04

Infrastructure

Cloud and hybrid set-up, infrastructure as code

Scalability and multi-region resilience

Zero-trust networking

Monitoring and observability

Patching and lifecycle (CIS, NIST)

AI check

GPU and model hosting, and monitoring AI workloads for latency and drift.

What keeps it running
Track 05

Continuity and recovery

Resiliency strategy and immutable backups

Recovery targets (RPO and RTO) matched to customer SLAs

Automated failover

Tested drills and attack simulations

Critical SaaS and cloud vendor dependencies

AI check

Reliance on third-party AI providers, and recovery of critical models.

Track 06

Team and organization

In-house or outsourced model

Org structure and role separation

Cloud and DevSecOps skills

Governance and prioritization

Key-person risk

AI check

AI roles, governance and ethics policies.

Where AI is central to the investment thesis, we go deeper on the AI itself, then help you capture it after close.

M&A AI due diligence
Red flags

What technology due diligence usually turns up

The growth story in the CIM assumes the technology can keep up. These are the findings that most often say otherwise, each tagged with what your deal team should do about it.

Price it in

A cost the deal model should carry

Fix before close

Ask the seller to fix it, or cover it in the terms

100-day plan

A first priority after close

01
Price it in

Tech debt that slows every release

Years of custom code and old frameworks make each new feature cost more than the plan assumes.

02
Price it in

An architecture built for today’s load

It works at current volume but needs a rebuild to reach the users in the growth plan.

03
Fix before close

Two engineers who hold the whole system

No documentation, no bench, and the product stalls if either leaves.

04
100-day plan

Releases that rely on luck

Little automated testing, manual deployments and no code review.

05
Fix before close

Security gaps in the product itself

No code scanning, unpatched open-source components and no inventory of what’s in the software.

06
Fix before close

Recovery promises nobody has tested

Backups and failover never drilled, and recovery targets that don’t match what customers were sold.

07
Price it in

Hidden dependence on one vendor

A single cloud, SaaS or AI provider the product can’t run without, on terms that can change.

08
Price it in

An AI story the code can’t support

“AI-powered” turns out to be a thin layer on someone else’s model, or the architecture can’t take the AI roadmap.

Every finding comes with a cost to fix and a place in the deal: the price, the terms or the 100-day plan.

Scope a diligence
How it runs

How technology due diligence runs

One senior team, a proven sequence and evidence from the systems themselves, not just interviews.

Phase 1

Prepare

A request list on day one, read-only access to code and delivery tools, and every technology claim in the CIM checked.

Phase 2

Assess

Interviews with the CTO, product and engineering leads, an architecture walkthrough, code review and a security review. Red flags reach the deal team within days.

Phase 3

Report

Findings ranked by deal impact, a scorecard, remediation and scaling costs, and a roadmap, read out to the deal team, with support on the rep and warranty call.

Pick the depth
Red-flag review · 3–5 days
Confirmatory · 3–5 days
Full-scope · 2–3 weeks
See all four tiers
FAQ

Technology due diligence questions, answered

Something we haven’t covered? A partner can answer it on a short call.

What is technology due diligence?

It’s a review of a target’s technology before you invest: the code, architecture, infrastructure, security and the team that builds it. Tech due diligence tells you whether the technology can support the growth you’re paying for, and what it will cost to fix or scale.

IT due diligence reviews the systems a company runs on, like ERP, network and security, and applies to almost any deal. Technology due diligence, sometimes called technical due diligence, reviews the software a company builds or sells.

Software and tech-enabled targets usually need it. Many deals need both, and we can run them together.

When the investment thesis depends on technology: buying a software or SaaS company, a tech-enabled services business, or any company that runs on software it built itself. It runs between the LOI and signing.

Sellers use it 6–12 months before a sale, to find and fix what a buyer will find.

Yes. Code review is part of every full-scope engagement. We look at code quality, test coverage, how dependencies are managed and how securely it’s built, alongside the architecture and delivery practice.

A red-flag review takes 3–5 days. A full-scope review takes 2–3 weeks, depending on the size of the product and how fast the target shares access.

Architecture diagrams, the product roadmap, uptime and incident history, a list of third-party and open-source components, the org chart for product and engineering, and read-only access to code and delivery tools.

We send a request list on day one so nothing waits.

AI is built into every track, not reviewed on the side. We check whether the AI in the product is real and defensible, how it’s secured and whether the architecture can carry the AI roadmap.

After close, our AI consulting for private equity turns the AI findings into a plan.

The findings become a prioritized roadmap. Because we’ve already been inside the technology, we can help deliver it: as fractional CTO, running the program or supporting the team, so nothing is lost in a hand-off.

Know if the software can carry the deal

Start with a red-flag review: three to five days, and a clear view of the tech debt, the cost to scale and the risks in the code.