Technische Due Diligence verändert den Preis

Technische Due Diligence ist kein Wettbewerb um die schönste Codequalität. Ein Käufer will wissen, welche technischen Tatsachen den künftigen Cashflow verändern, das Eigentum am Vermögenswert gefährden, die Integration verzögern oder das Unternehmen von einer Person abhängig machen, die nach dem Abschluss gehen könnte. Saubere Abstraktionen sind angenehm. Planbare Auslieferung, nachweisbare Rechte und beherrschte Betriebsrisiken beeinflussen den Deal.

Ich habe erlebt, wie Käufer tagelang über Namenskonventionen stritten, während ein nächtlicher Abrechnungslauf keinen Verantwortlichen, keinen wiederholbaren Build und keinen Test hatte, der die Ergebnisse von gestern und heute vergleichen konnte. Das ist verkehrt. Eine brauchbare Prüfung verfolgt geschäftliche Folgen durch Code, Auslieferungsweg, Personal und Verträge und sagt dann, wie jeder Befund Preis oder Bedingungen verändern sollte.

Der Käufer bewertet Unsicherheit, nicht Stil

Ein Käufer nutzt technische Due Diligence, um Unbekanntes in einen kalkulierbaren Plan zu verwandeln. Die Codebasis liefert Belege, ist aber nur ein Teil. Repository-Verlauf, Build-Systeme, Produktionstelemetrie, Störungsprotokolle, Abhängigkeitsmanifeste, Architekturdiagramme, Zugriffskontrollen und Interviews zeigen, ob die Software unter einem neuen Eigentümer weiter Geld verdienen kann.

Die erste oft verwischte Unterscheidung betrifft Fehler und Deal-Risiko. Eine langsame Abfrage mit klarer Korrektur, Verantwortlichem und begrenztem Schadensradius ist ein Fehler. Eine undokumentierte Abrechnungslogik, die nur ein Auftragnehmer versteht, ist ein Deal-Risiko, selbst wenn sie jahrelang störungsfrei lief. Der erste Fall erzeugt ein Engineering-Ticket. Der zweite kann einen Einbehalt, eine Abschlussbedingung, eine Übergangsvereinbarung oder eine niedrigere Bewertung rechtfertigen, weil sich weder Ausfallwahrscheinlichkeit noch Wiederherstellungskosten gut begrenzen lassen.

Prüfer sollten jeden wesentlichen Befund mit einem wirtschaftlichen Mechanismus verbinden. Verlangt er sofortige Behebung? Blockiert er eine geplante Produktzusammenführung? Könnte er Umsatz unterbrechen, einen Kundenvertrag verletzen oder verhindern, dass der Käufer das System betreibt? Muss der Käufer eine bestimmte Person halten oder eine kommerzielle Lizenz kaufen? Ohne diese Brücke bleibt ein Befund eine Beobachtung und ist keine Due Diligence.

Schweregrade allein verdecken diese Logik. Zwei als "hoch" markierte Befunde können verschiedene Folgen haben. Ein öffentlich erreichbarer Administrationsendpunkt kann Maßnahmen vor Abschluss verlangen. Eine Datenbank an ihrer Kapazitätsgrenze kann ein finanziertes Projekt nach Abschluss begründen. Ein strittiger Codebeitrag kann eine Freistellung erfordern. Nennen Sie Folge und verfügbare Kontrolle, bevor Sie eine Farbe wählen.

Der Käufer braucht auch eine Vertrauensstufe. Können Prüfer das System nicht ausführen, auf produktionsähnliche Daten zugreifen oder den Betreiber befragen, dürfen sie den Bereich nicht stillschweigend als sauber markieren. Sie sollten die Beleglücke als eigenes Risiko erfassen. Fehlende Belege verändern Bedingungen oft stärker als ein bekannter Fehler, weil niemand die Obergrenze ehrlich kalkulieren kann.

Der Repository-Zugriff muss den Kaufgegenstand belegen

Repository-Zugriff sollte Vollständigkeit, Verlauf und Herkunft klären, bevor jemand die Architektur prüft. Ein gepflegtes Anwendungs-Repository kann von fehlenden Deployment-Skripten, Berichtsgeneratoren, Firmware, Datenbankjobs oder einem separaten Verzeichnis ablenken, das manuell auf Produktionsserver kopiert wird. Die Transaktion umfasst ein laufendes Gesamtsystem, nicht nur das Repository, das der Verkäufer zuerst öffnet.

