Technische Due Diligence: Was Investoren und Käufer übersehen

75 % der Investoren zählen die digitale Reife inzwischen zu den Top-3-Treibern für den Unternehmenswert.Diese Zahl stammt aus dem Global Private Equity Report 2025 von Bain. Dies bedeutet, dass Technologie bei Übernahmen kein Backoffice-Problem mehr darstellt; es ist ein primärer Bewertungshebel.

Und doch erfolgen die meisten technischen Due-Diligence-Prüfungen zu spät, decken zu wenig ab und übersehen die Risiken, die nach dem Abschluss explodieren. Das Standard-Playbook beauftragt einen Junior-Analysten, Architekturdiagramme zu überfliegen, auf Verstöße gegen Open-Source-Lizenzen zu prüfen und ein 40-seitiges PDF zu erstellen, das niemand liest, bis etwas kaputt geht.

In diesem Artikel erfahren Sie, wie ein gründlicher technischer DD-Prozess aussieht, wo die meisten Überprüfungen mangelhaft sind und welche spezifischen Bereiche Sie vor der Unterzeichnung bewerten sollten.

Warum technische DD heute wichtiger ist als vor fünf Jahren

Vor fünf Jahren konnte ein PE-Unternehmen, das ein Unternehmen mit einem Umsatz von 50 Millionen US-Dollar erwarb, den Tech-Stack als Einzelposten behandeln. Wenn das Produkt funktionierte, war der Code „gut genug“. Der Wert lag in Umsatz, Kundenverträgen und Markenwert.

Dieses Kalkül hat sich verschoben. SaaS-Multiplikatoren schrumpfen, wenn Käufer technische Schulden entdecken, deren Behebung 12 bis 18 Monate dauert. Die Integrationszeitpläne verdoppeln sich, wenn APIs nicht dokumentiert oder eng an einen einzelnen Anbieter gekoppelt sind. Die Cloud-Kosten steigen, wenn die Infrastruktur durch Vermutungen statt durch Lasttests bereitgestellt wird. Diese Überraschungen untergraben die Wertthese, die den Kaufpreis rechtfertigte.

Das ergab eine McKinsey-Studie aus dem Jahr 202440 % der Technologietransformationen nach der Übernahme überschreiten ihr ursprüngliches Budget um mehr als 50 %. Die Hauptursache sind in den meisten Fällen Risiken, die bereits vor Abschluss bestanden, aber bei der Due-Diligence-Prüfung nicht identifiziert wurden.

Die fünf versteckten Risiken, die Standard-DD-Bewertungen übersehen

1. Fragile Architektur unter Last

Das Produkt funktioniert bei dem aktuellen Verkehrsaufkommen einwandfrei. Die Akquisitionsthese geht jedoch von einem dreifachen Wachstum über 24 Monate aus. Wird die Architektur damit umgehen? Die meisten DD-Rezensionen beantworten diese Frage nie, weil sie sie nie testen. Sie überprüfen Diagramme. Sie führen keine Lastsimulationen durch.

Ein häufiges Fehlermuster: Die Anwendung verwendet eine monolithische Datenbank ohne Lesereplikate, ohne Caching-Schicht und Abfragen, die vollständige Tabellen scannen. Bei 10.000 täglich aktiven Benutzern liegen die Reaktionszeiten unter 200 ms. Bei 30.000 DAU dauern dieselben Abfragen 2–4 Sekunden. Bei 50.000 wird die Datenbank aufgrund eines Schreibkonflikts gesperrt und das Produkt fällt aus. Dabei handelt es sich um Sanierungskosten in Höhe von 500.000 bis 2 Millionen US-Dollar, die das Team des Verkäufers nicht freiwillig übernimmt.

2. Unvorhersehbare Cloud-Kosten

Das Zielunternehmen meldet Cloud-Ausgaben in Höhe von 8.000 US-Dollar pro Monat. Das DD-Team nimmt dies zur Kenntnis und macht weiter. Was sie nicht überprüfen: Die Infrastruktur verfügt über keine Autoscaling-Richtlinien, keine reservierten Instanzen und keine Kostenwarnungen. Drei Entwicklungsumgebungen laufen rund um die Uhr mit den Spezifikationen der Produktionsebene. Ein vergessener Kubernetes-Cluster kostet 1.200 US-Dollar pro Monat und bringt nichts.

Nach der Übernahme, wenn der neue Eigentümer auf Wachstum drängt, steigen die Cloud-Kosten auf 25.000 US-Dollar pro Monat, weil niemand die Grundlage optimiert hat. Die tatsächliche Zahl würde immer 25.000 US-Dollar betragen; Der Betrag von 8.000 US-Dollar spiegelte eine unzureichende Auslastung wider, nicht die Effizienz.

3. Undokumentierte Abhängigkeiten und Stammeswissen

