Ein Produkt kann starke Umsätze, überzeugende Retention und ein präzises Marktprofil zeigen - und dennoch technisch auf einem Fundament stehen, das Wachstum ausbremst. Genau hier setzt ein Leitfaden für technische Due Diligence an: Er trennt skalierbare digitale Substanz von kurzfristig funktionierender Oberfläche. Für Käufer, Investoren und Führungsteams ist das keine rein technische Prüfung. Es ist eine Entscheidung über Geschwindigkeit, Risiko und den realen Wert eines digitalen Geschäftsmodells.
Bei einer Plattform, einem SaaS-Produkt oder einem datengetriebenen Geschäftsmodell steckt ein relevanter Teil des Unternehmenswerts in Architekturentscheidungen, Codequalität, Datenflüssen und operativer Lieferfähigkeit. Diese Faktoren lassen sich nicht zuverlässig anhand eines Produktdemos oder einer Liste eingesetzter Technologien beurteilen. Entscheidend ist, ob das System unter Last, bei Wachstum und nach einem Ownership-Wechsel weiterhin kontrollierbar bleibt.
Was technische Due Diligence tatsächlich bewertet
Technische Due Diligence untersucht nicht, ob ein Team einen modernen Framework-Namen nennen kann. Sie beantwortet eine härtere Frage: Kann das Unternehmen seine digitale Leistung langfristig liefern, weiterentwickeln und wirtschaftlich skalieren?
Dafür werden technische Risiken immer im Verhältnis zum Geschäftsmodell gelesen. Eine monolithische Anwendung ist nicht automatisch ein Problem. Für ein fokussiertes Produkt mit klarer Roadmap kann sie schneller, günstiger und besser wartbar sein als eine früh aufgeteilte Microservice-Landschaft. Kritisch wird sie, wenn Releases voneinander abhängige Bereiche destabilisieren, Teams nicht parallel arbeiten können oder einzelne Ausfälle das gesamte Geschäft unterbrechen.
Auch technischer Debt ist nicht per se negativ. Jedes wachstumsorientierte Unternehmen trifft Abkürzungen. Relevanz entsteht dort, wo diese Abkürzungen die Produktroadmap, die Sicherheit oder die Fähigkeit zur Integration nach einer Transaktion einschränken. Eine gute Prüfung beziffert deshalb nicht nur Mängel, sondern ihre geschäftliche Konsequenz.
Leitfaden für technische Due Diligence: Die Prüfbereiche
Der Umfang hängt von Transaktionsgröße, Datenkritikalität und Reife des Produkts ab. Die folgenden Bereiche bilden jedoch den Kern einer belastbaren Analyse.
Architektur und Skalierbarkeit
Die Architektur zeigt, ob ein digitales Produkt planbar wachsen kann. Geprüft wird, wie Frontend, Backend, Datenbanken, APIs, Drittanbieter und Hintergrundprozesse zusammenspielen. Besondere Aufmerksamkeit verdienen zentrale Abhängigkeiten: Gibt es einzelne Dienste, Personen oder externe Anbieter, deren Ausfall den Betrieb unmittelbar gefährdet?
Skalierbarkeit bedeutet dabei mehr als zusätzliche Serverkapazität. Ein System muss Lastspitzen bewältigen, Daten sauber verarbeiten und neue Produktfunktionen ermöglichen, ohne bestehende Prozesse zu brechen. Relevant sind reale Nutzungs- und Performance-Daten, nicht allein hypothetische Kapazitätsversprechen. Wenn die nächste Wachstumsphase eine grundlegende Neugestaltung der Datenhaltung verlangt, gehört dieser Aufwand in die Kaufpreislogik und in den Integrationsplan.
Codebasis, Entwicklungsprozess und Lieferfähigkeit
Codequalität lässt sich nicht seriös an Codezeilen oder an einer pauschalen Bewertung wie „sauber“ messen. Aussagekräftiger sind Struktur, Testabdeckung an kritischen Stellen, Dokumentation, Abhängigkeitsmanagement und die Verständlichkeit zentraler Geschäftslogik.
Ebenso wichtig ist der Weg vom Ticket in die Produktion. Gibt es Code Reviews, automatisierte Tests, nachvollziehbare Deployment-Prozesse und eine klare Trennung der Umgebungen? Oder erfolgen Releases manuell, unter Zeitdruck und mit direktem Zugriff auf Live-Systeme? Ein Produkt kann heute stabil wirken und dennoch teuer werden, wenn jede Änderung über wenige Schlüsselpersonen läuft.
Besonders genau sollte die Prüfung bei proprietären Kernfunktionen sein. Sind Preislogik, Berechtigungen, Workflows oder Datenmodelle nachvollziehbar implementiert? Oder liegen entscheidende Regeln verteilt in Skripten, Tabellen und nicht versionierten Konfigurationen? Diese Details bestimmen, wie schnell ein neues Team das System übernehmen und weiterentwickeln kann.
Sicherheit, Datenschutz und Resilienz
Sicherheitsrisiken sind im M&A-Kontext selten nur ein Thema der IT-Abteilung. Sie betreffen Haftung, Reputation, Vertragsfähigkeit und die Kontinuität des Geschäfts. Geprüft werden unter anderem Zugriffsrechte, Identitätsmanagement, Geheimnisverwaltung, Verschlüsselung, Protokollierung und der Umgang mit Schwachstellen.
Bei personenbezogenen oder geschäftskritischen Daten reicht eine Datenschutzerklärung nicht aus. Relevant ist, wo Daten gespeichert werden, welche Systeme darauf zugreifen, wie Löschkonzepte umgesetzt sind und ob Auftragsverarbeitungen nachvollziehbar dokumentiert wurden. Gerade schnell gewachsene Produkte haben hier oft eine Lücke zwischen formaler Absicht und technischer Realität.
Resilienz umfasst zusätzlich Backups, Wiederherstellungsfähigkeit, Monitoring und Incident Response. Ein Backup ist kein Schutz, wenn es nie getestet wurde. Ein Monitoring-Tool liefert keinen Nutzen, wenn niemand für Alerts verantwortlich ist. Die entscheidende Frage lautet: Wie schnell erkennt und behebt das Unternehmen einen Ausfall, ohne Kunden, Daten oder Umsatz unnötig zu gefährden?
Daten, Integrationen und Abhängigkeiten
Digitale Geschäftsmodelle leben häufig von Integrationen: Zahlungsanbieter, CRM, ERP, Analytics, KI-Services, Messaging, Identity Provider oder branchenspezifische Datenquellen. Jede dieser Schnittstellen kann strategische Beschleunigung bringen, aber auch Abhängigkeiten erzeugen.
In der technischen Due Diligence wird geprüft, ob APIs stabil angebunden sind, Fehlerfälle verarbeitet werden und es realistische Alternativen gibt. Ein einzelner externer Dienst ist nicht grundsätzlich riskant. Problematisch wird er, wenn Vertragslaufzeiten, Preismodelle, Datenzugriff oder technische Limits die Produktstrategie dominieren.
Auch die Datenqualität verdient Aufmerksamkeit. Doppelte Kundendatensätze, unklare Datenverantwortung und historisch gewachsene Datenmodelle bremsen Personalisierung, Reporting und Automatisierung. Wer ein datengetriebenes Unternehmen kauft, sollte verstehen, ob die entscheidenden Kennzahlen reproduzierbar sind - und ob die Datenbasis künftige KI- oder Automatisierungsprojekte überhaupt trägt.
Team, Wissen und operative Ownership
Technologie ist immer auch eine Frage der Organisation. Ein kleines, starkes Team kann hoch effizient arbeiten. Das Risiko entsteht, wenn Wissen ausschließlich in den Köpfen einzelner Entwickler, Gründer oder externer Dienstleister liegt.
Die Prüfung sollte daher Verantwortlichkeiten, Dokumentationsniveau, Onboarding-Fähigkeit und Vendor-Verträge einbeziehen. Sind Repositories, Cloud-Konten, Domains, Zertifikate und Produktionszugänge rechtlich und operativ im Besitz des Unternehmens? Gibt es klare Übergaben? Und kann ein neuer technischer Lead innerhalb weniger Wochen verstehen, wie das System funktioniert?
Diese Fragen wirken operativ, sind aber finanziell relevant. Fehlende Ownership führt nach einer Transaktion oft zu Verzögerungen, teuren Übergangsvereinbarungen und einer Roadmap, die länger stillsteht als geplant.
So wird aus Befunden eine Entscheidungsgrundlage
Eine Due Diligence verliert an Wert, wenn sie als lange Mängelliste endet. Entscheider brauchen Prioritäten. Jeder Befund sollte deshalb vier Punkte klar machen: das konkrete Risiko, die geschäftliche Auswirkung, den Aufwand zur Behebung und den notwendigen Zeitpunkt.
Ein kritisches Sicherheitsproblem mit möglichem Datenabfluss braucht eine unmittelbare Maßnahme. Eine unmoderne, aber stabile Komponente kann dagegen bewusst weiterbetrieben werden, solange sie die Roadmap nicht blockiert. Zwischen diesen Polen liegt die eigentliche Arbeit: Risiken sauber einordnen, statt Architekturideale auf ein bestehendes Geschäft zu projizieren.
Ein überzeugender Bericht unterscheidet zudem zwischen Deal Breakern, kaufpreisrelevanten Investitionen und Optimierungspotenzial. Das schafft eine realistische Grundlage für Verhandlung, Post-Merger-Planung und die ersten 100 Tage nach Closing. Die beste technische Empfehlung ist nicht zwangsläufig die aufwendigste, sondern diejenige mit dem stärksten Effekt auf Wertschöpfung und Risikoreduktion.
Der richtige Ablauf unter Zeitdruck
Technische Due Diligence muss häufig in wenigen Wochen belastbare Klarheit schaffen. Das gelingt nur mit einem fokussierten Prozess. Am Anfang stehen Produktstrategie, Umsatzlogik und Wachstumsplan. Erst dann lässt sich entscheiden, welche technischen Fragen wirklich kritisch sind.
Danach folgen strukturierte Interviews mit Produkt, Engineering und Operations sowie die Sichtung von Architekturunterlagen, Repositories, Infrastrukturkonfigurationen, Sicherheitsnachweisen und Betriebsdaten. Ein reiner Dokumentencheck reicht nicht. Viele Risiken werden erst sichtbar, wenn Aussagen aus Interviews mit tatsächlichen Deployments, Tickets, Monitoring-Daten oder Zugriffsmodellen abgeglichen werden.
Zum Abschluss sollte das Zielsystem nicht nur bewertet, sondern in eine umsetzbare Roadmap übersetzt werden. Dazu gehören Verantwortlichkeiten, grobe Budgets, Abhängigkeiten und Quick Wins. Für Unternehmen mit komplexen Plattformen oder individuellen Software-Systemen ist diese Verbindung aus technischer Tiefe, Produktverständnis und klarer Strategie entscheidend.
Wer eine Transaktion vorbereitet, sollte technische Due Diligence deshalb nicht als Pflichttermin kurz vor Signing behandeln. Je früher Architektur, Daten und operative Ownership transparent werden, desto präziser lassen sich Preis, Integrationsaufwand und Wachstumsversprechen beurteilen. Gute Entscheidungen entstehen nicht aus einer perfekten Codebasis, sondern aus einer klaren Sicht darauf, was erhalten, verbessert oder bewusst neu gebaut werden muss.