Verlangen Sie ein Inventar, das jede Produktionskomponente einem Repository, Build-Pfad, Deployment-Verantwortlichen, einer Laufzeit, einem Datenspeicher und einer Umgebung zuordnet. Gleichen Sie es mit Cloud-Konten, Zeitplanern, Paketregistries, Serverdateisystemen, App-Stores, DNS-Einträgen und Lieferantenrechnungen ab. Erzielt eine ausführbare Datei Umsatz, hat aber keinen Quellort, erwirbt der Käufer womöglich eine Binärdatei, die er nicht reproduzieren kann.

Der Verlauf zählt, weil ein aktueller Snapshot weder Urheberschaft noch Entwicklungskonzentration zeigt. Fordern Sie die vollständige Commit-Historie, Tags, für unterstützte Releases nötige Branches, Submodule, Large-File-Speicher und nicht reproduzierbare Build-Artefakte an. Prüfen Sie, ob ein Import kurz vor dem Verkauf die Historie eingeebnet hat. Das kann harmlos sein, verhindert aber eine verlässliche Beitragsanalyse und erschwert die Prüfung von Zusicherungen zum geistigen Eigentum.

Eine kurze Triage-Sequenz liefert eine erste Karte. Führen Sie sie in einer isolierten Kopie aus, prüfen Sie jeden Befehl vorab und passen Sie die Pfade an das Repository an:

git rev-parse --is-shallow-repository
git shortlog -sne --all
git log --all --format='%aN <%aE>' | sort | uniq -c | sort -nr | head -20
git ls-files | sed 's|/.*||' | sort | uniq -c | sort -nr | head -30
find . -maxdepth 4 -type f \( -name 'package-lock.json' -o -name 'go.sum' -o -name 'Cargo.lock' -o -name 'pom.xml' -o -name '*.csproj' \) -print
find . -maxdepth 4 -type f \( -iname 'license*' -o -iname 'notice*' -o -iname 'copying*' \) -print

Die erwartete Ausgabe ist kein Bestanden oder Durchgefallen. Sie liefert Ansatzpunkte: ob die Historie flach ist, welche Identitäten Commits dominieren, wo Quellcode gebündelt liegt, welche Abhängigkeitsökosysteme existieren und wo Lizenzhinweise stehen. Danach folgen die Bereinigung von Aliasen und der Ausschluss von Bots. Setzen Sie Commit-Zahl nie mit Eigentum oder Können gleich. Generierte Änderungen, Importe, Pair Programming und Rebases verzerren das Bild.

Reproduzieren Sie schließlich ein unterstütztes Release aus einem dokumentierten Commit. Erfassen Sie Toolchain, benötigte Geheimnisse, externe Artefakte, Build-Dauer und die resultierenden Prüfsummen, sofern deterministische Ausgaben erwartet werden. Ein Build, der nur auf dem Laptop eines Mitarbeiters gelingt, ist nicht reproduzierbar, nur weil dieser Laptop während der Prüfung verfügbar ist.

Schlüsselpersonenrisiko steckt in Entscheidungen und Betrieb

Schlüsselpersonenrisiko besteht, wenn die Abwesenheit einer Person eine wesentliche Änderung, Wiederherstellung oder einen Geschäftsprozess stoppen kann. Commit-Konzentration ist ein Hinweis, keine Diagnose. Das Risiko steckt in undokumentierten Entscheidungen, privaten Zugangsdaten, manuellen Produktionsritualen, Lieferantenbeziehungen, Datenkorrekturen und der Berechtigung, ein Release freizugeben.

Beginnen Sie mit geschäftskritischen Wegen: Auftragserfassung, Abrechnung, Fakturierung, Monatsabschluss, regulatorische Berichte, Erfüllung und Kundenzugang. Fragen Sie bei jedem Weg, wer ihn erklären, ändern, ausliefern und wiederherstellen kann. Vier Namen sind nur dann besser als einer, wenn diese Personen unabhängig handeln können. Ein Team, das vor jeder Änderung an einer Preisregel den früheren Gründer anruft, hat weiterhin nur einen wirksamen Eigentümer.

