Skip to content

Transactions

Technology due diligence for M&A

A technology problem discovered during a sale rarely stays a technology problem. It can affect price, warranties, completion timing or what the buyer has to spend after the deal. I work with buyers and sellers to establish what is actually there, what matters to the transaction and what needs to happen next.

That can mean testing a target before acquisition, preparing a business before buyer diligence starts, carrying out seller-commissioned vendor technical due diligence, or turning the findings into a practical first-100-day technology plan.

Engagements

Where technology diligence fits in a transaction

Buy-side technical due diligence

For a buyer, investor or acquirer.

  • Assess the technology before the acquisition or investment completes.
  • Test whether the technology actually supports the deal rationale.
  • Identify architecture, code, security, data, infrastructure, supplier, technical debt and team risks, within the agreed scope.
  • Identify the likely remediation and post-deal technology costs.
  • Establish which management claims are evidenced and which remain unverified.

Buy-side work runs to the levels of assurance set out on Technical due diligence for investors and acquirers , which remains the main page for investor-side work and explains how each level is scoped.

Sell-side technology exit readiness

For a founder, owner, shareholder or management team preparing for a sale.

The purpose is to find the technology issues before the buyer finds them.

  • Review the areas buyer diligence is likely to cover.
  • Identify missing evidence.
  • Identify the technology risks likely to create buyer questions.
  • Separate the issues that can realistically be fixed before the process from those that cannot, and which instead need a clear evidenced explanation.
  • Improve the readiness of technical documentation.
  • Prepare management for technical diligence questions.
  • Prioritise remediation by transaction relevance rather than general technical neatness.

This is preparation for buyer scrutiny, not a programme to fix every weakness before sale. Where remediation would take too long or create unnecessary risk, the safer outcome is often to document the position, quantify it and prepare a credible plan.

Seller-commissioned vendor technical due diligence

For a seller.

  • I assess the technology position before or during the sale process.
  • Findings are evidence-led.
  • Material strengths and material weaknesses are both included.
  • Management statements are distinguished from independently observed evidence.
  • Areas that could not be assessed are identified explicitly.
  • The output can help create a consistent technical evidence base to work from during the transaction.

The scope, intended audience and permitted use of a vendor diligence report are agreed for each transaction. Third-party reliance is not implied unless it is explicitly agreed as part of the engagement.

First-100-day technology plan

For a buyer or investor, after the diligence work.

Material diligence findings turned into a sequenced plan for the period after completion.

  • What needs attention immediately.
  • What can safely wait.
  • Remediation dependencies.
  • Supplier and key-person risks.
  • Technology investment priorities.
  • Decisions required from leadership or the board.
  • Items that should stay visible in the first board packs.

Implementation support can be separately scoped where appropriate. The first-100-day plan itself is about establishing priorities, ownership and sequence.

Method

The same evidence standard on both sides of the deal

Whether the work is for a buyer or a seller, every finding is labelled by how well it is supported. Nothing is presented as more certain than the evidence behind it.

Stated
Provided by management but not independently verified.
Evidenced
Supported by documentation or artefacts.
Verified
Independently checked, where the scope and the access allow it.
Not assessed
Evidence or access was not available, and the gap is reported rather than assumed away.

The four levels of assurance, and how findings are traced and checked, are set out in full on the investor and acquirer diligence page .

Scope

What can affect the transaction

The assessment areas below are the ones that most often move price, warranties, completion timing or post-deal spend. Which of them are in scope depends on the deal and the access available.

  • Architecture and scalability
  • Code quality and maintainability
  • Security
  • Data and databases
  • Infrastructure and environments
  • Intellectual property and licensing exposure
  • Supplier dependency
  • Technical debt
  • Delivery capability
  • Key-person dependency
  • Documentation
  • Business continuity and disaster recovery
  • Technology cost and future investment
  • AI-generated code, where it is present

Preparation

What sellers should prepare before technical diligence

A working list rather than an exhaustive one. The exact requests vary by buyer, but these are the items most commonly asked for, and the ones that take longest to assemble under time pressure.

  • Architecture documentation
  • Source-control access
  • Infrastructure overview
  • Development and deployment process
  • Security policies and the evidence behind them
  • Disaster recovery and backup evidence
  • Key supplier agreements
  • Software licence and intellectual property position
  • Technology roadmap
  • Team structure and key-person dependencies
  • Material incidents
  • Known technical debt
  • Current technology spend and major future commitments

The mistake is not having technical debt. Most businesses do. The problem is when the buyer discovers something material that management cannot explain, evidence or price.

Output

What the report is for

One document, written so that each reader can find what they need without a translation layer.

  • Founders can see what buyers are likely to challenge.
  • Buyers can see what affects the deal.
  • Investment committees can see the material technology risks.
  • Technical teams can see what has to be remediated.
  • Boards can tell urgent issues apart from technical housekeeping.

The reporting format is the one evidenced on the investor and acquirer diligence page , including graded findings and the evidence behind each one.

Limits

What this does not cover

My work is technology due diligence. It is one workstream in a transaction and does not replace:

  • Legal due diligence
  • Financial due diligence
  • Tax due diligence
  • Commercial due diligence
  • Specialist penetration testing, where that is required
  • Formal regulatory or legal advice

Enquiry

Talk through the transaction

Tell me whether you are buying, selling or preparing for a transaction, what the technology consists of and the timetable you are working to. I will tell you what can realistically be assessed before the next decision.

Discuss the transaction

I will only use this to reply to you.

At least 20 characters.

Spam check, provided by Cloudflare Turnstile

I reply to everything myself, usually within a working day.

Last reviewed:

Buying, selling, or getting ready to be asked?

Send me the shape of the deal and the timetable. I will tell you which work fits, and what can honestly be evidenced in the time available.

Discuss the transaction