Technical due diligence can tell you a great deal about a software asset before an acquisition. It can evaluate architecture, infrastructure, security, product quality, technical processes and the engineering team itself. Snyk describes technical due diligence as an assessment of products, infrastructure, architecture, roadmap, services, practices and IT staff, usually performed around events such as M&A or investment.
What it can't do is transfer understanding.
The transaction closes. Someone now owns the repositories. Someone has to change the system on Monday, answer an auditor on Tuesday and debug it at 2 a.m. three months later.
The diligence report described the asset.
It didn't upload the previous team's mental model into yours.
That gap is where post-acquisition engineering risk starts.
Technical due diligence and technical ownership solve different problems
A good diligence process should absolutely examine the codebase.
Modern software due-diligence guidance typically covers architecture, infrastructure, security, IP and licensing, documentation, delivery processes and team capability. MadeWithLove makes the distinction particularly clearly: a code audit focuses on code, while technical due diligence evaluates the broader technical operation. Its 2026 guide breaks down the difference here.
M&A advisers also increasingly treat key-person dependency as part of the risk picture. L40's 2026 M&A technology checklist includes dependence on a handful of individuals among the questions that can affect the investment thesis and post-deal execution. See its technology due-diligence checklist.
But diligence has a natural boundary.
It can tell you:
“This service has poor test coverage.”
It may not tell you:
“The team stopped investing in those tests because the payment provider's sandbox behaved differently from production and every attempted rewrite created false confidence.”
It can tell you:
“These services communicate over a message queue.”
It may not tell you:
“The queue exists because a synchronous integration caused a production incident four years ago and nobody ever revisited the trade-off.”
The first category is visible in systems and artifacts.
The second often exists in history, conversations and people's heads.
That's the knowledge you discover you bought only after some of it has already left.
Three ways engineering teams inherit code they don't understand
An acquisition is only one version of the problem.
#1 An acquisition closes
The buyer inherits repositories created under conventions, constraints and business assumptions its engineers weren't present for.
The code may be perfectly functional.
The problem is that the new team can't yet distinguish deliberate design from historical accident.
#2 A new CTO or engineering leader arrives
No repositories changed hands.
Accountability did.
The new leader is responsible for systems they haven't had time to internalize. Every architecture question initially flows downward to people who may themselves hold only fragments of the answer.
#3 A key engineer leaves
No M&A process. No diligence room.
The billing service is still there on Monday.
The person who knew which part not to touch isn't.
Different trigger, same underlying condition:
a production system exists and the people now accountable for it can't yet answer basic operational questions without outside help.
The first mistake is trying to understand everything
The goal of the first month isn't mastery.
That is impossible for a large inherited estate and usually counterproductive.
The goal is to establish where ignorance creates risk.
You need to know:
- which systems have concentrated ownership
- which critical areas no longer have an active owner
- where documentation diverges from code
- which architectural decisions carry large blast radius
- which external dependencies have no current internal expert
- which questions the new team simply can't answer
That gives you a risk map.
Without one, inherited-codebase work tends to follow curiosity: engineers explore the systems that are easiest or most interesting to understand first.
Operational risk rarely follows the same order.
How risky is the codebase you inherited?
Pick one critical system, not the entire estate.
1. Active ownership
0 points: multiple current engineers can change it
1 point: one clear owner plus a credible backup
2 points: one owner only
3 points: no current owner
2. Knowledge concentration
0: system knowledge is distributed
1: some questions route repeatedly to one person
2: most non-trivial questions route to one person
3: the knowledgeable person is no longer available
3. Documentation trust
0: docs are current and verified
1: mostly current
2: engineers regularly say “check the code instead”
3: nobody trusts the docs
4. Architecture confidence
0: diagrams match current call paths
1: small differences
2: major unknowns
3: nobody can explain the real runtime architecture
5. External dependency ownership
0: services, licenses and integrations have named owners
1: minor gaps
2: several unclear dependencies
3: critical jobs/services have no internal expert
6. Safe-change ability
Ask: Could someone on the current team ship a meaningful change to this system this week without help from the previous owner?
0: yes
1: probably
2: only with significant delay
3: no
Result
0–4 — Operationally understood
Normal transition work.
5–8 — Knowledge gaps
Prioritize the exposed areas.
9–13 — High transition risk
Treat knowledge recovery as roadmap work.
14–18 — Critical
Avoid unnecessary structural change until the team can explain the system.
CTA:
Map the top three exposed systems →
Implementation note: calculate instantly. No email gate before the result.
Your first 30 days: build an exposure map before an integration plan
The first month should produce one outcome:
a ranked list of systems the new organization can and can't safely change.
Not a prettier architecture deck.
Not a migration wishlist.
A usable exposure map.
Days 1–3: map ownership concentration
Start with repository history.
For each critical subsystem, identify:
- meaningful contributors
- current employees
- frequent reviewers
- last substantial change
- likely backup owners
Don't equate commit count with knowledge.
Research into bus factor shows why. A 2022 study of 269 engineers found that version-control history misses other important channels through which engineering knowledge is distributed. The researchers improved bus-factor estimation by including code-review and communication data alongside VCS information. Read Bus Factor In Practice.
So the ownership question isn't:
Who committed most?
It's:
Who can explain and safely change this now?
Days 1–3 deliverable
Create an initial list:
System
Primary knowledge owner
Still available?
Backup?
Confidence
Any critical system with no available owner moves immediately into the exposure queue.
Days 4–7: identify orphaned systems and question routes
For a week, capture unresolved questions.
Not every Slack message.
Only questions that reveal missing system context:
- Where is this behavior implemented?
- Why does this retry?
- Who owns this scheduled job?
- Can we remove this queue?
- What calls this service?
- Why does the schema look like this?
- Which repository is authoritative?
- What happens if this dependency disappears?
Track where each question goes.
If every difficult question routes to one former employee, contractor or overworked remaining engineer, you've found the real ownership map.
This is the same problem bus-factor research tries to capture: project resilience depends on the distribution of knowledge, not simply the number of contributors. A 2016 study of 133 popular GitHub projects found that 65% had an estimated truck factor of two or lower, though the authors also stressed there's no universally accepted way to calculate the metric. See A Novel Approach for Estimating Truck Factors.
On top of the above, you also need to plan the following steps:
Week 1: inventory the things that aren't obvious from the repository tree
Inherited systems often fail around their edges.
Look for:
- SaaS integrations
- scheduled jobs
- certificates
- license servers
- infrastructure scripts
- service accounts
- deployment credentials
- manual production procedures
- external APIs
- data pipelines
- old cron jobs
- third-party libraries with special constraints
Technical due diligence commonly includes infrastructure, security, licensing and third-party exposure precisely because software isn't only application code. Snyk's technical due-diligence overview lists infrastructure, architecture, products and practices among the areas under review.
Post-close, though, you need an additional field:
Who internally understands this dependency now?
A perfectly documented vendor contract doesn't help much during an outage if nobody knows which production path still depends on the service.
Week 2: reconstruct the decisions with the largest blast radius
Don't try to reconstruct every historical decision.
Pick five.
Choose decisions where getting the rationale wrong could make future work expensive or dangerous:
- database architecture
- eventing model
- authentication
- tenancy
- deployment topology
- synchronization strategy
- integration boundaries
- data ownership
For each decision, ask:
- What exists now?
- What alternatives were considered?
- Why did the current design win?
- Which constraint was decisive?
- Is that constraint still true?
- What evidence survives?
Look in:
- ADRs
- old PRs
- issues
- commit messages
- incident reports
- meeting notes
- archived chats
- people who worked around the system
If you can't find the rationale, mark it unknown.
Don't reverse-engineer a plausible story and quietly turn it into fact.
That distinction becomes especially important with AI. A model can generate a convincing reason why a queue, retry or abstraction exists. Convincing isn't the same as historically correct.
Weeks 3–4: test the handover with work, not meetings
A transition isn't complete because:
- the previous team ran six walkthroughs
- Confluence has 42 pages
- the new owner attended every session
- somebody recorded the calls
Give the new owner a meaningful change.
Not a typo.
Something requiring them to:
- identify the implementation
- trace relevant dependencies
- understand likely blast radius
- decide what needs testing
- make the change
- explain it in review
Then count the external dependencies on knowledge.
How many times did they need someone from the previous team?
How many answers came from unverifiable memory?
Which questions couldn't be answered at all?
That's your remaining transition backlog.
Why handover sessions underperform
Handover sessions aren't useless.
The problem is timing.
A person receiving a subsystem walkthrough on day three often doesn't yet know enough to understand which parts of the explanation will matter on day thirty.
The source expert says: “Don't change that mapper unless you also update the reconciliation path.”
The receiver records the sentence.
Six weeks later they encounter the mapper and no longer remember what “the reconciliation path” referred to.
Knowledge was transferred.
Context wasn't.
That is why queryable, source-linked knowledge can be more useful than bulk knowledge transfer for structural questions. The answer becomes available at the moment the engineer has enough context to ask the right question.
But there is a boundary.
A codebase can reveal current structure.
It can't recover an unrecorded conversation from four years ago.
AI makes inherited-code archaeology faster and more dangerous at the same time
AI assistants are naturally useful in an unfamiliar codebase.
They can help:
- find usages
- summarize files
- trace call paths
- identify related implementations
- explain language or framework patterns
- search large repository estates
Those are exactly the kinds of tasks that consume the early weeks of inherited-code work.
The danger appears when the model moves from:
“Here's what the repository shows.”
to:
“Here's why the previous team designed it this way.”
without evidence.
Birgitta Böckeler has made a related point in the context of coding assistants and pair programming: LLMs don't automatically contain the tacit history of a codebase that human collaboration distributes through a team. Her discussion of coding assistants and shared codebase knowledge is here.
For inherited software, the distinction is critical.
AI is strong at reconstructing structure
Examples:
- Where is PaymentRetryPolicy used?
- Which service owns this database table?
- What calls this endpoint?
- Where else do we implement the same validation?
- Which repository contains the producer for this event?
AI needs evidence for intent
Examples:
- Why was this timeout chosen?
- Why did the team reject the obvious alternative?
- Why is the deployment split across two clusters?
- Why is this duplicated instead of shared?
If the answer isn't recorded anywhere, the correct result is unknown.
Not a better hallucination.
Where Tentaro fits into inherited-code work
Tentaro is useful on the structural side of that boundary.
It indexes private repositories and turns them into grounded, queryable code context for engineers and compatible AI assistants. Its product boundary is explicitly context rather than code generation: it helps answer what exists, where it lives and how code relates without pretending to manufacture undocumented rationale.
That matters particularly in inherited software because the first problem is often scale.
The new engineer doesn't know:
- which repository contains the implementation
- which of three similarly named services is active
- what depends on a component
- where equivalent logic already exists
- which files they should read before making a change
Tentaro's internal dogfooding spans 100+ repositories built over 15 years of enterprise delivery, which makes the multi-repository problem more representative of the environment the product was built around than a single clean demo repo.
The useful workflow looks like:
question → grounded structural context → source references → engineer verifies → judgment
not:
question → plausible generated explanation → trust
Most post-acquisition plans naturally become system plans:
- migrate application A
- consolidate database B
- deprecate platform C
- merge CI pipelines
- move identity
- standardize observability
Those steps may all be right.
But before sequencing by architectural convenience, overlay understanding risk.
Imagine two systems:
System A
Ugly architecture.
Three current engineers understand it deeply.
Strong tests.
Clear operational ownership.
System B
Cleaner architecture.
Original owner gone.
Docs unreliable.
Nobody has changed it since acquisition.
Which one should you restructure or migrate first?
Probably not B.
The condition of the code and the condition of the organization's understanding are different variables.
Your integration plan should account for both.
Integration readiness check
Before scheduling a major change to an inherited system, can the current team answer:
- Who owns it?
- Who is the backup owner?
- Where is the authoritative implementation?
- What are its upstream dependencies?
- What depends on it downstream?
- How is it deployed?
- How is it monitored?
- Which external services does it require?
- What is the rollback path?
- Which major architectural decisions are understood?
- Which decisions are explicitly still unknown?
- Could someone other than the owner review a risky change?
10–12 checked: reasonable integration readiness
7–9: close gaps before major restructuring
4–6: high transition risk
0–3: learn before you migrate
CTA: Run this against your riskiest inherited system
The exit criterion for a codebase transition
A transition needs a finish line.
“Documentation delivered” isn't one.
“KT complete” isn't one either.
Use something operational.
For example: The receiving team can answer and verify normal structural questions, change the system safely and operate it without relying on unavailable members of the previous organization.
That doesn't mean every historical decision has been recovered.
Some won't be.
The point is to know where uncertainty remains and make it explicit.
A mature transition produces three categories:
KNOWN
We can answer and verify it.
RECOVERABLE
We don't know yet, but the evidence exists.
LOST / UNKNOWN
The rationale wasn't recorded or is no longer available.
The dangerous category isn't “unknown”.
It's unknown presented as known.
A 30-day inherited-codebase checklist
Days 1–3 → Exposure
- inventory critical repositories and systems
- identify current meaningful contributors
- identify departed owners
- flag systems without backup ownership
- freeze avoidable changes in critical unknown areas
Days 4–7 → Reality check
- log unanswered engineering questions
- validate sample architecture paths against code
- inventory external dependencies
- identify stale or untrusted documentation
- rank systems by operational exposure
Week 2 → Recover
- reconstruct five highest-risk decisions
- capture evidence for each
- label missing rationale explicitly
- assign provisional owners
- identify available previous-team knowledge paths
Week 3 → Make context usable
- make structural repository knowledge searchable
- connect decisions to relevant engineering artifacts
- centralize system-specific unknowns
- identify repeated questions that don't need human judgment
Week 4 → Test
- give the new owner a real change
- observe where they get blocked
- verify their architectural assumptions
- close remaining critical gaps
- establish the next-quarter ownership plan
Don't start with the whole acquired codebase
Pick the system that creates the most hesitation.
The one where engineers say: “We should probably wait until someone from the old team is available.”
Bring that system into an onboarding teardown.
The goal isn't a generic audit report. It's to expose what the new team can answer, what the repositories can recover and where the remaining knowledge risk lives.