Prüfen Sie Wissen durch Arbeit, nicht nur durch Interviews. Lassen Sie einen zweiten Entwickler eine Produktionstransaktion verfolgen, die maßgebliche Regel finden, in einer Nicht-Produktionsumgebung harmlos ändern, die passenden Tests ausführen und das Rollback beschreiben. Lassen Sie die Rufbereitschaftsvertretung ein repräsentatives Backup wiederherstellen und einen fehlgeschlagenen geplanten Job untersuchen. Der Beobachter sollte notieren, wo undokumentierte Informationen oder die Erlaubnis eines anderen Mitarbeiters nötig sind.

Der heikle Fall ist ein fähiger Gründer, der gehen will. Käufer akzeptieren manchmal ein vages Verfügbarkeitsversprechen, weil der Ersatz tiefen Kontextwissens unhöflich oder teuer wirkt. Dieses Versprechen ist schwach. Definieren Sie eine Übergabeleistung: benannte Runbooks, aufgezeichnete Erklärungen, Übertragung von Zugangsdaten, gemeinsam durchgeführte Releases, eine Störungsübung und Abnahme durch die künftigen Betreiber. Koppeln Sie die Erfüllung bei wesentlicher Abhängigkeit an Abschlussbedingung, Beratungsvertrag oder Bindungspaket.

Verwechseln Sie alte Technologie nicht mit dem Risiko eines einzigen Experten. Eine gut betriebene COBOL-Umgebung mit mehreren Bedienern, aufgezeichnetem Produktionsverhalten, automatisierten Builds und geübter Wiederherstellung kann sicherer sein als ein moderner Dienst, den letztes Jahr ein einzelner, inzwischen ausgeschiedener Auftragnehmer schrieb. Das Technologiealter beeinflusst Personalgewinnung und Änderungskosten. Konzentriertes Wissen beeinflusst Kontinuität. In manchen Systemen treffen beide zusammen, doch Belege und Abhilfe unterscheiden sich.

Der Preis bewegt sich, wenn der Käufer Doppelbesetzung finanzieren, jemanden zu Sonderbedingungen halten, die Integration verschieben oder ein nicht versicherbares Ausfallrisiko übernehmen muss. Kann ein praktischer Wissenstransfer die Lücke vor Abschluss schließen, machen Sie ihn zur Bedingung. Kann der Verkäufer das Wissen nicht übertragen, weil es niemand mehr besitzt, gehört die Behebung in die Investitionsrechnung und nicht in eine Dokumentationsaufgabe.

Lizenzrisiken beginnen bei der Herkunft

Die Lizenzprüfung muss beantworten, ob der Verkäufer jede wesentliche Produktkomponente übertragen und betreiben darf. Ein Abhängigkeitsscanner hilft, beweist aber keine Arbeitnehmerübertragung, Eigentumsrechte von Auftragnehmern, kopierte Ausschnitte, gekaufte Komponenten, Rechte an Trainingsdaten oder Bedingungen für Code von Partnern. Das sind Herkunftsfragen.

Erstellen Sie eine Software-Stückliste aus Manifesten, Lockfiles, eingebundenen Vendor-Verzeichnissen, Container-Images, generierten Clients, Mobilpaketen und mitgelieferten Betriebssystempaketen. Gleichen Sie sie anschließend mit dem ab, was Kunden oder Produktion tatsächlich erreicht. Die Dokumentation zum Dependency Graph von GitHub sagt, dass seine statische Analyse unterstützte Manifest- und Lockdateien parst. Diese Grenze zählt: Eine alte JavaScript-Datei im Vendor-Verzeichnis oder eine Binärdatei im Release-Ordner kann außerhalb des Manifestgraphen liegen.

Normalisieren Sie Befunde mit SPDX-Kennungen. Die SPDX-Spezifikation erlaubt Ausdrücke mit AND, OR und WITH und bewahrt damit Unterschiede, die eine Tabellenkalkulationsspalte namens "Lizenz" zerstört. GPL-2.0-only OR MIT bietet eine Wahl; LGPL-2.1-only AND BSD-2-Clause besagt, dass beide für die beschriebene Paketgruppe gelten. Wer beides zu einer Namensliste verkürzt, kann die falsche Abhilfe empfehlen.

Scanner liefern Behauptungen, die geklärt werden müssen. Erfassen Sie für jeden wesentlichen Treffer Komponente und Version, Eintrittsweg ins Produkt, Änderungen, Verteilung oder Hosting, erkannte und abschließend beurteilte Lizenz, nötige Hinweise oder Quellangebote, Verantwortlichen und Belege. Juristen beurteilen die Rechtslage. Engineering belegt Nutzung und Ersetzbarkeit. Keine Seite kann die Prüfung allein abschließen.

