Technology Due Diligence ist eine operative Entscheidung, keine Transaktions-Checkliste

Mit der Investmentthese beginnen, nicht mit der Architektur

Die erste Diligence-Frage sollte nicht lauten, ob der Stack modern ist. Sie sollte lauten, ob die bestehende Technologie das geplante Umsatz-, Margen- und Kundenwachstum ohne unverhältnismäßige oder nicht offengelegte Investitionen unterstützt.

Diese Frage ordnet die Technologie dem Geschäftsmodell unter. Setzt der Plan starkes Kundenwachstum voraus, muss die Diligence prüfen, ob Infrastruktur, Produktarchitektur, Lieferkapazität und Support damit skalieren. Unterstellt der Plan eine höhere Gross Margin, muss die Technologiekostenbasis zeigen, wie diese entsteht. Beruht der Investment Case auf Produktintegration oder gemeinsamen Daten, müssen die Systeme dies technisch und rechtlich ermöglichen. Soll sich das EBITDA verbessern, brauchen Technologiesynergien mehr Substanz als eine Zeile im Spreadsheet.

Architekturqualität ist wichtig. Doch Investoren kaufen keine Architekturdiagramme—sie investieren in das Geschäft, das diese Architektur ermöglichen muss.

Der sinnvolle Test lautet deshalb nicht: „Würde ich dieses System heute genauso entwerfen?“ Er lautet: „Kann dieses System das beabsichtigte Geschäft im relevanten Zeitraum zu den erforderlichen Kosten und Risiken tragen?“ Dazu gehören verborgener CapEx, laufender OpEx, Migrationsaufwand, Delivery-Grenzen und die Kosten stabiler Kundenbeziehungen während der Veränderung.

Diese Perspektive verhindert zugleich, dass Diligence zu einem Schönheitswettbewerb wird. Ein sauberes Cloud-native-Diagramm beweist weder tragfähige Unit Economics noch klare Ownership oder verlässliche Delivery. Ein weniger zeitgemäß wirkendes System kann profitables Geschäft, loyale Kunden und beherrschbare Veränderung tragen. Der Businessplan—nicht technischer Geschmack—definiert die Materialität.

Nicht Legacy ist das Warnsignal, sondern die wirtschaftliche Grenze

Ein technisch unattraktives System kann ein hervorragendes Business Asset sein. Ein moderner Stack kann teuer, fragil oder schlecht geführt sein.

Legacy wird materiell, wenn sie die Wirtschaftlichkeit verschlechtert, Wachstum blockiert, untragbare Resilienz- oder Regulierungsrisiken erzeugt, Wissen unbeherrschbar konzentriert oder strategische Optionen beseitigt. Bis dahin kann der Umbau eines profitablen Systems allein aus architektonischem Unbehagen mehr Wert vernichten als schaffen.

Ein Legacy-Stack ist nicht automatisch ein Deal-Risiko. Eine Architektur, die den Businessplan nicht tragen kann, ist es.

Dieselbe Disziplin gilt für Technical Debt. Manche Schulden entstehen bewusst: Ein Unternehmen akzeptiert eine Abkürzung für schnelleres Time-to-Market, lernt von Kunden und behält einen realistischen Refactoring-Pfad. Das kann eine rationale Kapitalallokation sein. Gefährlicher Technical Debt ist anders. Er führt in eine technische Sackgasse, verteuert jede Änderung unverhältnismäßig, blockiert Skalierung, schafft materielles Security- oder Rechtsrisiko oder macht spätere Veränderung wirtschaftlich irrational.

Technical Debt wird zum Investmentproblem, sobald er Wirtschaftlichkeit, Skalierbarkeit oder strategische Optionen einschränkt.

Diligence muss deshalb sowohl die Schuld als auch ihre Konsequenz benennen. Welche Umsatzannahme begrenzt sie? Welches Kundenversprechen gefährdet sie? Welche Kosten wachsen schneller als das Geschäft? Welche Produkt- oder Integrationsoption entfällt? Was kostet die Behebung, wann wird sie nötig und welches Risiko besteht bis dahin?

