Wie man technische Schulden vor einer M&A Due Diligence findet

Bei jeder Akquisition gibt es zwei Bilanzen. Die finanzielle Bilanz wird von Buchhaltern, Anwälten und Beratern über Monate hinweg auf Herz und Nieren geprüft. Die technische Bilanz — der Zustand der Software, die oft das Produkt ist — wird häufig nur von einem Ingenieur überflogen, der zwei Tage Zeit und keine strukturierte Methodik hat.

So kommt es, dass Käufer am Ende Systeme mit sechsstelligen Sanierungskosten besitzen, für die niemand budgetiert hat.

Technische Schulden sind bei M&A keine Metapher. Sie sind ein echter Kostenfaktor. Jede ungepatchte CVE, jede undokumentierte Integration, jedes Modul, das nur eine Person versteht — all das übersetzt sich direkt in Kosten, Risiko und Zeitverzögerungen, sobald der Deal abgeschlossen ist. Die Frage ist, ob Sie dies entdecken, bevor der Preis festgelegt wird, oder danach.

Was eine Technical Due Diligence tatsächlich abdeckt

Eine gründliche technische Bewertung untersucht fünf Bereiche. Jeder Bereich liefert Erkenntnisse, die sich auf finanzielle Auswirkungen abbilden lassen.

1. Architektur und Skalierbarkeit

Worauf Sie achten: Kann dieses System die Wachstumspläne des Käufers unterstützen, oder muss es neu gebaut werden?

• Monolith vs. Services-Architektur. Ein Monolith ist nicht per se schlecht, aber er schränkt ein, wie schnell Sie einzelne Komponenten skalieren können. Wenn der Geschäftsplan von einem 10-fachen Wachstum ausgeht, muss das System dies unterstützen.
• Datenbankdesign. Normalisierte Schemata skalieren anders als denormalisierte. Ein Single-Database-Design, das Nutzerdaten, Analysen und Abrechnungen in einer einzigen PostgreSQL-Instanz mischt, wird einen signifikanten Anstieg des Traffics möglicherweise nicht überstehen.
• Infrastruktur. Läuft das System auf einem einzelnen Server? In einer Auto-Scaling-Gruppe? Auf Kubernetes? Die Lücke zwischen "es läuft" und "es läuft zuverlässig in großem Maßstab" ist oft ein Entwicklungsaufwand von sechs Monaten.

Finanzielle Auswirkungen: Architektureinschränkungen, die nach der Akquisition einen Rewrite oder ein größeres Refactoring erfordern, kosten typischerweise 100.000 € bis 500.000 € an Entwicklungszeit. Wird dies erst nach Vertragsabschluss entdeckt, geht das vom Integrationsbudget ab.

2. Sicherheitslage (Security Posture)

Worauf Sie achten: Wird dieses System ein Compliance-Audit bestehen, oder wird es eines auslösen?

• Abhängigkeits-CVEs. Führen Sie automatisierte Scans gegen jedes Paket im Abhängigkeitsbaum durch. Legacy-Systeme haben oft Dutzende von bekannten Schwachstellen — einige davon kritisch.
• Authentifizierung und Autorisierung. Wie werden Passwörter gehasht? Wie werden Sessions verwaltet? Gibt es Rate Limiting? Gibt es fehlerhafte Muster bei der Zugriffskontrolle?
• Secrets-Management. Werden API-Schlüssel, Datenbank-Zugangsdaten und Verschlüsselungscodes sicher aufbewahrt? Oder sind sie im Git-Verlauf (Git History) committet, in Quelldateien hardcodiert oder werden sie über Slack geteilt?
• Compliance-Bereitschaft. Wenn das Zielunternehmen Finanzdaten, Gesundheitsdaten oder personenbezogene Daten von EU-Bürgern verarbeitet: Ist es DSGVO-konform? SOC 2-ready? PCI DSS-zertifiziert?

Finanzielle Auswirkungen: Ein Sicherheitsvorfall im ersten Jahr nach der Akquisition ist ein Marken- und Haftungsrisiko für den Käufer. Die Behebung kritischer Sicherheitslücken kostet typischerweise 20.000 € bis 80.000 €. Die Nichteinhaltung von Vorschriften kann deutlich mehr kosten.

3. Code-Qualität und Wartbarkeit

Worauf Sie achten: Können die Entwickler des Käufers in dieser Codebase produktiv arbeiten, oder benötigen sie eine monatelange Einarbeitung?

• Komplexitätsmetriken. Zyklomatische Komplexität, Code-Duplizierung, Modulkopplung. Hohe Werte in einem dieser Bereiche sagen hohe Fehlerraten und eine langsame Entwicklungsgeschwindigkeit voraus.
• Testabdeckung. Nicht nur der Prozentsatz — die Qualität. Decken Tests geschäftskritische Pfade ab? Können Sie sie in der CI ausführen? Bestehen sie beständig?
• Dokumentation. Architecture Decision Records (ADR), API-Dokumentation, Deployment-Runbooks. Wenn diese nicht existieren, verlässt jedes Stück institutionelles Wissen das Unternehmen, wenn Mitarbeiter nach der Übernahme gehen.
• Toter Code. Ungenutzte Funktionen, auskommentierte Blöcke, ganze Dateien, die nie importiert werden. Toter Code ist nicht nur Unordnung — er ist ein Beweis für eine Codebase, die nicht gewartet wurde.