Behandeln Sie das Eigentum am eigenen Code genauso sorgfältig. Gleichen Sie Beitragende mit Beschäftigungszeiten, Erfinder- und Rechteübertragungen, Leistungsbeschreibungen für Auftragnehmer, Übernahmelisten und Code aus früheren Vorhaben ab. Prüfen Sie besonders Commits mit privaten E-Mail-Adressen, fremden Domains sowie Beiträge von Praktikanten, Agenturen und Gründern vor der Gründung. Eine unterschriebene Garantie im Kaufvertrag ist nützlich, lässt aber den Eigentumsanspruch eines Dritten nicht verschwinden.

Der Preis verändert sich, wenn eine Komponente im geplanten Modell nicht rechtmäßig ausgeliefert werden kann, ein Ersatz den Plan verzögert oder das Eigentum streitig bleibt. Kleinere Lücken passen oft in einen Abschlussplan, die Bereinigung von Hinweisen, eine gezielte Freistellung oder ein Escrow. Erklären Sie nicht jede Copyleft-Abhängigkeit für tödlich. Verteilung, Verknüpfung, Änderung und der tatsächliche Lizenztext bestimmen die Pflichten. Allgemeine Etiketten ersetzen keine juristische Prüfung.

Eine Testsuite ist nur Beleg, wenn sie scheitern kann

Der Zustand der Testsuite zählt, weil der Käufer das System nach Abschluss verändern wird. Dateizahlen und Abdeckungsprozente sagen wenig darüber, ob Tests geschäftliche Regressionen erkennen. Tausend Assertions rund um Datenzugriffe schützen keine Abrechnungsberechnung, wenn niemand das erwartete Ergebnis festgeschrieben hat.

Führen Sie die Suite aus einer sauberen Umgebung mit dem dokumentierten Befehl aus. Notieren Sie Einrichtungszeit, externe Dienste, Umgang mit Geheimnissen, Laufzeit, Wiederholungen bei Flakes, übersprungene Tests und Fehler im Standard-Branch. Fügen Sie dann einen kleinen kontrollierten Fehler in eine wichtige Regel ein und bestätigen Sie, dass ein passender Test aus dem erwarteten Grund scheitert. Nehmen Sie die Änderung sofort zurück. Diese Mutation sagt oft mehr als ein Abdeckungsbericht, weil sie prüft, ob der Test widersprechen kann.

Trennen Sie vier Belegarten. Unit-Tests schützen lokale Regeln. Integrationstests belegen, dass Komponenten bei Protokollen und Speicherung übereinstimmen. End-to-End-Tests prüfen ausgelieferte Wege, decken aber häufig wenige Varianten ab. Produktionsvergleich oder Replay-Tests zeigen, ob ein Ersatz beobachtetes Verhalten bewahrt. Keine Form ersetzt alle anderen. Eine grüne Browser-Suite validiert keine Jahresabschlussrechnung, und hohe Unit-Abdeckung beweist keine funktionierenden Datenbankmigrationen.

Lesen Sie die Fehlerhistorie der kontinuierlichen Integration. Ein roter Standard-Branch, den alle ignorieren, zeigt ein Kontrollversagen, auch wenn jeder Fehler eine Erklärung hat. Das gilt ebenso für eine Suite, die nur nach Wiederholungen besteht. Fragen Sie, wie Teams instabile Tests isolieren, wer Prüfungen übergehen darf, ob geschützte Branches Ergebnisse verlangen und wie Release-Hotfixes vom normalen Weg abweichen.

Testdaten bringen ein eigenes Risiko mit. Klären Sie, ob Fixtures Kunden- oder Mitarbeiterdaten enthalten, wie sie maskiert werden, wer darauf zugreifen kann und ob Löschpflichten Backups und Entwicklerkopien erreichen. Ein Käufer will bei der Integration nicht entdecken, dass die schnellste Testumgebung von einem unkontrollierten Produktionsabzug abhängt.