Das führt unmittelbar zur Entscheidung zwischen Modernisierung, Re-Platforming und Neubau. Ein kompletter Rewrite ist keine moralische Korrektur eines alten Systems. Er ist eine Investitionsoption mit eigenem Übergangsrisiko, Kundenrisiko und Opportunitätskosten. Die evidenzbasierte Entscheidung vertieft die Perspektive Modernisieren, Plattform erneuern oder neu bauen: Welche Fakten entscheiden?.

Technology Economics gehören in die Diligence

Technology Due Diligence muss letztlich in Geschäftswirtschaftlichkeit münden. Dafür reichen weder die Infrastrukturrechnung noch das Engineering-Budget.

Zum Kostenmodell gehören je nach Geschäft Hosting- und Infrastruktur-COGS, SaaS-Lizenzen, externe APIs, AI Inference, Engineering-Kapazität, der interne und externe Delivery-Mix, Lieferantenbindungen, Migration, Supportaufwand, Security- oder Compliance-Remediation, Abbau von Technical Debt und Integrationsaufwand. Ebenso wichtig ist manuelle Arbeit, die sich hinter vermeintlich automatisierten Prozessen verbirgt.

Keine dieser Kosten ist isoliert gut oder schlecht. Cloud Spend ist kein Problem, wenn Umsatz und Gross Margin schneller skalieren. Kritisch wird er, wenn sich Unit Economics mit dem Wachstum verschlechtern, Ausgaben nicht Produkten oder Kunden zugeordnet werden können oder die Architektur immer mehr Kosten benötigt, um dieselbe Leistung zu halten. Ziel ist nicht die niedrigste absolute Ausgabe. Ziel sind tragfähige Technology Economics.

Dasselbe gilt für Engineering-Kapazität. Ein großes Team kann produktive Investition sein oder fragile Architektur und manuelle Abläufe kompensieren. Ein kleines Team kann effizient oder gefährlich von wenigen Menschen abhängig sein. Diligence muss Kapazität mit Roadmap, Wartung, Support und den Veränderungen aus dem Businessplan verbinden.

Bei AI wird diese Verbindung besonders sichtbar. Eine AI-Funktion, die die Demo verbessert und gleichzeitig die Unit Economics zerstört, ist keine technologische Differenzierung. Inference, Evaluation, Monitoring, Fehlerbehandlung, Datenaufbereitung, Modellwechsel und operative Ownership gehören in die Lebenszykluskosten. Ein technisch beeindruckendes Feature kann die Gross Margin trotzdem schwächen.

Synergieannahmen brauchen dieselbe Prüfung. Tool-Konsolidierung, weniger doppelte SaaS-Ausgaben, gemeinsame Infrastruktur oder sinnvoll geteilte Plattformdienste können realistisch sein. Die vollständige Zusammenführung zweier unterschiedlicher Kernplattformen in wenigen Monaten ist eine andere Risikoklasse. Der Investment Case muss eine plausible Einsparung von einem noch nicht geplanten und finanzierten Transformationsprogramm unterscheiden.

Jedes materielle Technology Finding sollte am Ende in eines von drei Ergebnissen münden: eine Geschäftsrestriktion, einen quantifizierten Investitionsbedarf oder eine Ausführungspriorität. Andernfalls bleibt es Beobachtung statt Entscheidungsgrundlage.

Lieferfähigkeit prüfen, nicht Engineering-Theater

„Wir arbeiten agil“, „wir haben CI/CD“ und „wir besitzen eine hohe Test Coverage“ beschreiben Praktiken, aber nicht zwingend Ergebnisse.

Belastbare Diligence-Evidenz zeigt, wie Arbeit tatsächlich durch das Unternehmen fließt. Deployment Frequency, Lead Time for Changes und Change Failure Rate können Delivery-Verhalten sichtbar machen, wenn Definition und Kontext klar sind. Commit-to-Production-Zeit zeigt, ob die nominelle Pipeline Reibung wirklich entfernt. Onboarding-Dauer legt offen, wie zugänglich Wissen ist. Der Bus Factor zeigt persönliche Kontinuitätsrisiken. Das Verhältnis von Cloud Spend zu Umsatz kann Skalierungsökonomie beleuchten, sofern es zum Geschäftsmodell passt.

