Enterprise Architektur

Technical Due Diligence: Was Investoren im Tech-Stack wirklich prüfen

Wie eine Technical Due Diligence abläuft, welche Findings Deals verzögern oder Kaufpreise drücken – und wie Sie Ihr Unternehmen 12 Monate vorher DD-fest machen. Aus der Praxis von Prüfungen auf Käufer- und Verkäuferseite.

📖 10 Min. Lesezeit
Technical Due Diligence Tech-DD M&A IT-Due-Diligence Technical Debt Key-Person-Risk Investoren Private Equity Architektur-Review Exit-Vorbereitung

Der Termin steht seit Wochen fest, das Management-Team hat die Pitch-Story perfektioniert, die Finanzkennzahlen sind aufbereitet. Dann stellt der technische Prüfer des Investors die dritte Frage: "Zeigen Sie mir bitte, wie ein Deployment bei Ihnen abläuft." Und plötzlich wird es still im Raum, weil das Deployment in Wahrheit darin besteht, dass der dienstälteste Entwickler freitags per Remote-Desktop Dateien auf den Produktionsserver kopiert.

Solche Momente entscheiden über Kaufpreise. Eine Technical Due Diligence (Tech-DD) ist der Stresstest, den jede Software-Gesellschaft durchläuft, sobald Kapital fließen soll – bei der Finanzierungsrunde, beim Verkauf an einen Strategen oder ein Private-Equity-Haus, zunehmend auch bei größeren Kreditlinien. Ich habe Tech-DDs auf beiden Seiten des Tisches begleitet: als Prüfer im Auftrag von Käufern und als Sparringspartner von Gesellschaftern und CTOs, die ihr Unternehmen auf den Prozess vorbereiten. Dieser Artikel beschreibt, was tatsächlich geprüft wird, welche Findings Deals gefährden – und wie Sie sich vorbereiten, idealerweise lange bevor ein Termsheet auf dem Tisch liegt.

Für wen dieser Artikel relevant ist: Gesellschafter, Geschäftsführer und CTOs von Software- und softwaregetriebenen Unternehmen, die in den nächsten 6–24 Monaten eine Finanzierungsrunde, einen (Teil-)Verkauf oder eine Nachfolgeregelung anstreben – sowie Investoren und Beiräte, die verstehen wollen, was hinter dem DD-Report steckt.

Was eine Tech-DD ist – und was sie nicht ist

Eine Tech-DD beantwortet dem Kapitalgeber im Kern vier Fragen:

  1. Trägt die Technologie den Business-Plan? Kann die Plattform das Wachstum der nächsten 3–5 Jahre stemmen – mehr Kunden, mehr Volumen, neue Märkte, neue Produkte?
  2. Wo liegen die Risiken? Technische Schulden, Abhängigkeiten von Einzelpersonen, veraltete Komponenten, Sicherheits- und Compliance-Lücken, Lizenzprobleme.
  3. Was kostet die Behebung? Jedes Finding wird in Aufwand und Zeit übersetzt – und landet als Investitionsbedarf im Bewertungsmodell oder als Bedingung im Kaufvertrag.
  4. Ist die Organisation reproduktionsfähig? Kann das Team ohne die Gründer-Generation weiterentwickeln, ausliefern und betreiben?

Was eine Tech-DD nicht ist: ein Code-Schönheitswettbewerb. Kein erfahrener Prüfer erwartet eine perfekte Architektur. Erwartet wird, dass das Management seine technischen Schulden kennt, bewertet und im Griff hat. Ein CTO, der auf die Frage nach den drei größten technischen Risiken souverän antwortet und einen plausiblen Abbaupfad zeigt, hinterlässt einen besseren Eindruck als einer, der behauptet, es gäbe keine. Bewusste, dokumentierte Trade-offs sind normal – überraschte Prüfer sind das Problem.

Die sechs Prüffelder – und die Findings, die wehtun

Der Zuschnitt variiert je nach Prüfer und Dealgröße, aber die Substanz ist erstaunlich konstant. Sechs Felder, jeweils mit den Findings, die in Reports regelmäßig als "rot" markiert werden:

1. Architektur und Skalierbarkeit

Geprüft wird, ob die Systemstruktur zum Business-Plan passt: Mandantenfähigkeit, Skalierungsgrenzen, Modularität, Abhängigkeitsstruktur. Die Methodik ähnelt einem klassischen Architektur-Review, nur mit Investitionsbrille.

Rote Findings: Single-Tenant-Architektur bei einem SaaS-Wachstumscase (jeder Neukunde ist ein manuelles Infrastruktur-Projekt). Skalierung nur vertikal ("größerer Server") bei geplanter Verzehnfachung des Volumens. Kernlogik in Komponenten, die niemand mehr anfassen kann.

2. Technische Schulden und Codebasis

Kein Prüfer liest Hunderttausende Zeilen Code. Geprüft wird stichprobenartig plus werkzeuggestützt: statische Analyse, Abhängigkeits-Scans, Alter und Support-Status der Frameworks, Testabdeckung, Hotspot-Analyse (wo ändert sich viel bei hoher Komplexität?).

