Vier Leute verstehen dieses System. Drei gehen in Rente.
Es läuft seit achtzehn Jahren, es trägt das Geschäft, und niemand kann mehr vollständig sagen, was darin passiert. Modernisieren kann man nur, was man versteht. Wir machen Struktur, Logik und Abhängigkeiten sichtbar – bevor irgendjemand etwas anfasst.
Vier Sätze, die wir in fast jedem Erstgespräch hören.
Keiner davon handelt von Technologie. Alle vier handeln davon, dass Wissen verschwunden ist, während das System weiterlief.
Ändern dauert bei uns sechs Monate. Auch Kleinigkeiten.
Nicht weil die Änderung schwer wäre, sondern weil niemand mit Sicherheit sagen kann, was sonst noch daran hängt. Also wird getestet, was ohnehin nie kaputtging – und das Eigentliche übersehen.
Die Dokumentation? Die ist von 2011.
Sie beschreibt ein System, das es so nicht mehr gibt. Gefährlicher als keine Dokumentation ist eine, der man noch glaubt.
Herr K. weiß das. Der ist aber nächstes Jahr weg.
Das Wissen, das über zwanzig Jahre entstanden ist, steht in keinem Repository. Es steht in einem Kopf, und dieser Kopf hat ein Austrittsdatum.
Der Anbieter sagt: neu bauen oder gar nichts.
Eine Neuentwicklung ist die teuerste Art, dasselbe Nichtwissen noch einmal zu produzieren. Wer nicht weiß, welche Regeln im Alten stecken, kann sie im Neuen nicht abbilden.
Wir graben das System aus, statt es zu erraten.
Quellcode, Datenbankschemata, Schnittstellen, Logs, Tickets, Betriebsdaten. KI liest die Mengen, die ein Team in Workshops nie durcharbeiten könnte – und wir bewerten, was dabei herauskommt. Am Ende steht keine Vermutung, sondern eine Karte.
Beispielhafte Darstellung, keine Kundendaten. Die gestrichelten Kanten sind der eigentliche Ertrag: Stellen, an denen etwas passiert, das in keinem Dokument steht. Genau dort kippen Modernisierungsprojekte.
Wir sammeln, was da ist: Repositories, Schemata, Schnittstellendefinitionen, Betriebslogs, Tickets, alte Fachkonzepte. Dazu vier bis sechs Gespräche mit denen, die das System heute am Leben halten.
- Read-only
- keine Produktivzugriffe
- NDA vorab
Agenten arbeiten den Bestand durch: Modulgrenzen, Aufrufketten, Datenflüsse, tote Pfade, doppelte Logik, Geschäftsregeln, die ausschließlich im Code stehen. Wir prüfen die Funde und verwerfen, was nicht trägt.
- Abhängigkeitsgraph
- Business-Regel-Extraktion
- Security-Befunde
Je Komponente eine Entscheidung mit Begründung: behalten, kapseln, zerlegen, migrieren, ersetzen, stilllegen. Priorisiert nach Geschäftswert, Risiko und Abhängigkeitstiefe – nicht nach technischer Eleganz.
- Aufwandsspannen
- Risikoklassen
- Reihenfolge
Eine Sitzung mit allen, die entscheiden. Sie bekommen die Karte, die Roadmap und eine Pilotempfehlung – und die Liste dessen, was wir nicht herausfinden konnten. Die ist oft die nützlichere.
- Entscheidungsvorlage
- Systemlandkarte
- offene Punkte
Legacy Discovery. Zehn Tage, ein System, ein Ergebnis.
Kein Rahmenvertrag, keine Vorstudie über die Vorstudie. Ein abgegrenztes System, ein Festpreis, ein Termin, an dem etwas auf dem Tisch liegt.
Legacy System Discovery
Anwendungen, Datenbanken, Schnittstellen, Abhängigkeiten – belegt und unterschieden von vermutet.
Welche Komponenten Sie nicht anfassen können, ohne dass anderswo etwas ausfällt.
Je Komponente eine begründete Empfehlung mit Aufwandsspanne, nicht eine Gesamtempfehlung.
Der Bereich, an dem sich Methode und Zielarchitektur mit dem geringsten Risiko beweisen lassen.
Vier Module, einzeln buchbar.
Vertiefte Analyse, priorisierte Roadmap, Entscheidungsvorlage für das Investitionsgremium.
Ein abgegrenzter Bereich wird tatsächlich modernisiert. Zielarchitektur und Methode werden validiert, nicht behauptet.
Ihre Teams arbeiten künftig selbst so. Werkzeuge, Prozesse, Guardrails – nicht ein Tool-Training.
Wiederholbare Analyse- und Migrationspipelines für System zwei bis zwanzig.
Ihr Team schreibt jetzt dreimal so viel Code. Wer liest ihn?
Die Frage kommt spätestens sechs Monate nach dem Copilot-Rollout, und sie hat noch kaum jemand beantwortet. Hundert Entwickler mit KI erzeugen mehr Änderungen, als hundert Reviewer prüfen können. Wer die Kontrolle proportional mitwachsen lässt, gibt den Produktivitätsgewinn wieder ab. Wer sie weglässt, merkt es im Betrieb.
- Manuelle Code Reviews
- Pull-Request-Prüfung durch Erfahrung
- Stichproben bei Sicherheit
- Dokumentation von Hand kontrolliert
- Freigabe pro Änderung, gleich welcher
Entwickelt unter der Annahme, dass Menschen den Code schreiben. Skaliert nicht mit dem Volumen.
- Prüfbare Eigenschaften statt gelesener Zeilen
- Guardrails als Code, automatisch durchgesetzt
- Risikoklassen: nicht jede Änderung gleich streng
- Human in the Loop dort, wo es wehtut
- Nachweisführung statt Vertrauensvorschuss
Die Frage verschiebt sich von „hat jemand das gelesen" zu „lässt sich belegen, dass es tut, was es soll".
Beides gehört zusammen. Die Analyse schafft Verständnis über das Bestehende; das Engineering-Modell sorgt dafür, dass die nächsten zehn Jahre nicht wieder in einem System enden, das niemand mehr versteht.
KI modernisiert Ihr System nicht von allein.
Sie können mit KI Quellcode, Schemata und Betriebsdaten in einer Größenordnung auswerten, die manuell nicht geht. Das ist der ganze Hebel, und er ist groß. Er ersetzt keine Architekturentscheidung.
Welche Komponente gekapselt und welche zerlegt wird, welche Geschäftsregel wirklich noch gilt, welches Risiko tragbar ist – das bleibt Ingenieursarbeit mit Verantwortung. Wer Ihnen vollautomatische Modernisierung verkauft, hat entweder ein kleines System vor sich oder eine große Rechnung im Hinterkopf.
Und einen Fall gibt es, in dem wir abraten: Wenn das System in zwölf Monaten ohnehin durch Standardsoftware ersetzt wird, lohnt die Grabung nicht. Dann sagen wir das im Erstgespräch, nicht in Woche drei.
Bringen Sie das System mit, das Ihnen Sorgen macht.
30 Minuten, kein Vertrieb. Wir sagen Ihnen, ob eine Discovery bei diesem System etwas bringt – und falls nicht, warum.