Legacy-Code-Analyse für Technologie-Due-Diligence Referenz |…

Legacy-Code-Analyse

Die Herausforderung

Unbekannte Substanz vor Signing

Die Käuferseite benötigte belastbare Aussagen zu Wartbarkeit, Sicherheitslage und Integrationsrisiken – ohne Zugriff auf alle Produktionsdaten.

Entwickler-Abhängigkeiten und undokumentierte Module waren im Data Room nur fragmentarisch beschrieben.

Board erwartete belastbare Szenarien statt pauschaler Einschätzung zur technischen Tragfähigkeit.

Wir mussten vor dem Signing wissen, ob die Codebasis tragfähig ist – nicht erst danach.

Delphi, Java und Batch-Nebenpfade

Die Anwendung vereinte mehrere Generationen: Desktop-Delphi, Java-Services und nächtliche Batch-Jobs. Schnittstellen waren teils undokumentiert.

Key-Person-Risiko war hoch, weil kritische Domänenlogik nur in wenigen Köpfen dokumentiert war.

Lizenz- und Dependency-Risiken waren im Data Room nicht vollständig aufgeschlüsselt.

Zielbild: Prioritätenmatrix für die ersten 12 Monate

Ein vertraulicher Report soll Risiken, Schulden und Integrationsaufwand quantifizieren – mit Szenarien Stabilisierung vs. Teilmodernisierung für Board und IT-Leitung.

Käufer will Kaufpreis und Integrationsbudget datenbasiert verhandeln.

Timeline für erste 12 Monate nach Closing muss belastbar sein.

Integrationsteam braucht klare Abhängigkeiten zwischen Security-Fixes und Modernisierung.

Verhandlungsteam will Heatmaps und CSV-Detailplanung neben Board-PDF.

M&A-Entscheider brauchen verständliche Zusammenfassung neben technischem Detail-Report.

Due-Diligence-Timeline erlaubt keine wochenlangen Analyse-Pausen vor Signing.

Verhandlungsteam will Heatmaps und CSV-Detailplanung neben Board-PDF für Kaufpreisverhandlung.

Integrationsteam braucht 90-Tage-Backlog mit Abhängigkeiten zwischen Security und Modernisierung.

Heatmaps zeigen Module mit hoher Key-Person-Abhängigkeit für Board und Verhandlungsteam.

Workshop mit IT-Leitung und Board schloss offene Risiken vor Signing ab.

CSV-Export ergänzt Board-PDF für Detailplanung des Integrationsteams nach Übernahme.

Unsere Lösung

Analyseartefakte

Mehrschichtige Analyse-Architektur

Statische Analyse, Architektur-Schnitte, Review kritischer Domänenpfade und Schätzung der Modernisierungsblöcke. Ergebnis als Prioritätenmatrix mit Aufwandsszenarien für die ersten 12 Monate nach Closing.

Vertraulicher Report ohne Produktionsdaten – geeignet für Board und Verhandlungsteam.

Methodik entlang Legacy-Code-Analyse; Modernisierungsimpulse in der Blog-Kategorie Legacy-Modernisierung.

Phase 1: Inventar und Security-Hotspots

SonarQube und Semgrep identifizieren Code- und Dependency-Risiken; ArchUnit prüft Schichtenverletzungen. Kritische Domänenpfade werden manuell nachverfolgt.

Team-Abhängigkeiten und Bus-Factor werden im Report benannt.

Undokumentierte Batch-Jobs und Schnittstellen erhalten Aufwandsschätzung und Risiko-Score.

Security-Hotspots werden nach Exploitability und Business-Impact priorisiert.

Phase 2: Roadmap-Szenarien und Aufwand

Drei Szenarien (Stabilisierung, schrittweise Modernisierung, Kernrewrite) mit Grob-Aufwand und Risiko. CSV/PDF-Export für Verhandlung und Budgetplanung.

Workshop mit IT-Leitung und Board schließt offene Risiken vor Signing ab.

Integration Backlog für die ersten 90 Tage ist mit Abhängigkeiten zwischen Security-Fixes und Modernisierung gemappt.

Due Diligence heißt: Risiken benennen – nicht schönreden.

Ergebnisse

Entscheidungsreife für Verhandlung und Budget

Das Management konnte Risiken gegen den Kaufpreis spiegeln und ein Integrationsteam priorisiert aufsetzen.

Security-Hotspots und Legacy-Module erhielten klare Prioritäten statt pauschaler „technische Schulden“-Formulierung.

Verhandlungsteam nutzte Aufwandsszenarien für Kaufpreisanpassung und Integrationsbudget.

Heatmaps zeigten Module mit hoher Bus-Factor-Abhängigkeit auf einen Blick.