Rote Findings: Frameworks jenseits des Supports (das klassische .NET Framework 4.x ohne Migrationsplan ist ein Dauergast in DD-Reports), keine automatisierten Tests in geschäftskritischen Modulen, Abhängigkeit von verwaisten Open-Source-Paketen. Wie Sie technische Schulden systematisch quantifizieren und priorisieren, habe ich im Artikel zum Technical-Debt-Management beschrieben – genau diese Aufbereitung ist es, die im DD-Prozess Souveränität signalisiert.

3. Delivery-Fähigkeit und Betrieb

Wie kommt Code in Produktion? Wie oft, wie sicher, wie reproduzierbar? Gibt es CI/CD, Infrastruktur als Code, Monitoring, ein geübtes Incident-Verfahren, getestete Backups?

Rote Findings: Manuelle Deployments mit Wochenend-Wartungsfenstern. Kein Staging, das Produktion ähnelt. Backups, deren Wiederherstellung noch nie geprobt wurde. Release-Zyklen von Monaten bei einem Business-Plan, der schnelle Produktiteration verspricht. Hier zahlt sich jede DevOps-Investition doppelt aus – sie ist gleichzeitig DD-Vorbereitung.

4. Team und Schlüsselpersonen-Risiko

Für viele Investoren das kritischste Feld, gerade im Mittelstand: Wie viele Menschen verstehen den Kern des Systems? Was passiert, wenn der langjährige Chefentwickler geht – oder der technische Gründer nach dem Exit die Motivation verliert?

Rote Findings: Der berühmte "Bus-Faktor 1" auf der Kernkomponente. Wissensmonopole ohne Dokumentation. Eine Organisation, in der der CTO jede Architekturentscheidung selbst trifft und jedes Release persönlich freigibt – was übrigens auch ein Führungsproblem ist, nicht nur ein DD-Problem.

5. Sicherheit und Compliance

Spätestens seit NIS2 und DORA ist dieses Feld von der Pflichtübung zum Deal-Faktor geworden, besonders bei Kunden in regulierten Branchen. Geprüft werden Zugriffskonzepte, Umgang mit Secrets, Patch-Prozesse, DSGVO-Basics (AVVs, Löschkonzepte, Datenflüsse), gegebenenfalls Pentest-Berichte.

Rote Findings: Produktionszugänge für alle Entwickler, API-Keys im Repository, personenbezogene Daten in Test-Umgebungen, keine dokumentierten Auftragsverarbeitungsverhältnisse. Vieles davon ist mit überschaubarem Aufwand behebbar – aber nicht in den zwei Wochen zwischen Termsheet und Report.

6. Lizenz- und IP-Sauberkeit

Wem gehört der Code? Sind alle Beiträge von Freelancern vertraglich übertragen? Welche Open-Source-Lizenzen stecken im Produkt – und sind Copyleft-Komponenten (GPL & Co.) sauber gekapselt? Die jüngste Kommerzialisierungswelle im .NET-Ökosystem hat hier eine neue Facette ergänzt: Prüfer fragen inzwischen auch nach Lizenz-Exposure bei Paketen, die ihr Lizenzmodell gewechselt haben.

Rote Findings: Fehlende IP-Übertragung von früheren Freelancern (im schlimmsten Fall ein Deal-Breaker, weil die Chain of Title zum Kernasset unterbrochen ist), ungeklärte GPL-Nutzung im proprietären Produkt, KI-generierter Code ohne geregelte Richtlinie – Letzteres wird von Prüfern zunehmend explizit abgefragt.

Wie der Prozess abläuft – und warum Zeit Ihr Gegner ist

Eine typische Tech-DD im Mittelstands-Segment dauert zwei bis sechs Wochen und läuft in drei Schritten: Dokumentenanalyse (Architektur-Übersichten, Team-Struktur, Prozessbeschreibungen, Lizenz-Inventar über den Datenraum), Management-Sessions (strukturierte Interviews mit CTO, Lead-Entwicklern, teils Live-Demos von Deployment und Monitoring) und technische Stichproben (Code-Einsicht, Werkzeug-Scans, gelegentlich Zugriff auf Repositories und Pipelines).

Zwei Dinge unterschätzen Verkäuferseiten regelmäßig:

Erstens die Signalwirkung der Reaktionsgeschwindigkeit. Wenn die Anforderungsliste des Prüfers drei Wochen unbeantwortet bleibt, weil niemand weiß, wo die Architektur-Dokumentation liegt, ist das selbst ein Finding – es zeigt, dass die Organisation ihre eigene Technologie nicht auskunftsfähig verwaltet.

Zweitens die Parallelbelastung. Die DD trifft genau die Personen, die auch das Tagesgeschäft tragen: CTO und Lead-Entwickler. Wer unvorbereitet in den Prozess geht, bezahlt mit Wochen an Führungskapazität mitten in der heißesten Phase des Deals – und mit genervten Schlüsselpersonen, deren Bindung gerade jetzt entscheidend wäre.