Der CTO hat das ursprüngliche System vor vier Jahren gebaut. Zwei Ingenieure kamen später hinzu. Die drei haben alle architektonischen Zusammenhänge im Kopf. Es sind keine Architekturentscheidungsdatensätze vorhanden. Keine Runbooks. Keine Playbooks zur Reaktion auf Vorfälle. Der Bereitstellungsprozess umfasst eine SSH-Verbindung zu einem Server und die Ausführung eines Bash-Skripts, das eine Person geschrieben hat und das eine Person versteht.

Wenn der CTO nach der Übernahme ausscheidet (und CTOs gehen häufig innerhalb von 12 Monaten nach Abschluss), kann das verbleibende Team ohne monatelanges Reverse Engineering keine Funktionen liefern, Produktionsprobleme beheben oder neue Ingenieure einbinden. Dies ist kein technisches Problem. Es handelt sich um ein Geschäftskontinuitätsrisiko, das im Rahmen der DD quantifiziert werden sollte.

4. Schwache Notfallwiederherstellung

Stellen Sie dem Zielunternehmen zwei Fragen: „Wann haben Sie das letzte Mal eine Wiederherstellung aus einem Backup durchgeführt?“ und „Was ist Ihr Erholungszeitziel?“ Wenn die Antworten „nie“ und „wir haben keine definiert“ lauten, ist die DR-Haltung eine Belastung.

Viele Unternehmen richten bei der Erstbereitstellung automatisierte Backups ein und überprüfen diese nie. Datenbanken werden jede Nacht auf S3 gesichert, aber niemand hat getestet, ob diese Sicherungen wieder in einen funktionsfähigen Zustand versetzt werden. Die Sicherung ist möglicherweise beschädigt. Das Wiederherstellungsskript verweist möglicherweise auf eine Infrastruktur, die nicht mehr vorhanden ist. Sie werden es erst erfahren, wenn Sie es brauchen, und bis dahin haben Sie Daten und Umsatz verloren.

5. Integrationsblocker

Der Anschaffungswert hängt häufig von der Integration des Produkts des Zielunternehmens in die bestehende Plattform des Käufers ab. Ein von einer Unternehmenssuite erworbenes CRM-Tool muss in SSO, gemeinsame Abrechnung und einheitliche Analysen integriert werden können. Wenn es sich bei dem Authentifizierungssystem des Ziels um eine maßgeschneiderte Lösung handelt, die fest auf einen Identitätsanbieter programmiert ist, dauert die Integration sechs Monate statt sechs Wochen.

DD-Reviews sollten jede Integrationsoberfläche abbilden: APIs, Webhooks, Authentifizierungsflüsse, Datenformate und Ereignissysteme. Jeder benötigt eine ehrliche Einschätzung, wie viel Arbeit nötig ist, um sich mit dem Stack des Käufers zu verbinden. „Wir haben eine API“ ist nicht dasselbe wie „Wir haben eine dokumentierte, versionierte, ratenbegrenzte API mit Standardauthentifizierung und Fehlerbehandlung.“

Die technische DD-Checkliste

Diese Tabelle deckt die Bereiche ab, die eine gründliche technische DD-Überprüfung bewerten sollte. Jeder Bereich enthält spezifische zu beantwortende Fragen und das Risikoniveau, wenn es nicht untersucht wird.

Diese Checkliste deckt den technischen Oberflächenbereich ab. Zu einem vollständigen DD-Engagement gehören auch Interviews mit dem Engineering-Team, eine Überprüfung der Sprintgeschwindigkeit und des Lieferrhythmus sowie eine kommerzielle Bewertung der Produkt-Roadmap.

Wann sollte die technische DD ausgeführt werden (Hinweis: früher als Sie denken)

Die meisten Firmen planen die technische DD nach der Unterzeichnung einer Absichtserklärung. Zu diesem Zeitpunkt hat der Deal Fahrt aufgenommen. Die Partner sind emotional beteiligt. Das Zielunternehmen weiß, dass es sich in einer starken Verhandlungsposition befindet. Wenn in dieser Phase Sanierungskosten in Höhe von 2 Millionen US-Dollar festgestellt werden, steht man vor einer unbequemen Entscheidung: den Preis neu verhandeln (was den Deal zum Scheitern bringen kann) oder die Kosten übernehmen (was die Rendite schmälern kann).

Führen Sie eine technische DD vor dem LOI oder parallel zur kommerziellen Due Diligence durch.Eine einfache technische Bewertung dauert 5–10 Werktage und kostet einen Bruchteil des Geschäftswerts. Es liefert Ihnen von Anfang an die Informationen, die Sie für eine korrekte Preisgestaltung des Deals benötigen.

Early Tech DD macht drei Dinge. Zunächst werden Dealbreaker identifiziert, bevor Sie Kapital und Anwaltskosten aufbringen. Zweitens erhalten Sie spezifische Datenpunkte, um Preisanpassungen im Zusammenhang mit den Sanierungskosten auszuhandeln. Drittens verringert es die Reibungsverluste bei Deals; Wenn beide Seiten die technische Realität frühzeitig erkennen, gibt es keine späten Überraschungen, die den Abschluss aufhalten könnten.