Finanzielle Auswirkungen: Eine geringe Code-Qualität wirkt sich direkt auf die Entwicklerproduktivität aus. Eine Codebase mit hoher Komplexität und ohne Tests wird die Feature-Entwicklung um 30–50 % verlangsamen im Vergleich zu einer gut gewarteten. Über ein Jahr hinweg bei einem 5-köpfigen Team und 100.000 €/Entwickler bedeutet das 150.000 € bis 250.000 € an Produktivitätsverlust.

4. Team- und Wissenskonzentration

Worauf Sie achten: Gibt es ein Busfaktor-Problem? Was passiert, wenn Schlüsselpersonen das Unternehmen verlassen?

• Busfaktor. Wie viele Personen verstehen jedes kritische System? Wenn die Antwort "eine" lautet, ist das ein Single Point of Failure, der bei Post-Acquisition-Übergängen (wenn die Mitarbeiterfluktuation am höchsten ist) kritisch wird.
• Contributor-Analyse. Eine Analyse des Git-Logs zeigt, wer welchen Code anfasst. Wenn 80 % der Commits in einem kritischen Modul von einer einzigen Person stammen, ist dieses Modul gefährdet.
• Einarbeitungszeit (Onboarding). Wie lange dauert es, bis ein neuer Entwickler seine erste sinnvolle Änderung ausliefert? Dies ist ein Indikator für Code-Qualität, Dokumentation und architektonische Klarheit.

Finanzielle Auswirkungen: Das Risiko durch Schlüsselpersonen ist eine der häufigsten Überraschungen nach einer Akquisition. Bindungspakete (Retention Packages) für kritische Entwickler kosten typischerweise 30.000 € bis 100.000 € pro Person. Wenn sie trotzdem gehen, sind die Kosten für die Wiederbeschaffung des Wissens meist noch höher.

5. Betriebliche Gesundheit (Operational Health)

Worauf Sie achten: Läuft dieses System zuverlässig, oder wird es durch manuelle Eingriffe zusammengehalten?

• Uptime und Vorfallshistorie. Wie oft fällt das System aus? Wie lange dauert die Wiederherstellung? Gibt es eine Rufbereitschaft (On-Call Rotation), oder klingelt jedes Mal das Telefon derselben Person?
• Deployment-Pipeline. Wie gelangen Änderungen in die Produktion? Automatisierte CI/CD mit Tests? Oder manuelle FTP-Uploads während Wartungsfenstern?
• Monitoring und Observability. Gibt es Dashboards? Alarme? Log-Aggregation? Oder erfährt das Team von Problemen erst, wenn Kunden anrufen?
• Backup und Disaster Recovery (DR). Wann wurde das letzte Backup testweise wiederhergestellt? "Wir haben Backups" und "wir können aus Backups wiederherstellen" sind zwei sehr unterschiedliche Aussagen.

Finanzielle Auswirkungen: Betriebliche Unreife — manuelle Deployments, kein Monitoring, kein Disaster Recovery — kostet 50.000 € bis 150.000 € in der Behebung und birgt ein anhaltendes Risiko, bis sie behoben ist.

Wie man technische Schulden quantifiziert

Die Erkenntnisse des Audits müssen in Zahlen übersetzt werden, die den Deal informieren. Wir verwenden ein einfaches Framework:

Diese Summe wird zu einem Verhandlungsinput. Wenn der geforderte Preis nicht 310.000 € an technischer Sanierung berücksichtigt, zahlt der Käufer zu viel.

Wann man es tun sollte

• Vor der Unterzeichnung des LOI (Letter of Intent), falls möglich. Die technische Bewertung informiert darüber, ob man überhaupt weitermachen sollte.
• Während der Exklusivitätsphase (Exclusivity) mindestens. Dies ist das Standardfenster für eine Due Diligence.
• Vor der Integrationsplanung. Die Erkenntnisse bestimmen den Zeitplan und das Budget für die Integration.

Der schlechteste Zeitpunkt, um technische Schulden zu entdecken, ist drei Monate nach Vertragsabschluss, wenn das Integrationsbudget festgelegt und der Zeitplan in Stein gemeißelt ist.

Wenn Sie im Rahmen eines M&A-Prozesses die Technologie eines Unternehmens bewerten — oder Ihr eigenes System auf eine mögliche Übernahme vorbereiten —, liefert ein System-Audit die strukturierte Bewertung, die aus "wir denken, der Code ist in Ordnung" evidenzbasierte Erkenntnisse mit Kostenschätzungen macht. Es ist ein Engagement von 2–3 Wochen, das Ihnen monatelange Überraschungen ersparen kann.