Tech Due Diligence für M&A: Code, Architektur, Sicherheit, Team

Warum Tech Due Diligence bei M&A entscheidend ist

Bei Fusionen und Übernahmen ist Technologie häufig entweder der größte Werttreiber oder ein verborgenes Risiko, das erst nach Vertragsunterzeichnung sichtbar wird. Tech Due Diligence (TDD) verfolgt ein zentrales Ziel: technologische Risiken und Kosten zu identifizieren, bevor sie zu Problemen werden, und zu bewerten, ob Produkt und Engineering-Organisation in der Lage sind, nach der Transaktion weiteres Wachstum zu tragen.

Eine professionell durchgeführte TDD ist nicht nur ein Code-Audit. Sie umfasst die Bewertung von:

• Qualität und Wartbarkeit der Lösung
• Architektur und Skalierbarkeit
• Sicherheit und Compliance
• Reifegrad von DevOps und Betrieb
• Kompetenz und Stabilität des Teams
• sowie der realen Kosten: technischer Schulden, Migrationen, Refactorings und Wartung

Nachfolgend finden Sie eine praxisnahe Checkliste als Grundlage für eine Tech Due Diligence – sowohl beim Erwerb eines Produktunternehmens (SaaS) als auch bei der Bewertung eines Software-„Build-ups“ innerhalb eines größeren Unternehmens.

Umfang und Kontext (bevor der Code geprüft wird)

Ziel: Verstehen, was erworben wird und wie die Technologie das Geschäft unterstützt (oder behindert).

• Welche zentralen Produkte/Systeme gibt es (Kernsysteme vs. unterstützende Systeme)?
• Welche kritischen Geschäftsprozesse werden durch das System unterstützt?
• Wie sieht das Erlösmodell aus und welche Teile der Plattform sind umsatzkritisch?
• Welche Komponenten stellen Single Points of Failure dar?
• Wie sieht die Roadmap aus und welche Verpflichtungen bestehen gegenüber Kunden (SLA, Verträge)?
• Welche Abhängigkeiten bestehen zu Anbietern (Cloud, Lizenzen, Drittservices)?

Ergebnis: Eine Systemlandkarte mit priorisierten Risiken – also eine klare Definition, wo die TDD besonders tief analysieren sollte.

Codebasis & Engineering-Qualität

Ziel: Bewertung von Wartbarkeit, Regressionsrisiko und Kosten der Weiterentwicklung.

Repository-Struktur und Code-Hygiene

• Haben Repositories eine klare Struktur und definierte Verantwortlichkeiten?
• Gibt es Coding-Standards, Code-Review-Prozesse und einen Style Guide?
• Besteht Konsistenz bei Benennung, Modularität und Schichtentrennung?
• Wie hoch sind die technischen Schulden (TODO/FIXME, Legacy-Module, „Hot Spots“)?

Testing und Qualitätssicherung

• Welche Testarten existieren (Unit-/Integrations-/E2E-Tests)?
• Wie hoch ist die tatsächliche Abdeckung kritischer Pfade (nicht nur %-Werte)?
• Sind Tests stabil (keine „flaky tests“) und in CI integriert?
• Wie häufig treten Regressionen nach Deployments auf?

Abhängigkeiten und Schwachstellen

• Werden Abhängigkeiten regelmäßig aktualisiert?
• Gibt es einen Prozess zum Management von Sicherheitslücken (SCA)?
• Werden End-of-Life-Komponenten (Frameworks/Bibliotheken ohne Support) verwendet?

Technische Dokumentation

• Gibt es ein aussagekräftiges README, Runbooks und Contribution-Guidelines?
• Sind Architekturentscheidungen dokumentiert (ADR)?
• Kann ein neuer Entwickler in angemessener Zeit eingearbeitet werden?
  
  

Red Flags: Keine Tests, kein CI, starkes Abhängigkeitswissen einzelner Personen, manuelle Deployments, viele kritische Sicherheitslücken.

Architektur & Skalierbarkeit

Ziel: Bewertung, ob das System Wachstum bewältigen kann und wie aufwendig Integration oder Modernisierung sein werden.

Anwendungsarchitektur

• Monolith oder Microservices – und ist die Wahl begründet?
• Sind fachliche Grenzen (Bounded Contexts) klar definiert?
• Wie werden Datenkonsistenz und Transaktionen gehandhabt?
• Wo liegen Engpässe (eine Datenbank, ein Service, eine Queue)?

Datenarchitektur

• Welche Datenbanken werden verwendet und warum – und werden sie angemessen eingesetzt?
• Gibt es Caches, Indizes und Query-Optimierungen?
• Bestehen Probleme mit Datenqualität, Duplikaten oder Inkonsistenzen?
• Gibt es Datenpipelines/Integrationen und wie werden sie gewartet?

Performance und Zuverlässigkeit

• Gibt es definierte SLOs/SLAs und reale Uptime-Metriken?
• Wie sieht die Observability aus (Logs, Metriken, Traces)?
• Gibt es einen Disaster-Recovery-Plan (DR), Backups und Wiederherstellungstests?
• Wie reagiert das System auf Lastspitzen?

Integrationen und Abhängigkeiten

• Welche Integrationen sind geschäftskritisch (Zahlungen, ERP/CRM, Provider)?
• Wie robust ist das System bei Ausfällen von Anbietern (Retries, Circuit Breaker)?
• Wie werden API-Versionen und Abwärtskompatibilität gemanagt?

Red Flags: Kein Monitoring, keine DR-Tests, keine Skalierungsstrategie, „zufällige“ Architektur, Abhängigkeit von einer einzelnen nicht redundanten Komponente.

Sicherheit & Compliance