Wie eine gute technische DD-Ausgabe aussieht

Ein nützlicher DD-Bericht ist kein 60-seitiges Dokument voller Architekturdiagramme und Fachjargon. Es ist ein Entscheidungsinstrument. Die Leute, die es lesen, sind Partner, Vorstandsmitglieder und Deal-Teams, die Risiken in finanzieller Hinsicht verstehen müssen.

Zu einem starken technischen DD-Ergebnis gehören:

• Zusammenfassung (1 Seite):Go/No-Go-Empfehlung mit den drei größten Risiken und ihren geschätzten Sanierungskosten.
• Risikoregister:Jedes Risiko ist nach Schweregrad (kritisch, hoch, mittel, niedrig) kategorisiert, mit einer Dollarschätzung zur Behebung und einem Zeitplan zur Behebung.
• Bewertung der Skalierbarkeit:Kann die aktuelle Architektur den Wachstumsplan unterstützen? Wenn nicht, welche Änderungen sind erforderlich und was kosten sie?
• Integrations-Roadmap:Ein realistischer Zeitplan für die Verbindung des Produkts des Ziels mit der Plattform des Käufers, mit Angabe von Abhängigkeiten und Blockern.
• Teambewertung:Risiken bei Schlüsselpersonen, Qualifikationsdefizite und ein Einstellungsplan, wenn die Roadmap nach der Übernahme Fähigkeiten erfordert, die dem aktuellen Team fehlen.
• 100-Tage-Plan:Die technischen Maßnahmen mit der höchsten Priorität für die ersten 100 Tage nach Schließung, geordnet nach Auswirkung und Dringlichkeit.

Jede Feststellung sollte sich an den Dollars und dem Zeitplan orientieren. „Die Testabdeckung beträgt 23 %“, ist eine Beobachtung. „Die Testabdeckung beträgt 23 %, was bedeutet, dass jedes neue Feature-Release ein Regressionsrisiko von 30–40 % birgt; die Behebung dieser Abdeckung auf 70 % wird 6–8 Wochen dauern und 40.000–60.000 US-Dollar kosten“, sind umsetzbare Erkenntnisse.

Häufige Fehler, die Acquirer bei Tech DD machen

Verlassen Sie sich auf die selbst gemeldeten Kennzahlen des Ziels.Der Verkäufer gibt an, dass die Bereitstellung zweimal pro Woche erfolgt und die Testabdeckung 80 % beträgt. Überprüfen Sie es. Rufen Sie die Bereitstellungsprotokolle ab. Führen Sie die Testsuite aus. Selbstberichtete technische Kennzahlen sind oft erstrebenswert und nicht tatsächlich.

Verwechseln Sie „es funktioniert“ mit „es ist gut gebaut“.Ein Produkt kann einen Umsatz von 10 Millionen US-Dollar generieren und trotzdem auf einer Codebasis laufen, deren Wartung in den nächsten drei Jahren 3 Millionen US-Dollar kosten wird. Funktionierende Software und wartbare Software sind verschiedene Dinge. DD muss beides bewerten.

Überspringen Sie die Teaminterviews.Der Code sagt Ihnen, was das System heute tut. Das Team sagt Ihnen, ob das System weiterentwickelt werden kann. Sprechen Sie mit einzelnen Ingenieuren und nicht mit dem CTO, der eine Präsentation präsentiert. Fragen Sie sie: „Was würden Sie umbauen, wenn Sie drei Monate Zeit hätten?“ Ihre Antworten offenbaren die technischen Schulden, mit denen sie täglich leben.

Tech DD als Kontrollkästchen behandeln.Einige Firmen beauftragen einen DD-Anbieter, erhalten den Bericht, reichen ihn ein und führen das Geschäft unverändert fort. Der Zweck von DD besteht darin, die Geschäftsbedingungen bekannt zu geben. Wenn im Bericht Sanierungskosten in Höhe von 1,5 Millionen US-Dollar ausgewiesen werden, sollte diese Zahl in der Preisverhandlung erscheinen. Wenn dies nicht der Fall ist, haben Sie für die DD bezahlt und sie dann ignoriert.

Das Endergebnis

Bei der technischen Due Diligence handelt es sich nicht um eine Compliance-Übung. Es handelt sich um ein Bewertungsinstrument. Die Firmen, die das Geschäft ernst nehmen, es mit erfahrenen Ingenieuren (und nicht mit allgemeinen Beratern) besetzen, es zu Beginn des Deal-Prozesses betreuen und jedes Ergebnis an einen Dollarwert knüpfen, sind die Firmen, die die Überraschungen nach dem Abschluss vermeiden, die die Erträge zerstören.

Die Kosten für ein umfassendes technisches DD-Engagement betragen 0,1–0,3 % des Geschäftswerts. Die Kosten für das Verpassen eines kritischen Risikos betragen 10–30 % des Geschäftswerts. Die Rechnung ist einfach.

Häufig gestellte Fragen