Eine technische Due Diligence prüft vor dem Signing, was im Code eines Zielunternehmens steckt, welche Risiken er birgt und was eine Übernahme technisch tatsächlich wert ist. Wer ein Unternehmen kauft, kauft dessen Software mit, ob das im Kaufpreis eingepreist ist oder nicht. Nach dem Bain Global M&A Report haben über 70 Prozent der Transaktionen im mittleren Marktsegment eine wesentliche Technologiekomponente, wie Plausity unter Berufung auf den Report schreibt (Plausity, 03/2026). Ein Kaufpreis, der auf einer zu oberflächlichen Prüfung beruht, lässt sich nach dem Signing nur noch selten nachträglich korrigieren.
Eine technische Due Diligence prüft vor einer Übernahme Architektur, Abhängigkeiten, Sicherheitslage, Testabdeckung, Betriebsreife und die Herkunft des geistigen Eigentums im Zielunternehmen. Hohe technische Schulden bedeuten nach dem Kauf oft erhebliche Nacharbeit und wirken direkt auf die Rendite. Wichtig ist der vollständige Prüfumfang, reine Interviews mit dem Entwicklungsteam reichen dafür nicht.
Was eine technische Due Diligence konkret prüft
Eine Prüfung, die nur aus Interviews mit dem Entwicklungsteam besteht, deckt einen Bruchteil der relevanten Risiken auf. Sie muss über Gespräche hinausgehen und den Code selbst, die Sicherheitslage und die Herkunft des geistigen Eigentums prüfen, denn Aussagen im Gespräch und der tatsächliche Zustand der Systeme fallen in der Praxis häufig auseinander. Wer sich auf Präsentationen des Managements verlässt, sieht selten die Stellen im System, die der Übernahme später am meisten kosten. Genau diese Stellen findet nur, wer selbst im Code nachsieht, statt sich auf eine Zusammenfassung zu verlassen.
der Transaktionen im mittleren Marktsegment haben nach dem Bain Global M&A Report eine wesentliche Technologiekomponente.
Plausity zum Bain Global M&A Report, 03/2026
| Bereich | Leitfrage |
|---|---|
| Architektur | Lässt sich das System skalieren und in Teilen ersetzen, ohne alles neu zu bauen? |
| Abhängigkeiten und Lizenzen | Welche Fremdkomponenten stecken im Produkt, unter welchen Lizenzbedingungen? |
| Testabdeckung | Lassen sich Änderungen risikoarm ausliefern, oder hängt Qualität an einzelnen Personen? |
| Betriebsreife | Wie oft fällt das System aus, und wie schnell wird ein Ausfall erkannt? |
| Schlüsselpersonen | Wie viele Personen müssten ausfallen, damit die Entwicklung stillsteht? |
| Dokumentation | Lässt sich das System ohne die ursprünglichen Entwickler warten? |
Diese sechs Bereiche hängen zusammen, ein schwacher Wert in einem Feld verstärkt meist die Risiken in den anderen. Fehlt die Dokumentation, wiegt das Schlüsselpersonen-Risiko schwerer. Fehlt die Testabdeckung, wird jede Weiterentwicklung der Architektur riskanter, als sie auf dem Papier aussieht.
Bei der Herkunft des geistigen Eigentums lohnt der genaue Blick in die Verträge. Nach § 69b UrhG stehen die vermögensrechtlichen Befugnisse an Software, die Angestellte in Wahrnehmung ihrer Aufgaben schaffen, dem Arbeitgeber zu, sofern nichts anderes vereinbart ist. Für freie Mitarbeiter gilt diese Regel nicht. Dort braucht es eine ausdrückliche Rechteübertragung im Vertrag, und genau die fehlt in über Jahre gewachsenen Codebasen häufig.
In Prüfungen, die wir begleiten, taucht ein Muster immer wieder auf. Systeme mit guter Testabdeckung haben fast immer auch die verständlichere Dokumentation, weil beides aus derselben Arbeitsdisziplin im Entwicklungsteam entsteht. Fehlen beide gleichzeitig, ist das ein stärkeres Warnsignal als jeder einzelne Wert für sich genommen.
Warum technische Schulden den Kaufpreis verändern
Technische Schulden lassen sich als Kennzahl messen, anders als der vage Eindruck aus einem einzelnen Gespräch. Veraltete Abhängigkeiten, fehlende Tests und eine Architektur, die jede Änderung zum Risiko macht, bedeuten nach dem Kauf reale Folgekosten, sei es durch Nacharbeit, durch verzögerte Weiterentwicklung oder durch ein höheres Ausfallrisiko im laufenden Betrieb. Diese Kosten wirken direkt auf die Rendite der Transaktion, unabhängig davon, wie gut das Geschäftsmodell selbst funktioniert.
Eine Quantifizierung dieser Schulden ist deshalb keine akademische Übung. Sie liefert die Grundlage für die Kaufpreisverhandlung und für einen realistischen „Plan der ersten 100 Tage“ nach der Übernahme, in denen die dringendsten Risiken angegangen werden müssen, bevor sie zu Ausfällen oder Sicherheitsvorfällen führen. Ein Betrag im Kaufvertrag, der auf dieser Zahl beruht, lässt sich vor einem Gremium leichter vertreten als ein pauschaler Abschlag nach Gefühl.
Die gefundene Zahl fließt in der Praxis meist auf einem von zwei Wegen in die Transaktion ein. Entweder sinkt der Kaufpreis um die geschätzten Folgekosten, oder ein Teil des Kaufpreises wird über eine Escrow-Regelung zurückgehalten, bis die kritischsten Punkte behoben sind. Welcher Weg passt, hängt vom Verhandlungsgewicht der beiden Seiten ab, nicht allein von der Höhe der gefundenen Schulden. Wie teuer ein solches Nacharbeiten werden kann, zeigt der Beitrag ERP-Projekt in der Krise: Typische Muster und Auswege.
Eine Prüfung in zwei Wochen kann die größten Risiken sichtbar machen, aber keine vollständige Kontrolle jeder Codezeile leisten. Wer eine lückenlose Garantie erwartet, verwechselt eine Risikoeinschätzung mit einer Vollprüfung, die Wochen oder Monate braucht und in den seltensten Fällen zum Zeitplan einer Transaktion passt.
Technische Prüfung vor dem Signing
Eine erste Einschätzung des Zielunternehmens lässt sich häufig innerhalb einer Woche organisieren.
Häufige Fragen
Wie lange dauert eine technische Due Diligence?
Für einen ersten belastbaren Überblick reichen häufig ein bis zwei Wochen mit einem kleinen Team, das Zugriff auf Code, Ticketsystem und die wichtigsten Ansprechpartner bekommt. Größere Transaktionen mit mehreren Produktlinien oder verteilten Teams brauchen entsprechend länger, besonders wenn Zugänge erst organisiert werden müssen, bevor die eigentliche Prüfung beginnen kann. Ein fester Zeitrahmen zu Beginn hilft beiden Seiten, weil er verhindert, dass sich die Prüfung unbemerkt über Wochen hinzieht und den gesamten Transaktionsprozess verzögert.
Was sind typische Ausschlusskriterien?
Dazu zählen unklare Eigentumsverhältnisse am Code, etwa wenn wesentliche Teile von freien Mitarbeitern ohne dokumentierte Rechteübertragung stammen, gravierende Sicherheitslücken in produktiven Systemen sowie eine Architektur, die sich nur mit einem faktischen Neubau weiterentwickeln lässt. Keines dieser Kriterien schließt eine Transaktion automatisch aus, sie verschieben aber den Kaufpreis oder die Struktur des Deals erheblich, etwa über eine längere Haftungsfrist des Verkäufers oder einen zurückgehaltenen Kaufpreisanteil.
Wer sollte prüfen?
Ein Team mit echter Entwicklungserfahrung liefert andere Ergebnisse als reine Berater, die selbst nie produktiven Code verantwortet haben. Wer die gefundenen Risiken nach der Übernahme auch beheben soll, gehört im besten Fall schon während der Prüfung eingebunden, das verkürzt den Übergang von der Bewertung zur tatsächlichen Integration erheblich. Ein reiner Prüfbericht ohne Umsetzungsverantwortung endet in der Praxis häufig in einer Schublade, statt in konkreten Maßnahmen.
Eine technische Due Diligence ist nur so viel wert wie die Fähigkeit, die gefundenen Risiken danach auch zu beheben. torck prüft Zielunternehmen mit denselben Entwicklungsteams aus Maxhütte-Haidhof, Wien und Rabat, die im Anschluss die technische Integration als Interim-Mandat übernehmen können, statt die Ergebnisse nur in einem Bericht zu übergeben. Vertragspartner für die Prüfung ist die deutsche torck GmbH, was Vertraulichkeit während einer laufenden Transaktion erleichtert. Wer vor einer Übernahme eine technische Einschätzung braucht, kann das in einem Erstgespräch klären.
Dieser Beitrag nennt Gesetze und Verordnungen, um technische Entscheidungen einzuordnen. Er ist keine Rechtsberatung. Ob und wie eine Regelung auf Ihr Unternehmen zutrifft, klären Sie bitte mit Ihrer Rechtsabteilung oder einer Kanzlei.
German 
English 
French