Übersetzen Sie das Ergebnis in Änderungskosten. Schwache Tests zwingen den Käufer zu langsameren Releases, mehr manueller Prüfung, einer höheren Störungsrate oder einer frühen Investition in Charakterisierungstests. Setzt die Roadmap schnelle Integration oder einen Plattformumbau voraus, kann fehlender Verhaltensnachweis den Preis verändern, weil es keinen günstigen Beweis dafür gibt, dass geänderte Software weiterhin dieselben Ergebnisse liefert.

Betriebsfähigkeit zeigt die versteckte Engineering-Rechnung

Betriebsfähigkeit zeigt, wie viel Arbeit die Software nach der Auslieferung verbraucht. Käufer sollten Releases, Beobachtbarkeit, Backup-Wiederherstellung, Störungsbehandlung, Kapazität und routinemäßige Datenreparatur prüfen. Ein Produkt kann stabil wirken, weil zwei erfahrene Menschen jeden Tag unbemerkt sichtbare Ausfälle verhindern. Ihre Arbeit gehört in das Kostenmodell.

Beobachten Sie einen normalen Release und, wenn es der Zeitplan erlaubt, ein Notfall-Rollback. Identifizieren Sie manuelle Tore, gemeinsame Konten, undokumentierte Befehle, veränderliche Server und Freigaben, die nur im Chat existieren. Bestätigen Sie, dass sich die ausgelieferte Version zum Quellcode zurückverfolgen lässt und das Team sagen kann, welche Datenbankmigrationen liefen. Ein Release-Dokument, das den Idealweg statt der tatsächlichen Praxis beschreibt, ist Dekoration.

Fordern Sie Störungsprotokolle und Beispielalarme an und verfolgen Sie dann einen jüngeren Vorfall von Erkennung über Diagnose bis Korrektur. Gute Belege umfassen Zeitstempel, Alarmverantwortung, Logs, Metriken, Kundenkommunikation, Folgearbeit und den Nachweis, dass die Korrektur die Produktion erreichte. Keine erfassten Vorfälle können ausgezeichnete Zuverlässigkeit bedeuten. Es kann ebenso heißen, dass das Unternehmen Vorfälle nicht erfasst. Telemetrie und Interviews unterscheiden beides.

Backups brauchen einen Wiederherstellungstest. Ein Screenshot geplanter Sicherungen belegt die Ausführung eines Jobs, nicht die Wiederherstellbarkeit des Geschäfts. Stellen Sie repräsentative Daten isoliert wieder her, prüfen Sie die Integrität, messen Sie den Ablauf und identifizieren Sie die bei einem echten Ausfall nötigen Zugangsdaten oder Lieferantenzugriffe. Vergleichen Sie das Ergebnis mit Kundenversprechen und internen Zielen, ohne Präzision zu erfinden, die das Unternehmen nie gemessen hat.

Manuelle Datenkorrekturen sind ein weiterer blinder Fleck. Durchsuchen Sie Ticketsysteme, Skripte, Notebooks und Shell-Historien nach Anpassungen an Salden, Aufträgen, Berechtigungen oder Berichten. Klären Sie Genehmigung, Protokollierung und Fortbestand der Ursache. Häufige sichere Korrekturen können normaler Betrieb sein. Ungeprüfte Schreibzugriffe auf Produktion schaffen finanzielle und prüfungsbezogene Risiken.

Diese Arbeit verändert den Preis, wenn wiederkehrende Arbeit in der Margendarstellung des Verkäufers fehlte, Kapazitätsarbeit vor Wachstum nötig ist, die Wiederherstellung vertragliche Zusagen nicht erfüllt oder die Integration eine angenommene Abhängigkeit entfernt. Sie verändert Bedingungen, wenn der Verkäufer vor Abschluss einen Restore-Test durchführen, Konten übertragen oder eine gefährliche Release-Kontrolle beheben kann.

Architektur zählt dort, wo sie die Deal-These begrenzt

Die Architekturprüfung sollte die geplante Nutzung durch den Käufer testen und keine modischen Diagramme belohnen. Ein Monolith kann ein guter Kauf sein, wenn er planbar ausgeliefert wird und den Wachstumsplan trägt. Eine Dienstesammlung kann zur Last werden, wenn Verantwortlichkeiten unklar sind, Aufrufe Zyklen bilden und jedes Release koordinierte Änderungen verlangt.