Keine Kennzahl sollte zum universellen Score werden. Test Coverage ohne Qualitätskontext kann Tests belohnen, die wenig beweisen. Story Points sind lokale Planungseinheiten, keine Unternehmensproduktivität. Ein großer Backlog kann Nachfrage, Unentschlossenheit oder schlechte Pflege bedeuten. Lines of Code sagen nahezu nichts über Business Capability aus.

Ziel ist ein konsistentes Betriebsbild. Können Teams kleine Änderungen sicher ausliefern? Lassen sich Incidents diagnostizieren und beheben? Werden neue Engineers ohne mündliche Überlieferung produktiv? Passt der Roadmap-Durchsatz zum Forecast? Können die Verantwortlichen eines Service ihn auch betreiben?

Zwei informelle Fragen zeigen mitunter mehr als polierte Dokumentation: Welches Subsystem beunruhigt Sie sonntags um zwei Uhr morgens am meisten? Und: Was geschieht, wenn ein bestimmter Entwickler morgen das Unternehmen verlässt? Die Konkretheit der Antwort zeigt häufig, ob das Management sein Risiko versteht.

Delivery Capability bestimmt auch, ob eine Remediation glaubwürdig ist. Ein Target kann die richtigen Architekturänderungen identifizieren. Der Plan bleibt dennoch fragwürdig, wenn die Organisation nie gezeigt hat, dass sie vergleichbare Veränderung bei stabilem Kundenbetrieb liefern kann. Diligence prüft deshalb nicht nur, was zu tun ist, sondern ob Team, Operating Model und Governance es leisten können.

Team, Ownership und Rechte können wichtiger sein als Architektur

Ein starkes Team kann schwache Architektur reparieren. Eine schwache Ownership-Kultur wird selbst gute Architektur langfristig verschlechtern.

Key-Person-Abhängigkeit ist ernst, lässt sich aber oft durch Retention, Nachfolge, Dokumentation und Wissenstransfer steuern. Eine Organisation, in der niemand das System besitzt, ist schwieriger zu reparieren. Sind Verantwortlichkeiten diffus, wandern Incidents zwischen Teams, fehlen accountable Owner für Architekturentscheidungen und wird Wartung dauerhaft verschoben, ist das Risiko systemisch statt persönlich.

Technology Ownership hat auch eine rechtliche Dimension. Diligence muss feststellen, ob das Unternehmen die Technologie, von der sein Geschäft abhängt, nutzen, verändern und übertragen darf. IP-Übertragungen, Open-Source-Pflichten, Drittanbieter-Lizenzen, Lieferantenverträge und Datenrechte können materieller sein als eine unvollkommene Modulgrenze. In reifen Unternehmen erschwert die Historie diese Arbeit: Produkte, Mitwirkende, Verträge und Gesellschaftsstrukturen verändern sich, während die Evidenzkette intakt bleiben muss.

Daten und Privacy verlangen ebenso operative Fragen. Sind Tenants getrennt? Bleiben ACLs und Berechtigungen über Systeme hinweg erhalten? Wohin fließen Daten? Was ändert sich, wenn zwei Unternehmen Daten nach dem Closing zusammenführen? Bleibt die geplante Integration mit Vertragszweck und GDPR-Pflichten vereinbar? Eine technisch einfache Datenkombination kann rechtlich oder operativ unmöglich sein.

Security Diligence sollte weniger fragen, ob irgendeine Schwachstelle existiert—eine wird sich fast immer finden—und stärker prüfen, wie die Organisation reagiert. Patch-Disziplin, Incident Response, DevSecOps Ownership, Remediation-Geschwindigkeit und Post-Mortem-Kultur zeigen, ob Risiko als Operating Capability geführt wird. Zertifikate können die Evidenz stützen. Sie ersetzen sie nicht.