Ziel: Bewertung des Vorfallrisikos, der Audit-Fähigkeit und der Auswirkungen auf die Transaktion.

IAM und Zugriff

• Gibt es SSO/MFA? Wie werden Berechtigungen verwaltet?
• Gibt es gemeinsame Accounts und fehlende Nachvollziehbarkeit?
• Ist der Zugriff auf Produktion kontrolliert und protokolliert?
  
  

Secrets und Schlüssel

• Werden Secrets in einem Vault/Secret Manager oder im Code gespeichert?
• Wie erfolgt die Rotation von Schlüsseln und wer hat Zugriff?
  
  

Anwendungssicherheit

• Sind SAST/DAST/SCA in CI/CD integriert?
• Werden regelmäßige Penetrationstests durchgeführt?
• Wie werden Schwachstellen und Patches gemanagt?
  
  

Daten und Datenschutz

• Wie werden sensible Daten (PII) geschützt?
• Sind Daten im Ruhezustand und bei Übertragung verschlüsselt?
• Gibt es Richtlinien zur Daten- und Log-Aufbewahrung?
  
  

Vorfälle und Betriebsbereitschaft

• Gab es Sicherheitsvorfälle und wie wurde reagiert?
• Gibt es einen Incident-Response-Plan (IRP) und regelmäßige Übungen?
• Besteht ein Monitoring zur Anomalieerkennung?

Red Flags: Secrets im Repository, kein MFA, kein Patch-Prozess, kein Schwachstellenmanagement, keine Audit-Logs.

DevOps, Cloud & Betrieb

Ziel: Bewertung, ob das Unternehmen Systeme sicher deployen und betreiben kann.

• Gibt es CI/CD? Wie sieht der Release-Prozess aus?
• Ist die Infrastruktur als Code (IaC) definiert?
• Sind Umgebungen (Dev/Stage/Prod) reproduzierbar?
• Wie funktionieren Monitoring und Alerting?
• Gibt es Runbooks und Incident-Response-Prozesse?
• Wie werden Betriebskosten gesteuert (FinOps-Praxis)?

Red Flags: Manuelle Deployments, „Click-Ops“-Infrastruktur, keine Rollback-Strategie, keine Non-Prod-Umgebungen, starke Abhängigkeit von wenigen Schlüsselpersonen.

Team & Engineering-Organisation

Ziel: Bewertung der Fähigkeit, Technologie nach der Übernahme weiterzuentwickeln und zu betreiben.

Struktur und Kompetenzen

• Welche Rollen sind vorhanden (Backend/Frontend/QA/DevOps/Data/Security)?
• Gibt es starke technische Führungskräfte und klare Entscheidungsprozesse?
• Wie ist das Produktmanagement organisiert und wie wird das Backlog gepflegt?
  
  

Stabilität und Personalrisiken

• Wo liegen Single Points of Knowledge?
• Wie hoch ist die Fluktuation und wie stark ist die Abhängigkeit von externen Dienstleistern?
  Gibt es strukturierte Onboarding-Prozesse und Dokumentation?
  
  

Engineering-Kultur

• Gibt es Code Reviews, Qualitätsstandards und Tests?
• Wie werden technische Schulden gemanagt?
• Gibt es Retrospektiven und kontinuierliche Verbesserung?

Red Flags: Kein QA/DevOps, keine technische Führung, Wissen in wenigen Köpfen gebündelt, hohe Fluktuation, chaotisches Backlog.

Lizenzen, IP & rechtliche Risiken (oft übersehen)

Ziel: Bewertung von IP-Risiken und Lizenzkosten.

• Besitzt das Unternehmen die Rechte am Code (Verträge mit Mitarbeitern und Auftragnehmern)?
• Welche Open-Source-Lizenzen werden genutzt und sind sie compliant (z. B. Copyleft)?
• Gibt es kommerzielle Komponenten mit Eskalationsrisiko bei Lizenzkosten?
• Sind Patente oder Dritt-IP im Produkt enthalten?
  
  

Wie ein gutes Tech Due Diligence-Ergebnis aussieht

Eine gute TDD endet nicht nur mit einer Problemliste, sondern mit einer Entscheidungsgrundlage:

• Kritische Risiken (Deal Breaker) – z. B. gravierende Sicherheitslücken, fehlende IP-Rechte, mangelnde Skalierbarkeit.
• Wesentliche Risiken (bewertungsrelevant) – technische Schulden, notwendige Migrationen, DevOps-Lücken.
• Operative Risiken (Integrationsplanung) – Prozesse, Team, Monitoring, Onboarding.
• 30/60/90-Tage-Aktionsplan nach Closing – erste Schritte zur Stabilisierung.
• Kosten- und Aufwandsabschätzung – was erforderlich ist, um die Technologie auf „Standard“ zu bringen.
  
  

Wie Altimi unterstützen kann: Tech Due Diligence als Partnerschaft

Im Partnerschaftsmodell endet Tech Due Diligence nicht mit einem Bericht. Der eigentliche Mehrwert entsteht, wenn das Audit direkt in die Umsetzung übergeht: Stabilisierung, Modernisierung, Sicherheitsverbesserungen und Delivery-Optimierung.

Altimi unterstützt Organisationen in der Praxis bei:

• Analyse von Architektur und Codequalität
• Bewertung und Implementierung von DevOps/CI/CD, IaC und Observability
• Erhöhung des Cybersecurity-Niveaus (IAM, Secrets-Management, Scanning, Prozesse)
• Bewertung der Team-Reife und organisatorischen Empfehlungen‍
• Umsetzung von Remediation-Plänen im Consulting-, Managed-Services- oder BOT-Modell