Ein System übernehmen, das niemand dokumentiert hat
Die Leute, die es geschrieben haben, sind weg, und niemand kann zusagen, dass eine Änderung nicht etwas anderes zerlegt. Statt zu raten: einmal scannen und offenlegen, was drinsteckt, was was aufruft und wo das Risiko sitzt.
Vier Situationen, ein Problem
Selbst gebaut – und der Autor ist gegangen
Das System wurde intern entwickelt und gepflegt, der Entwickler ist vor Jahren gegangen, und die Übergabe bestand aus einem Dokument. Heute lässt sich nicht einmal ein Feld ändern, ohne dass jemand sagen kann, ob dabei etwas anderes kaputtgeht.
Extern entwickelt, Dienstleister längst weg
Das System wurde damals beauftragt und mit der Abnahme abgeschlossen. Der ursprüngliche Dienstleister hat gewechselt oder nimmt solche Aufträge nicht mehr an. Sie haben nur den Quellcode und keine Vorstellung, was darin steckt.
Ein Kunde hat Ihnen die Wartung übergeben
Beratungen und Entwicklungshäuser übernehmen das Bestandssystem eines Kunden und müssen vor dem Angebot beantworten, ob sich etwas ändern lässt und wie lange es dauert – mit nichts als manueller Code-Lektüre als Grundlage.
Ausschreibung gewonnen, Vorgängersystem geerbt
Nach dem Zuschlag übernehmen Sie, was der vorherige Auftragnehmer hinterlassen hat. Übergabe und Abnahme brauchen Belege; Erfahrungsberichte unterschreibt ein Auftraggeber nicht.
Was Sie nach dem ersten Tag in der Hand haben
Kein „Risiko eher hoch", sondern Dinge, mit denen Sie in eine Besprechung gehen und auf eine Datei zeigen können.
Wie dieses System tatsächlich aussieht
Klassendiagramme, Paketdiagramme, Komponentendiagramme, Aufrufgraphen, Abhängigkeitsgraphen, Datenflussdiagramme, Sequenzdiagramme, Verteilungsdiagramme – insgesamt 20 Arten, direkt aus dem Code erzeugt. Nach Rolle filterbar (Systemanalyse, Systemdesign, Entwicklung, Datenbankadministration, Oberflächengestaltung, Projektleitung, Compliance, Leitungsebene – neun insgesamt), damit Sie nicht alles auf einmal lesen müssen.
Was nicht stimmt, und in welcher Zeile
Alle 31 Frameworks werden im selben Scan ausgewertet, und jede Feststellung verweist auf eine konkrete Datei und Zeile, nach Risiko sortiert. Diese Liste ist die Grundlage für Aufwandsschätzung und Priorisierung.
Welche Pakete verwendet werden – und was darin lauert
Die SBOM listet jede Abhängigkeit, ihre Lizenzbedingungen und bekannte Schwachstellen, als CycloneDX und SPDX. Lizenzprobleme oder nicht mehr gepflegte Pakete sehen Sie, bevor Sie das System übernehmen – nicht danach.
Gesamtzustand – und klar benannt, welche Achsen geschätzt sind
Der Risiko-Fingerabdruck mit acht Achsen: Die Sicherheitslage wird durch den Scan gemessen. Dokumentation, Tests, Abhängigkeiten und technische Schulden sind derzeit Systemvorgaben, im Diagramm mit (geschätzt) gekennzeichnet und nie als Risikofeststellung ausgewiesen. Uns ist die Kennzeichnung lieber, als Ihnen ein Diagramm zu geben, das voller aussieht, als es ist.
Die menschliche Seite
Der Fragebogen zur Risikobewertung deckt ab, was ein Scan nicht sieht: Systemübergabe, Anforderungsnachverfolgung, Änderungsprognose, Abnahmekriterien und Kommunikationsaufwand. Diese Werte stammen aus den Antworten Ihres Teams, nicht aus einem Code-Scan.
Berichte und Ergebnisse gehören Ihnen. Sie können sie unmittelbar an Kunden oder die Geschäftsleitung weitergeben – als Anlage zu Übergabe, Abnahme oder Angebot.
Was gelesen werden kann
Das ist meist die erste Frage, deshalb hier klar: Die Analyse hat zwei Schichten. Die .NET-Familie bekommt einen Syntaxbaum plus Compliance- und Sicherheitsregeln; die übrigen 62 Technologiefamilien bekommen syntaktisches Parsing und Aufrufbeziehungen, aber nicht diese Regeln.
Tiefenanalyse (Syntaxbaum-Ebene)
C#, VB.NET und ASP.NET WebForms (.aspx samt Code-Behind). Klassenvererbung und Abhängigkeiten, API-Endpunkte, Datenfluss, Geschäftslogik und Fehlerbehandlung werden auf dieser Ebene analysiert.
Dateien, die die Compliance-Regeln scannen
.cs, .vb, .aspx, .sql, .config, .json, .xml, .yml, .yaml, .ps1, .sh, .tf sowie .md- und .txt-Dokumente. Die Befundliste für die ursprünglichen 24 Rahmenwerke stammt aus diesen Dateien; die sieben KI-Governance-Rahmenwerke betrachten gesondert die KI-Nutzung in allen unterstützten Sprachen. Endungen wie .cbl, .pas, .pbl, .prg und .abap stehen nicht auf der Liste; ein fest einkodiertes Passwort oder ein SQL-Injection-Muster im Quellcode alter Sprachen taucht daher nicht in den Befunden auf – dort geht es um Struktur und Aufrufbeziehungen.
Syntaktisches Parsing und Aufrufbeziehungen (62 Technologiefamilien)
Java, Python 2/3, PHP 5/7/8, Go, Rust, C++, SAP ABAP, PowerBuilder, VB6, COBOL (85/2002/IBM/Micro Focus/GnuCOBOL), Delphi, FoxPro, Fortran, Pro*C, klassisches ASP (VBScript/JScript), AngularJS, jQuery, Ember, TypeScript, CoffeeScript, Blazor, Flutter, MAUI, Xamarin, Flash/Flex, Silverlight sowie .NET-DLLs ohne Quellcode (nach Dekompilierung erfasst). Diese Schicht zählt nicht nur Dateien: Sie extrahiert Programme, Klassen und Prozeduren, baut den Aufrufgraphen, erfasst je Routine die Anzahl von Verzweigungen, Schleifen und Ausnahmebehandlungen und markiert dynamische Aufrufstellen – jene Punkte, deren Ziel erst zur Laufzeit feststeht und die bei Migrationen am häufigsten übersehen werden. Bei COBOL werden zusätzlich Copybooks expandiert (inklusive REPLACING) und der Dialekt erkannt. Diese Ergebnisse fließen in dieselbe Bestandsliste wie die .NET-Schicht, sodass Diagramme und Auswirkungsanalyse sie mit abdecken.
Woher der Code kommt
Eine Git-Repository-URL (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea und andere; selbst betriebene Git-Server im internen Netz müssen in den Einstellungen freigegeben werden) oder ein ZIP-Upload mit bis zu 2 GB je Übermittlung. Ohne CI und ohne Pull-Request-Prozess geht es auch – Ordner zippen, fertig.
Diese Schicht setzt Python auf dem Host der Analyse-Engine (Agent) voraus; jede Technologiefamilie lässt sich einzeln ein- und ausschalten.
Derzeit nicht unterstützt
TFVC und SVN lassen sich nicht direkt anbinden (stattdessen ZIP hochladen), ebenso wenig Oracle-PL/SQL-Pakete, Excel-VBA-Makros sowie Programme für SPS- und OT-Steuerungen. Besser, Sie wissen es vorher als mitten im Scan.
Wenn der alte Stack ersetzt werden soll
Das Modul für Technologie-Stack-Migration beginnt mit einer Bewertung: worauf das System heute läuft, in wie viele Phasen der Umstieg zerfällt und welche Dateien jede Phase berührt. Die automatische Umstellung (Codemods) ist derzeit auf .NET ausgerichtet – WebForms zu Razor, EF6 zu EF Core, .NET Framework zu .NET 9. Für andere Sprachen gibt es die Bewertung und den Compliance-Vergleich vorher/nachher; die Umstellung selbst führt Ihr Team durch.
- Compliance-Zustand vorher und nachher nebeneinander – der Nachweis, dass das Upgrade die Sicherheit nicht verschlechtert hat
- Die Ergebnisse jeder Phase bleiben im Dokumentenzentrum, herunterladbar und nachvollziehbar
- Umstellungsergebnisse lassen sich direkt als Pull Request öffnen (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea)
Fangen Sie mit einem Projekt an
Der kostenlose Plan bleibt dauerhaft kostenlos: 1 Platz, 3 Analysen pro Monat, Online-Einsicht in den vollständigen Bericht samt Bewertungen. Die Online-Selbstregistrierung ist noch nicht geöffnet, sprechen Sie uns also zuerst an, wenn Sie echte Ergebnisse sehen wollen. Darf Ihr Code das Netz nicht verlassen, reden wir über den Betrieb in Ihrer eigenen Umgebung.