Workshop schloss offene Risiken vor Signing mit IT-Leitung und Board ab.

CSV-Export ergänzt Board-PDF für Detailplanung des Integrationsteams.

Nachweisbare Lieferung innerhalb Timeline

Report und Workshop mit IT-Leitung und Board innerhalb der vereinbarten Due-Diligence-Frist.

Verhandlungsteam nutzte Aufwandsszenarien für Kaufpreisanpassung und Integrationsbudget.

Integration Backlog für 90 Tage nach Closing ist mit Abhängigkeiten dokumentiert.

Security-Hotspots erhielten Priorität vor kosmetischer Modernisierung.

Heatmaps zeigten Module mit hoher Bus-Factor-Abhängigkeit auf einen Blick für Verhandlungsteam und Board.

90-Tage-Integrations-Backlog ist mit Abhängigkeiten zwischen Security-Fixes und Modernisierung dokumentiert.

CSV-Detailplanung ergänzt Board-PDF für Integrationsteam und Verhandlung nach Closing.

Heatmaps zu Key-Person-Risiko und Modul-Komplexität unterstützen Kaufpreis- und Budgetentscheidungen.

Analyse durch Groenewold IT Solutions – strukturierte Legacy-Bewertung Made in Germany für M&A-Entscheidungen.

Analysemethodik

Statische Tools und Architektur-Schnitte

Automatisierte Scans ergänzen manuelle Reviews kritischer Pfade; Ergebnisse fließen in eine einheitliche Risiko-Matrix.

Delphi-, Java- und Batch-Pfade werden in einem gemeinsamen Inventar zusammengeführt.

Domänen und Integrationspunkte

Externe Schnittstellen, Batch-Jobs und Datenhaltung werden inventarisiert; undokumentierte Kopplungen erhalten Aufwandsschätzung.

Ergebnis und Nutzung

Prioritäten für Post-Closing

Die Matrix sortiert Maßnahmen nach Risiko, Aufwand und Business-Impact – Basis für das Integrationsteam in den ersten Monaten.

Vertraulichkeit und Formate

Board-tauglicher PDF-Report plus CSV für Detailplanung; keine Produktionsdaten erforderlich.

Workshop mit IT-Leitung und Board schließt offene Risiken vor Signing ab.

Workshop und Verhandlungsunterstützung

Board-Präsentation

Kernaussagen zu Risiko, Aufwand und Integrationspfad werden für nicht-technische Entscheider aufbereitet.

Heatmaps zeigen Module mit hoher Bus-Factor-Abhängigkeit und Security-Priorität.

Integration Backlog

Erste 90-Tage-Maßnahmen sind als priorisierter Backlog mit Grob-Schätzung enthalten.

Abhängigkeiten zwischen Stabilisierung, Security-Fixes und Teilmodernisierung sind explizit gemappt.

Board-taugliche Zusammenfassung ergänzt technischen Detail-Report und CSV-Export.

Delphi-, Java- und Batch-Pfade werden in einem gemeinsamen Inventar zusammengeführt.

Undokumentierte Kopplungen erhalten Aufwandsschätzung und Risiko-Score für Integrationsteam.

Verhandlung und Integrationsteam

Heatmaps und Bus-Factor

Heatmaps zeigen Module mit hoher Key-Person-Abhängigkeit für Board und Verhandlungsteam.

Integration Backlog für 90 Tage nach Closing ist mit Abhängigkeiten dokumentiert.

Workshop und Signing

Workshop mit IT-Leitung und Board schloss offene Risiken vor Signing ab.

CSV-Export ergänzt Board-PDF für Detailplanung des Integrationsteams.

Prioritätenmatrix quantifiziert Stabilisierung versus Teilmodernisierung für die ersten zwölf Monate.

Vertraulicher Report ohne Produktionsdaten eignet sich für Board und Verhandlungsteam.

Integration Backlog für neunzig Tage nach Closing ist mit Abhängigkeiten dokumentiert.

Features

Funktionen im Überblick

Code- und Architektur-Inventar
Security- und Dependency-Hotspots
Roadmap-Szenarien (Stabilisierung vs. Teilmodernisierung)
Vertraulicher Report für Board und IT-Leitung
Heatmaps für Bus-Factor und Security-Priorität pro Modul
90-Tage-Integrations-Backlog mit Grob-Schätzung
Workshop und Verhandlungsunterstützung innerhalb Due-Diligence-Timeline
Drei Szenarien Stabilisierung, Teilmodernisierung und Kernrewrite mit Grob-Aufwand

Häufige Fragen zur Legacy-Code-Analyse in der Due Diligence