DD-Readiness: Die Vorbereitung, die sich immer lohnt

Der beste Zeitpunkt für die Vorbereitung ist 12–18 Monate vor dem geplanten Ereignis. Nicht, weil man so lange für Dokumente braucht – sondern weil substanzielle Findings (Framework-Migration, Bus-Faktor, Testabdeckung) Zeit zur Behebung brauchen. Das Vorgehen, das ich mit Mandanten durchlaufe:

Schritt 1: Selbst-Audit mit Käuferbrille. Eine interne Prüfung entlang der sechs Felder oben, idealerweise mit externem Blick – die eigene Betriebsblindheit ist bei diesem Thema strukturell. Ergebnis ist eine priorisierte Findings-Liste, wie sie auch ein Prüfer erstellen würde. Alles, was Sie selbst finden, kann Sie später nicht überraschen.

Schritt 2: Rote Findings mit Hebelwirkung beheben. Nicht alles muss perfekt werden. Priorität haben Findings, die (a) als Deal-Breaker taugen (IP-Ketten, ungeklärte Copyleft-Nutzung), (b) hohe Bewertungsabschläge auslösen (End-of-Life-Kernkomponenten ohne Plan, Bus-Faktor 1) oder (c) mit wenig Aufwand viel Signal bringen (Secrets aus dem Repo, Backup-Restore-Test, Deployment-Automatisierung).

Schritt 3: Das erzählbare Narrativ bauen. Für alles, was bewusst nicht behoben wird, braucht es eine ehrliche, dokumentierte Einordnung: "Wir kennen das, hier ist die Risikobewertung, hier der Abbaupfad, das kostet X und ist für Q3 geplant." Ein DD-Prozess bestraft nicht Schulden – er bestraft Überraschungen und Ahnungslosigkeit.

Schritt 4: Den Datenraum vorab befüllen. Architektur-Übersicht (aktuell, nicht die von 2019), Systeminventar mit Support-Status, Lizenz-Inventar (werkzeuggestützt generiert), Team-Matrix mit Wissensverteilung, Prozessdokumentation für Release und Incident. Wer diese Artefakte am ersten Tag liefert, setzt den Ton für den gesamten Prozess.

Ein positiver Nebeneffekt, den ich immer wieder beobachte: DD-Readiness ist verkleidete Ingenieurs-Hygiene. Fast alles auf dieser Liste – Automatisierung, Dokumentation, Wissensverteilung, Abhängigkeits-Management – macht das Unternehmen auch dann besser, wenn der Deal nie kommt.

Für die Käuferseite: Drei Fragen, die Reports oft nicht beantworten

Wenn Sie auf der Investorenseite sitzen und einen Tech-DD-Report lesen, lohnen drei Nachfragen, die über Standard-Findings hinausgehen:

  1. Wie ist die Änderungsfähigkeit, nicht nur der Zustand? Ein System mit Schulden, aber sauberem Delivery-Prozess und lernfähigem Team ist ein besseres Investment als ein aufgeräumtes System mit versteinerter Organisation. Fragen Sie nach Lead Time und Release-Frequenz der letzten 12 Monate, nicht nur nach dem Architekturdiagramm.
  2. Was passiert in den ersten 100 Tagen nach Closing? Ein guter Report priorisiert Findings zu einem umsetzbaren Post-Deal-Plan mit Budget – sonst ist er eine Mängelliste ohne Handlungswert.
  3. Hängt die Wertthese an Personen, die nach dem Deal gehen könnten? Retention der technischen Schlüsselpersonen gehört in die Deal-Struktur, nicht in die Hoffnung.

Fazit

Eine Technical Due Diligence ist kein Examen, das man besteht oder nicht besteht – sie ist eine Verhandlung über Risiko und Preis, und Vorbereitung verschiebt beide zu Ihren Gunsten. Die Essenz:

  1. Prüfer bestrafen Überraschungen, nicht Schulden. Wer seine Risiken kennt, bewertet und mit Abbaupfad präsentiert, verhandelt aus einer anderen Position.
  2. Die harten Findings brauchen Vorlauf. IP-Ketten, End-of-Life-Migrationen und Bus-Faktor-Probleme löst niemand zwischen Termsheet und Signing. 12–18 Monate Vorlauf sind der Unterschied zwischen Gestaltung und Schadensbegrenzung.
  3. Delivery-Fähigkeit schlägt Architektur-Ästhetik. Die überzeugendste Antwort auf fast jede Prüferfrage ist ein automatisierter, beobachtbarer, reproduzierbarer Weg von der Codezeile zur Produktion.
  4. DD-Readiness lohnt sich auch ohne Deal. Alles, was den Prüfer überzeugt, macht das Unternehmen robuster, schneller und unabhängiger von Einzelpersonen.

Nächste Schritte

← Zurück zu allen Publikationen