Deshalb sollte der Target-CTO die Architektur nicht verteidigen, als wäre Diligence ein Gerichtsverfahren. Er sollte die Realität transparent erklären, materielle Risiken mit Kosten und Business Impact verbinden und einen glaubwürdigen Remediation-Pfad zeigen. Ziel ist keine perfekte Darstellung. Ziel ist der Nachweis, dass das Management den Zustand versteht und führen kann.

AI verändert das Diligence-Modell

AI Claims verlangen, Produktwert, Daten, Governance, Fehlermodi, Unit Economics und Lebenszykluskosten gemeinsam zu prüfen.

Die erste Frage lautet, ob die Fähigkeit verteidigbaren Produktwert schafft oder nur eine dünne Oberfläche über einem Provider bietet, der allen Marktteilnehmern zur Verfügung steht. Beruht Differenzierung auf Daten, muss Diligence prüfen, ob belastbare Ground Truth existiert, ob das Unternehmen sie für den vorgesehenen Zweck nutzen darf und ob sie bei veränderten Produkten oder Prozessen relevant bleibt.

Berechtigungen dürfen an der AI-Grenze nicht verschwinden. Retrieval und generierter Output müssen Tenant-Trennung, Access Controls und Berechtigungen der Quellsysteme bewahren. Rechte an Trainingsdaten und Outputs brauchen Klarheit. Sensible Informationen dürfen nicht über Prompts, Logs oder Modellverhalten abfließen. Providerwechsel, Modellabkündigung und Vendor Lock-in benötigen eine glaubwürdige Antwort.

Fehlerökonomie ist ebenso wichtig wie Modellqualität. Was kostet eine Halluzination? Welche Ergebnisse dürfen probabilistisch bleiben? Wo sind deterministische Kontrollen oder menschliche Freigaben erforderlich? Wie viel Expertenprüfung bleibt nach der Automatisierung bestehen? Wie entwickeln sich Inference- und Evaluationskosten mit der Nutzung?

Das sind Produktionsfragen, keine Einwände gegen AI. Sie unterscheiden ein Feature, das zu einer belastbaren Business Capability werden kann, von einer Demonstration, die Kosten und Risiko in den Betrieb verschiebt. Den Entscheidungsrahmen vertieft Wann industrielle AI nicht in Produktion gehen sollte.

Ein Finding braucht ein Ziel nach dem Closing

Ein Diligence Finding darf nach dem Closing nicht in einem PDF verschwinden. Es braucht Owner, Business Impact, Kosten, Timing und Entscheidung.

Manche Findings gehören vor das Signing. Ungeklärtes IP-Eigentum, ein materieller regulatorischer Blocker, ein grundsätzlich unpassendes Technologiekostenmodell, eine Architektur, die die Investmentthese nicht trägt, oder eine kritische Integrationsinkompatibilität können Bewertung, Deal-Struktur, Bedingungen, vertragliche Absicherung oder die Investitionsentscheidung beeinflussen.

Andere Findings gehören in einen 100-Day Plan oder eine längere Transformations-Roadmap: Refactoring, Security Hardening, FinOps, Vendor-Konsolidierung, Prozessharmonisierung, Finance- oder ERP-Integration und Änderungen der Produkt-Roadmap. Die Unterscheidung ist wichtig. Jede Unvollkommenheit zum Signing-Blocker zu erklären erzeugt Lärm; eine für die These kritische Grenze erst nach Closing zu behandeln schafft vermeidbare Überraschungen.

Die stärkste Diligence zeigt bereits, was als Nächstes geschehen muss. Sind Technologiesynergien fundamental für die Investmentthese, kann vor Closing eine Zielrichtung auf hoher Ebene nötig sein. Das detaillierte Target Architecture Design sollte meist dem tieferen operativen Verständnis folgen. Zu frühe Standardisierung kann die Agilität des Targets zerstören; dauerhafte Trennung erhält doppelte Kosten und verhindert Synergien. Das richtige Tempo hängt von Stand-alone-Absicht, Produktstrategie, Plattform-Integration und der Veränderung ab, die Kunden sicher aufnehmen können.

