Legacy code analysis for technology due diligence Case…

Legacy code analysis

The Challenge

Unknown substance before signing

The buyer needed credible statements on maintainability, security posture and integration risks—without access to all production data.

Developer dependencies and undocumented modules were only fragmentarily described in the data room.

We had to know if the codebase was viable before signing—not after.

Delphi, Java and batch side paths

The application combined several generations: desktop Delphi, Java services and nightly batch jobs. Interfaces were partly undocumented.

Key-person risk was high because critical domain logic lived in only a few heads.

Licence and dependency risks were not fully broken down in the data room.

Target state: priority matrix for the first 12 months

A confidential report should quantify risks, debt and integration effort—with stabilisation vs partial modernisation scenarios for board and IT leadership.

Buyer wants to negotiate purchase price and integration budget based on data.

Timeline for the first 12 months post-closing must be credible.

Integration team needs clear dependencies between security fixes and modernisation.

Negotiation team wants heatmaps and CSV detail planning alongside board PDF.

M&A decision-makers need understandable summary alongside technical detail report.

Due diligence timeline allows no week-long analysis pauses before signing.

Our Solution

Analysis artefacts

Layered analysis architecture

Static analysis, architecture cuts, review of critical domain paths and sizing of modernisation blocks. Delivered as a priority matrix with effort scenarios for the first 12 months post-closing.

Confidential report without production data—suitable for board and negotiation team.

Method aligned with our legacy code analysis service; modernisation context in the legacy modernisation blog category.

Phase 1: inventory and security hotspots

SonarQube and Semgrep identify code and dependency risks; ArchUnit checks layer violations. Critical domain paths are traced manually.

Team dependencies and bus factor are named in the report.

Undocumented batch jobs and interfaces receive effort estimate and risk score.

Security hotspots are prioritised by exploitability and business impact.

Phase 2: roadmap scenarios and effort

Three scenarios (stabilisation, incremental modernisation, core rewrite) with rough effort and risk. CSV/PDF export for negotiation and budgeting.

Workshop with IT leadership and board closes open risks before signing.

Integration backlog for the first 90 days is mapped with dependencies between security fixes and modernisation.

Due diligence means naming risks—not glossing them over.

Results

Decision-grade input for pricing and budget

Management could map risks to purchase price and staff an integration backlog with clear priorities.

Security hotspots and legacy modules received clear priorities instead of vague “technical debt” wording.

Negotiation team used effort scenarios for purchase price adjustment and integration budget.

Heatmaps showed modules with high bus-factor dependency at a glance.

Workshop closed open risks before signing with IT leadership and board.

CSV export complements board PDF for integration team detail planning.

Delivered within the agreed timeline

Report and workshop with IT leadership and board within the due diligence window.

Integration backlog for 90 days post-closing is documented with dependencies.

Security hotspots were prioritised over cosmetic modernisation.

Analysis by Groenewold IT Solutions—structured legacy assessment Made in Germany for M&A decisions.

Analysis methodology

Static tools and architecture cuts

Automated scans complement manual reviews of critical paths; results feed a unified risk matrix.

Delphi, Java and batch paths are consolidated in one inventory.

Domains and integration points

External interfaces, batch jobs and data stores are inventoried; undocumented couplings receive effort estimates.

Outcome and usage

Priorities for post-closing

The matrix sorts measures by risk, effort and business impact—basis for the integration team in early months.

First 90-day measures are included as a prioritised backlog with rough estimate.

Dependencies between stabilisation, security fixes and partial modernisation are explicitly mapped.

Confidentiality and formats

Board-ready PDF plus CSV for detailed planning; no production data required.

Board-friendly summary complements technical detail report and CSV export.

Features

Feature overview

Code and architecture inventory
Security and dependency hotspots
Roadmap scenarios (stabilisation vs partial modernisation)
Confidential report for board and IT leadership

Frequently asked questions: legacy code analysis for due diligence

How long does a legacy code analysis for due diligence take?

Typically a few business days up to about two weeks—depending on repository size, build complexity and available access. Before we start, we clarify scope (code only versus operations and interfaces) and agree a fixed timeline. For a compact first assessment, the fixed-price legacy code analysis is also an option.

What access and materials are required for the analysis?

Source repositories, build and deploy documentation, dependency lists, an interface overview and ideally architecture sketches. Production data is usually not required; anonymised staging environments are enough for most risk checks. Missing artefacts are documented as a separate risk in the report.

Which technical risks are typically identified?

Maintainability, missing tests, outdated frameworks, security hotspots, licence and dependency risks, key-person dependency and integration bottlenecks. The outcome is a prioritised matrix—not just a traffic light. For modernisation decisions, legacy modernisation often defines the next steps after the analysis.

What format does the analysis report take?

A structured report with risk classes, effort scenarios for stabilisation, partial modernisation and optional rewrite, plus recommendations for the first 12 months after closing. The audience is board, IT leadership and negotiation teams—confidential and without unnecessary jargon. The technical debt calculator can provide initial budget ranges.

When is analysis enough—and when is a rewrite the better option?

Analysis is enough when the codebase is still valuable and modernisation can proceed incrementally. A rewrite is more likely when architecture, stack or testability permanently block further development—with credible cost sizing instead of gut feeling. Between stabilisation and greenfield, software rescue bridges the gap; larger rebuilds are planned through custom software development.

Legacy code analysis for technology due diligence