Technology due diligence is sometimes treated as a code quality review. That is too narrow.
A buyer is not only acquiring a product, a repository, and a team. The buyer is also inheriting architecture, operating habits, dependencies, security exposure, data obligations, and decisions that may become expensive only after the deal closes.
The useful question is not “is this technology good?” It is “what technology reality are we buying, what could constrain the business, and what will it cost to change?”
What Technology Due Diligence Should Answer
A good review should make the technology side of the deal easier to understand in business terms.
What must keep working on day one? Which systems are critical to revenue or customer commitments? Where is the company dependent on a person, vendor, or fragile process? Which risks can be accepted, which need remediation, and which could materially change the deal?
That is very different from producing a long list of code smells.
The outcome should help the buyer separate three things: problems that are mostly cosmetic, problems that become important only at a certain scale or strategic direction, and problems that can affect continuity, cost, or the ability to execute the acquisition thesis.
Start with the Acquisition Thesis
Technology only makes sense in context.
If the buyer intends to keep the company independent, the important questions are different from a plan to integrate products, consolidate platforms, move data, combine teams, or expand into new markets.
Before reviewing architecture, understand what the business expects to happen after the acquisition.
Which capabilities are part of the value of the deal? Which systems will need to integrate? What growth is expected? What cannot be interrupted? Which technology assumptions are already built into the financial or product plan?
Without that context, reviewers can spend days criticizing choices that do not matter and miss constraints that do.
Map the Systems That Actually Matter
Not every repository deserves equal attention.
Start with the systems that support critical customer journeys, revenue, data, operations, and integrations. Understand how they connect and what happens when one fails.
You do not need a perfect architecture diagram. You need a map good enough to see where the business is concentrated.
Which components are hard to replace? Which have no clear owner? Where does one failure propagate into several products? Which parts depend on manual intervention? Where are releases or recoveries unusually risky?
The point is not architectural beauty. It is operational and strategic consequence.
Review Architectural Constraints, Not Fashion
Every working system contains trade-offs. Old technology can be perfectly adequate. Modern technology can be badly designed.
I would look for constraints rather than age.
Which components are difficult to change? Where are dependencies too tight? Which changes does the team routinely avoid? What fails repeatedly? Where does scaling require disproportionate effort? Are there product areas that cannot evolve without a major technical project?
Then connect each constraint to a business consequence.
If a monolith is stable and the company can ship quickly, the label “monolith” is not a finding. If a small change requires coordinated releases across several teams and repeatedly delays product work, that is a finding.
Understand Delivery, Not Just the Codebase
A healthy repository does not guarantee a healthy engineering system.
Look at how changes move from an idea to production. How frequently can the team release? What requires manual work? How are incidents handled? Can the company restore service and data? How much knowledge is required to deploy safely?
The goal is not to demand a specific development process. It is to understand whether the company can change its product predictably.
If every important release depends on two people being online at the same time, that is a technology risk even if the code itself is clean.
Find Key-Person Dependencies
Some of the most expensive risks sit in people rather than systems.
Who understands the critical architecture? Who knows how production actually works? Who can restore data? Who owns the most important vendor relationships? Who makes the decisions when something breaks?
Then ask what happens if those people leave after the transaction.
Documentation helps, but it is not the same as distributed capability. A company can have excellent documentation and still rely heavily on one person for judgment and context.
The important output is not “documentation is weak.” It is knowing where continuity depends on specific people and how difficult that dependency will be to reduce.
Understand the Data
Data deserves its own review because it is often both an asset and a constraint.
What data does the company store? Where does it come from? Which systems are authoritative? Who can access it? How is it backed up and restored? Can it be exported, migrated, or reconciled?
Look for gaps between what the company believes about its data and what the systems can actually prove.
If the acquisition thesis includes combining products or moving customers, data structure and data quality can become a major integration problem. The fashionable framework used by the application may matter much less.
Review Security Through Consequences
Security review can easily become a checklist exercise. I prefer to start with plausible consequences.
Who has access to production and sensitive data? How are secrets managed? What happens when an employee leaves? Can critical actions be traced? What happens if an account or vendor integration is compromised? Can systems and data be restored?
Then look at the controls around the most serious scenarios.
The goal is not to find a company with zero risk. No such company exists. The goal is to understand which risks are material, how likely they are to surface during integration or growth, and whether the current organization can manage them.
Review Vendors and External Dependencies
A product can look proprietary while depending heavily on cloud services, third-party APIs, licenses, contractors, or a vendor that is difficult to replace.
Map the dependencies that would hurt if they changed.
What happens if pricing changes? Can the company switch providers? Does a critical integration depend on an undocumented behavior? Is important operational knowledge held by a contractor? Does the business rely on technology it does not really control?
Vendor lock-in is not automatically bad. Sometimes it is the economically correct choice. It becomes a problem when the deal assumes flexibility that the technology does not actually have.
Separate Technical Debt from Remediation Cost
“Technical debt” is too broad to be useful on its own.
The buyer needs to know which debt affects the deal and what happens if it is left alone.
For each material issue, I would ask: what business capability does it constrain, when does it become critical, what has to change to fix it, who needs to be involved, and what happens if nothing is done?
This turns a technical finding into a decision.
A rough estimate can also be useful as a conversation starter. The Technical Debt Calculator can help structure that first estimate, but it should not replace engineering judgment. The cost is not only developer time; some issues require product trade-offs, migration work, organizational changes, or temporary slowdown.
A Practical Technology Due Diligence Checklist
The exact depth depends on the deal, but I would want clear answers in these areas:
- business-critical systems and customer dependencies;
- architecture constraints and scaling limits;
- engineering delivery and release process;
- reliability, backup, recovery, and incident handling;
- key-person and knowledge concentration;
- data ownership, quality, movement, and recovery;
- security access and material risk scenarios;
- cloud, vendor, license, API, and contractor dependencies;
- technical debt that can affect the acquisition plan;
- realistic remediation priorities after closing.
The checklist is not the report. It is a way to make sure important areas are not invisible.
What the Final Report Should Do
The worst due diligence report is a long document where every issue looks equally important.
I would group findings by consequence and decision.
What can break continuity? What can slow integration? What can create an unexpected cost? What can limit growth? What depends on retaining specific people? What should be fixed before closing, shortly after closing, later, or perhaps never?
For each major finding, explain the evidence, the business consequence, the likely remediation path, and the uncertainty.
The report should not pretend to know more than the review can prove. A short diligence process will always leave unknowns. Those unknowns should be visible too.
Technology Due Diligence Is About Optionality
A buyer does not need perfect technology. It needs to understand what it is committing to.
A system can be old and still leave the business plenty of options. A modern architecture can still trap the company behind fragile dependencies, missing knowledge, or expensive operating assumptions.
Good technology due diligence does not answer “how good is the code?” It shows what technology obligations come with the company, which of them matter to the acquisition thesis, and how much freedom the buyer will have after the deal.