Legacy Audit: Code & Architecture Forensic for Established .NET Systems

When is this service a good fit?

• Releases or larger changes are difficult to plan, and the technical causes are not yet supported by sufficient evidence.
• Architecture, dependencies, or hotspots make it difficult to judge which changes are reasonable.
• You need to choose between stabilization, incremental modernization, and a deeper follow-up investigation.
• You need a traceable basis from the existing system to set budgets and order the next technical steps.

What the legacy audit examines

Before the work starts, we define the system boundary, repositories, data sources, and decision questions. The assessment uses only the information that is actually available within the agreed scope.

• Architecture and system boundaries: responsibilities, structure, coupling, and visible technical bottlenecks.
• Dependencies and interfaces: internal and external connections, shared components, and areas with a wide change radius.
• Code quality and hotspots: areas that are hard to understand, frequently changed, or error-prone where the code and metrics support that assessment.
• Git and change history: change patterns, components that often change together, and indicators of recurring problems.
• Test strategy: which business-critical paths are protected, how meaningful the tests are, and where an adequate safety net is missing.
• Build and CI/CD: reproducibility, quality gates, manual steps, feedback times, and known weaknesses in the delivery path.
• Release and change risks: technical causes, affected processes, existing recovery options, and open questions before further changes.

Process

1. Clarify the assignment: we name the decision ahead, define the system and repository boundaries, and record available and missing data sources.
2. Examine the system: I connect architecture and code with dependencies, Git history, tests, build, CI/CD, and known release events where this information is available.
3. Classify the evidence: each item is identified as an evidence-backed finding, technical risk, hypothesis, or open question. Priorities reflect the connection to business-critical paths, the effect on releases and changes, the strength of the evidence, and the next verifiable step.
4. Prepare decisions: once all agreed access and data are available, I complete the audit within 5 working days. In the review, I explain priorities, limits, and options for stabilization or incremental modernization.

What you provide

• Access to the agreed repositories with their Git history and available architecture information.
• Available information on dependencies, tests, build, CI/CD, deployment, recovery, and known release problems.
• People who can explain the business domain, system context, operational processes, and previous change problems.
• A clearly named decision for the audit to prepare. All agreed access and data must be available before the 5-working-day period begins.

Result

• A traceable picture of architecture, dependencies, code hotspots, and technical knowledge gaps within the examined scope.
• A prioritized register of evidence-backed findings, risks, hypotheses, and open questions, with reasoning and the next investigation step.
• A detailed report, a dynamic audit that can be explored independently, and a concise two-page summary for internal alignment.
• A roadmap with options for stabilization and incremental modernization. A full rewrite is considered only when the findings support it.
• A review that supports budget sequencing, a scoped pilot, required follow-up investigations, and the next technical decisions.

Timeline and price

Within 5 working days once all access and data are available

€4,500–€9,000 fixed price, net plus VAT

Packages

Standard

up to 3 repositories €4,500 fixed price, net plus VAT

Full Forensic

up to 10 repositories €9,000 fixed price, net plus VAT

Agreed scope and documented acceptance.