Kundenkontinuität ist ebenso technologische wie kommerzielle Entscheidung. Datenmigration, Login- oder SSO-Wechsel, Billing-Migration, API-Abschaltung und Produktstilllegung verändern potenziell Workflow und Vertrauen der Kunden. Infrastruktur, Stabilität, Performance und Security lassen sich häufig früh und ohne sichtbare Unterbrechung verbessern. Erzwungene Migrationen und Interface-Wechsel verlangen mehr Vorsicht.

Hohe Kundenzufriedenheit kann selbst zur Integrationsrestriktion werden: Eine Migration, die auf dem Architekturdiagramm effizient wirkt, kann mehr Wert vernichten, als sie schafft.

Ein Deal schafft erst dann operativen Wert, wenn das kombinierte Unternehmen besser arbeitet als beide Unternehmen getrennt—durch niedrigere Kosten, höheren Umsatz, bessere Customer Experience, stärkere Produktfähigkeit, nutzbare Daten, schnelleres Time-to-Market, verbessertes EBITDA oder geringere Komplexität. Technology Due Diligence sollte prüfen, ob diese Verbesserungen real, kompatibel und finanzierbar sind.

Due Diligence verändert sich, wenn man weiß, dass man die Konsequenzen nach Closing weiter trägt. Man sucht nicht mehr nach architektonischen Unvollkommenheiten, sondern nach den Entscheidungen, die am ersten Tag zählen.

Fünf Fragen, die die Investmentdiskussion weiterbringen

Diese Fragen ersetzen keine Diligence. Sie zwingen die Technologiediskussion zurück in den Investment Case:

• Kann die bestehende Technologie das geplante Wachstum ohne ungedeckten oder unverhältnismäßigen Kapitalbedarf tragen?
• Welche konkreten Technologiesynergien enthält der EBITDA Case, und welche Voraussetzungen müssen dafür erfüllt sein?
• Wie hoch sind die realen COGS aus Hosting, externen APIs und Lizenzen je sinnvoller Kunden-, Transaktions- oder Produkteinheit?
• Wo liegen kritische Bus-Factor- und Key-Person-Risiken, und wie werden Ownership und Kontinuität gesichert?
• Welcher Kosten- und Zeitrahmen ist für die Post-Merger-Integration realistisch, ohne die Kundenkontinuität zu beschädigen?

Der Wert dieser Fragen liegt nicht in der spontanen Antwort. Entscheidend ist, ob das Management konsistente Evidenz aus Architektur, Finance, Delivery und Kundenbetrieb zusammenführen kann.

Fünf Dinge, die Target-CEO und -CTO vorbereiten sollten

Permanente Diligence Readiness ist normale operative Disziplin, kein Transaktionstheater:

• Technical Debt offenlegen und mit Kosten, Business Impact, Timing und Remediation verbinden.
• IP-Rechte, Open-Source-Pflichten und materielle Lieferantenverträge ordnen, bevor die Diligence beginnt.
• Belastbare Hosting-, FinOps- und Delivery-Evidenz pflegen, statt sie unter Deal-Druck nachträglich zu rekonstruieren.
• Datenarchitektur, GDPR-Exposition, Datenflüsse und Berechtigungsmodelle verstehen und dokumentieren.
• Erklären, wie die Architektur die nächste Geschäftsphase trägt—oder sich dafür verändern muss—statt sie als perfekt zu verteidigen.

Architekturdokumentation, Ownership, Verträge, Kostenstrukturen, Delivery-Signale, Security-Evidenz und Roadmap-Entscheidungen sollten aktuell sein, weil das Unternehmen sie zum Betrieb braucht. Ein unter Zeitdruck aufgebauter Data Room ist ein schwacher Ersatz für bereits vorhandene Managementinformation.

Exit Readiness ist kein Transaktionsprojekt. Sie ist eine Folge guter Unternehmensführung.