Ordnen Sie Geschäftsfähigkeiten Modulen, Datenspeichern, Queues, externen Schnittstellen und Deployment-Einheiten zu. Legen Sie dann die Deal-These auf diese Karte. Will der Käufer Kundenidentitäten zusammenführen, kann das System Mandanten trennen und Identitäten abgleichen? Erwartet er internationale Expansion, wo stecken Annahmen zu Währung, Steuern, Zeitzonen und Datenstandort? Hängen Einsparungen von Infrastrukturkonsolidierung ab, welche proprietären Dienste oder Netzwerkgrenzen widersetzen sich?

Suchen Sie Einschränkungen mit Belegen: nicht unterstützte Laufzeiten, End-of-Life-Mitteilungen von Anbietern, unbegrenzt wachsende Tabellen, synchrone Aufrufe in Umsatzwegen, gemeinsame Datenbankeigentümerschaft, fest codierte Umgebungsannahmen und Batch-Fenster nahe ihrer Grenze. Machen Sie Alter nicht automatisch zum Schweregrad. Eine alte Laufzeit hinter stabiler Schnittstelle kann einen begrenzten Ersatzweg haben. Ein neues Framework mit aufgegebenen Abhängigkeiten kann schwerer zu betreiben sein.

Daten sind meist der schwierige Integrationsteil. Prüfen Sie Schemaeigentum, Migrationshistorie, Aufbewahrungsregeln, Kennungen, Dublettenbehandlung, Prüfprotokolle und Abstimmungsjobs. Fragen Sie, wie das Team Teilausfälle repariert und nachgelagerte Verbraucher von Korrekturen erfahren. Wenn zwei Produkte dasselbe Wort für verschiedene Entitäten verwenden, löst ein API-Gateway den Bedeutungsunterschied nicht.

Schätzen Sie Änderungen anhand von Abschnitten beobachtbaren Verhaltens statt Codezeilen. Wählen Sie einen repräsentativen Geschäftsweg, listen Sie Ein- und Ausgaben sowie Abhängigkeiten auf und lassen Sie das Team erklären, wie es ihn verschieben oder ersetzen würde. Die Antwort zeigt, ob Grenzen praktisch existieren. Sie legt auch versteckte Arbeit in Stored Procedures, Desktop-Clients, Tabellen und geplanten Jobs offen, die Architekturdiagramme oft auslassen.

Eine Rewrite-Schätzung ist nicht automatisch ein Preisabzug. Sie wird dazu, wenn die Rendite vom Rewrite abhängt, das bestehende System eine andere nötige Änderung blockiert oder sein Weiterbetrieb Kosten verursacht, die in der Bewertung fehlten. Sonst verdient ein unmodernes, aber kontrolliertes System eher ein geplantes Modernisierungsbudget als einen Panikabschlag.

Sicherheitsbefunde brauchen Angriffsweg und Abhilfe

Sicherheitsbefunde beeinflussen eine Transaktion, wenn sie einen plausiblen Weg zu wesentlichem Schaden eröffnen oder eine fehlende Kontrolle zeigen, die der Käufer bereitstellen muss. Der Schweregrad eines Scanners ist nur ein Ausgangspunkt. Exponierung, Rechte, erreichbare Daten, vorhandene Gegenmaßnahmen, Angriffsvoraussetzungen und Erkennung bestimmen das Geschäftsrisiko.

Verfolgen Sie Identität von der Kundenanmeldung bis zu Administratorzugriff und Maschinenzugängen. Prüfen Sie Kontolebenszyklus, privilegierte Rollen, Durchsetzung von Mehrfaktorverfahren, Eigentum an Dienstkonten, Geheimnisspeicherung und Notfallzugriff. Ziehen Sie Stichproben realer Konten, statt Richtliniendokumente zu akzeptieren. Ehemalige Mitarbeiter mit aktiven Zugängen und gemeinsame Administratorpasswörter sind Tatsachen. Eine allgemeine Aussage zu schwacher Zugriffskontrolle ist keine.

Belegen Sie bei Schwachstellen, ob die betroffene Komponente ausgeliefert und erreichbar ist. Erfassen Sie Version, Aufrufweg, Eingabekontrolle, Berechtigungsgrenze, gefährdete Daten, kompensierende Kontrolle und Upgrade- oder Entfernungsweg. Abhängigkeitsbefunde in Testwerkzeugen verdienen eine andere Behandlung als dieselbe Bibliothek in einem öffentlich erreichbaren Dienst. Beide brauchen eine Entscheidung, doch nur Belege setzen Prioritäten.