Wie lange dauert eine Legacy-Code-Analyse für Due Diligence?

Typischerweise wenige Werktage bis etwa zwei Wochen – abhängig von Repository-Größe, Build-Komplexität und verfügbaren Zugängen. Vor Start klären wir den Scope (nur Code versus inklusive Betrieb und Schnittstellen) und liefern einen festen Zeitplan. Für eine kompakte Ersteinschätzung eignet sich auch die Legacy-Code-Analyse im Festpreis.

Welche Zugänge und Unterlagen werden für die Analyse benötigt?

Quellcode-Repositories, Build- und Deploy-Dokumentation, Abhängigkeitslisten, Schnittstellenübersicht und idealerweise Architektur-Skizzen. Produktionsdaten sind in der Regel nicht nötig; anonymisierte Staging-Umgebungen reichen für die meisten Risikoprüfungen. Fehlende Artefakte werden im Report als eigenes Risiko dokumentiert.

Welche technischen Risiken werden typischerweise identifiziert?

Wartbarkeit, fehlende Tests, veraltete Frameworks, Security-Hotspots, Lizenz- und Dependency-Risiken, Know-how-Konzentration und Integrationsengpässe. Das Ergebnis ist eine priorisierte Matrix – nicht nur eine Ampel. Für Modernisierungsentscheidungen liefert die Legacy-Modernisierung oft die nächsten Schritte nach der Analyse.

In welchem Format liegt der Analysebericht vor?

Als strukturierter Report mit Risikoklassen, Aufwandsszenarien für Stabilisierung, Teilmodernisierung und optional Rewrite sowie Empfehlungen für die ersten 12 Monate nach Closing. Zielgruppe sind Board, IT-Leitung und Verhandlungsteam – vertraulich und ohne unnötige Fachsprache. Ergänzend kann der Technical-Debt-Rechner erste Budgetrahmen liefern.

Wann reicht Analyse aus – wann ist ein Rewrite sinnvoller?

Analyse reicht, wenn der Bestand fachlich tragfähig ist und Modernisierung schrittweise möglich ist. Ein Rewrite wird eher empfohlen, wenn Architektur, Stack oder Testbarkeit die Weiterentwicklung dauerhaft blockieren – dann mit belastbarer Kostenschätzung statt Bauchgefühl. Zwischen Stabilisierung und Neuentwicklung vermittelt die Software-Rettung; größere Neuentwicklungen planen wir über individuelle Softwareentwicklung.

Transparenz zu dieser Case Study

Damit die Angaben oben einzuordnen sind, legen wir offen, um welche Art von Projekt es sich handelt, worauf die Ergebnisse beruhen und wer den Text fachlich geprüft hat. Mehr zu unserem Projektvorgehen und ein Überblick über allen Referenzprojekten.

Falltyp: Kundenprojekt, anonymisiert oder unter Projektnamen dargestellt – Reales Projekt; Firmenname, Branchendetails oder Einzelwerte sind auf Wunsch des Auftraggebers verallgemeinert.
Messgrundlage: Statische Codeanalyse und strukturierte Interviews: Risikoeinstufung der Module, Abhängigkeiten und Aufwandsschätzung für die ersten 90 Tage.
Erhebungszeitraum: Analysephase im Rahmen der Transaktionsprüfung
Datenquelle: Analyseergebnisse aus dem übergebenen Repository und Auskünfte des Entwicklungsteams; Auftraggeber vertraulich.
Einordnung: Kennzahlen sind gerundet und um identifizierende Details bereinigt; die Größenordnung bleibt erhalten.
Veröffentlichungsstatus: Nachweis im neuen Freigaberegister ausstehend
Freigabeumfang: Die bestehende anonymisierte Veröffentlichung bleibt erhalten; der fallbezogene Freigabenachweis ist im neuen Register noch nachzutragen.
Evidenznachweis: Interne Projektakte und anonymisierter Referenzdatensatz.
Fachliche Prüfung: Björn Groenewold, Geschäftsführer der Groenewold IT Solutions GmbH und der Hyperspace GmbH – zuletzt geprüft am 8. September 2026

Änderungshistorie

8. September 2026Evidenzangaben zur Case Study „Legacy-Code-Analyse für eine Due Diligence“ ergänzt: Falltyp, Messgrundlage, Datenquelle und fachliche Prüfung.
24. Februar 2026Ergebnisse und Lösungsbeschreibung der Case Study „Legacy-Code-Analyse für eine Due Diligence“ überarbeitet und die englische Fassung angeglichen.
1. Januar 2025Case Study „Legacy-Code-Analyse für eine Due Diligence“ veröffentlicht.

Legacy-Code-Analyse für Technologie-Due-Diligence