Prüfen Sie, wie das Unternehmen Meldungen empfängt, einordnet, behebt und offenlegt. Betrachten Sie jüngere Patches und ihren Weg von Meldung zu Release. Gab es ein Sicherheitsereignis, gleichen Sie technische Unterlagen mit Kundenmitteilungen, Versicherungsangaben, Behördenkorrespondenz und Deal-Offenlegungen ab. Widersprüche können wichtiger sein als die ursprüngliche Lücke, weil sie Zusicherungen des Managements infrage stellen.

Regulierte Kunden bringen Anforderungen mit, doch die Unterstützung einer regulierten Umgebung ist keine Zertifizierung. Fragen Sie nach exakter Vertragskontrolle, Systemgrenze, Beleg und verantwortlicher Partei. Machen Sie aus Hostingwahl oder Penetrationstestbericht keine breite Compliance-Aussage. Käufer erben Zusagen aus unterschriebenen Verträgen, nicht die Adjektive einer Verkaufspräsentation.

Eine unmittelbare Kompromittierung, nicht offengelegte Ereignisse oder systemische Zugriffsfehler können den Abschluss blockieren. Behebbare Schwachstellen gehören meist in einen Maßnahmenplan mit Verantwortung und Nachweis. Diese Unterscheidung erhält die Glaubwürdigkeit des Berichts: Bedroht jedes veraltete Paket den Deal, hört niemand mehr zu, wenn ein Befund es tatsächlich sollte.

Befunde bewegen den Preis über wenige Mechanismen

Ein technisches Problem verändert die Wirtschaftlichkeit durch Behebungskosten, verzögerten Nutzen, laufende Kosten, verlorenen oder unterbrochenen Umsatz, bedingte Haftung oder eine höhere Wahrscheinlichkeit, dass die Deal-These scheitert. Prüfer sollten Scheingenauigkeit vermeiden, aber Mechanismus und Annahmen zeigen.

Nutzen Sie für jeden wesentlichen Befund einen Entscheidungsdatensatz. Diese Mindestform erwarte ich:

Finding: Settlement rules have one effective owner
Evidence: Only one engineer can trace, change, deploy, and recover the nightly job
Business path: Customer settlement and finance reconciliation
Deal effect: Integration cannot safely begin on the planned date
Control before close: Backup owner completes a change and recovery exercise
Residual action: Add characterization tests around recorded settlement cases
Owner and evidence date: [named person] / [date]
Term response: Closing condition or funded retention agreement
Price response: Cost only if the control cannot be completed
Confidence: Medium, recovery was observed but a live release was not

Dieser Datensatz trennt Tatsache und Reaktion. Er verhindert auch Doppelzählung. Enthält das Bewertungsmodell bereits ein Modernisierungsprogramm, dürfen Prüfer dieselbe Arbeit nicht erneut abziehen, außer die Prüfung erweitert Umfang oder Risiko. Kontrolliert ein Bindungspaket das Einzelpersonenrisiko, sollten Sie nicht zusätzlich das volle Ausfallszenario als sicher einpreisen. Zeigen Sie das Restrisiko nach der Kontrolle.

Verschiedene Mechanismen brauchen verschiedene Deal-Werkzeuge. Eine bekannte, begrenzte Behebung kann den Preis senken oder das Budget des Käufers erhöhen. Einen heilbaren Zustand kann man zur Abschlussbedingung machen. Ein konkretes Eigentums- oder Offenlegungsrisiko kann Zusicherung, Freistellung, Escrow oder Einbehalt verlangen, von Juristen ausgestaltet. Unsichere künftige Investitionen können Earn-out-Ziele oder die Investitionsrechnung beeinflussen, wobei schlecht konstruierte Earn-outs eigene Fehlanreize schaffen.

Ordnen Sie Befunde nach Entscheidung, nicht Scanner-Schweregrad. Der Vorstand muss wissen, was die Unterzeichnung verhindert, was vor Abschluss passieren muss, was den Wert verändert, was in den ersten Betriebsplan gehört und welches Risiko der Käufer akzeptiert. Die technischen Details bleiben darunter verfügbar, doch ein hundertseitiger Fehlerkatalog ersetzt diese Entscheidungen nicht.

Die Belegqualität braucht ein eigenes Urteil

Ein Prüfbericht sollte sagen, was Prüfer beobachteten, erhielten und reproduzieren konnten und was unerreichbar blieb. Belegqualität steuert das Vertrauen in jede technische Schlussfolgerung. Ein vom Verkäufer geliefertes Diagramm und ein beobachtetes Deployment verdienen nicht dasselbe Gewicht.

Verwenden Sie einfache Belegklassen: reproduziert, beobachtet, dokumentiert, berichtet und nicht verfügbar. Reproduziert heißt, der Prüfer führte den Ablauf aus und erhielt das Ergebnis. Beobachtet heißt, das Team führte ihn unter Aufsicht aus. Dokumentiert bedeutet, dass ein Artefakt die Aussage stützt. Berichtet bedeutet, dass jemand sie äußerte. Diese Klassen unterstellen dem Verkäufer keine Unredlichkeit, sondern zeigen die verbleibende Unsicherheit.

Auch Stichproben brauchen Grenzen. Prüfen Reviewer drei von vierzig Diensten, nennen Sie Auswahlgrund und nicht abgedeckte Risiken. Wählen Sie Umsatzwege, privilegierte Komponenten, jüngere Änderungen und bekannte Problemstellen vor den aufgeräumten Repositories. Zufallsauswahl kann Urteil ergänzen, doch reine Zufälligkeit verfehlt oft die Systeme, die dem Deal schaden können.

Zugriffsbeschränkungen sind Befunde, wenn sie eine wesentliche Aussage verhindern. Eine Produktionsdatenbank kann zu Recht gesperrt bleiben, doch der Verkäufer kann oft Schemaexporte, maskierte Stichproben, Abfragepläne, aufgezeichneten Verkehr oder eine beobachtete Sitzung liefern. Gibt es keinen Ersatz, erfassen Sie die offene Frage und mögliche Deal-Wirkung. Machen Sie aus "nicht getestet" kein "kein Problem gefunden".

Die Abschlussbesprechung muss für Engineering, Finanzen, Juristen und Deal-Leitung verständlich sein. Jede Gruppe braucht dieselben Tatsachen in anderer Auflösung. Halten Sie einen gemeinsamen Quelldatensatz für Belege und Entscheidungen, damit eine späte Änderung keine widersprüchlichen Folien, Tabellen und Vertragsanlagen hinterlässt.

Der erste Betriebsplan beginnt vor der Unterschrift

Gute technische Due Diligence hinterlässt dem Käufer einen ausführbaren Eigentumsplan, selbst wenn der Deal nicht schließt. Das wichtigste Ergebnis ist eine kurze Liste kontrollierter Entscheidungen: Welches Risiko ändert Bedingungen, welcher Beleg fehlt, wer verantwortet jede Vorabschlussmaßnahme und welche Arbeit gelangt nach Abschluss in den finanzierten Plan?

Ordnen Sie Arbeit nach Abhängigkeit und Folge. Sichern Sie Administratorzugriff vor Änderungen am Deployment. Erfassen Sie Produktionsverhalten, bevor Sie Regeln ersetzen. Übertragen Sie Lieferanten- und Betreiberwissen, bevor Kündigungsfristen enden. Üben Sie die Wiederherstellung vor der Infrastrukturkonsolidierung. Das sind konkrete Kontrollen, kein allgemeiner Backlog.

Legacy-Code bündelt oft mehrere Risiken: knappes Wissen, schwache Tests, gemischte Herkunft und Verhalten in Batch-Jobs, Stored Procedures, Desktop-Code und Tabellen. CodeHero bearbeitet genau diesen Modernisierungsfall, indem es die ganze Codebasis liest, die Architektur wo passend in Go, Rust, TypeScript und Postgres neu schreibt und die Parität anhand aufgezeichneten Produktionsverkehrs prüft, mit Lieferung in unter 30 Tagen. Das kann die Behebungsoption verändern, doch der Käufer braucht weiterhin klares Eigentum, verlässliche Belege und Betriebsbefugnis.

Lassen Sie den Bericht nicht mit einem durchschnittlichen Risikowert enden. Nennen Sie die Bedingung, unter der der Deal noch funktioniert. Kann der Käufer den Release-Weg besitzen, kritisches Wissen halten oder übertragen, Lizenzausnahmen klären und Verhaltensparität messen, haben die Engineering-Risiken Grenzen. Lassen sich diese Bedingungen nicht erfüllen, muss der Preis die Unsicherheit tragen, statt das Integrationsteam sie nach der Unterschrift entdecken zu lassen.