Die meisten Legacy-Modernisierungsgespräche beginnen an der falschen Stelle. Jemand erklärt „wir müssen migrieren", und die Organisation verbringt drei Monate damit, eine Roadmap für ein Mehrjahresprogramm zu zeichnen. Zwölf Monate später existiert die Roadmap, migriert wurde nichts, und das Legacy-System hat ein weiteres Jahr an Workarounds angesammelt.
Das Problem ist nicht fehlende Planung. Es ist fehlende Diagnose. Bevor Sie entscheiden können, was modernisiert werden soll, wie und wann, müssen Sie verstehen, wo der Druck tatsächlich liegt. Nicht jedes Legacy-System braucht sofortige Aufmerksamkeit. Nicht jede technische Schuld erzeugt gleiche Reibung. Und die Systeme, die sich am schlimmsten anfühlen, sind nicht immer diejenigen, die den meisten Wert blockieren — oder das größte Risiko tragen.
Genau das soll der Legacy Readiness Check beantworten: Wo ist der Modernisierungsdruck am höchsten, und was sollten Sie zuerst dagegen tun?
Warum der Druck jetzt steigt
Lange war Legacy-Modernisierung eine reine Effizienzfrage — man konnte sie aufschieben, solange das System lief. Das hat sich verschoben, und zwar aus zwei Richtungen gleichzeitig.
Regulatorisch. Das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) ist seit dem 6. Dezember 2025 in Kraft und betrifft nach Schätzung der Bundesregierung rund 29.500 Unternehmen in 18 Sektoren. Für die technischen und organisatorischen Maßnahmen nach § 30 BSIG sieht das Gesetz keine Übergangsfrist vor — sie gelten ab Inkrafttreten. Ein Legacy-System, dessen Hersteller-Support ausgelaufen ist, das keine sauberen Zugriffs- und Protokollierungsmechanismen kennt oder dessen Abhängigkeiten niemand mehr vollständig überblickt, ist damit nicht länger nur ein Effizienzthema. Es wird zu einer Nachweis- und Haftungsfrage für die Geschäftsführung.
Technologisch. Wer KI-Workflows produktiv schalten will, stößt früher oder später auf die Datenfrage. Der EU AI Act verlangt für Hochrisiko-Systeme nach Artikel 10 Trainings-, Validierungs- und Testdaten, die „relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig" sind — eingebettet in dokumentierte Data-Governance-Praktiken. Selbst wo ein konkreter Anwendungsfall nicht als Hochrisiko gilt, gibt diese Messlatte die Richtung vor: KI braucht zuverlässigen, zeitnahen und nachvollziehbaren Datenzugriff. Ein Legacy-Kern, der seine Daten nur per Nacht-Batch und Custom-Skript herausgibt, ist nicht der Engpass von morgen — er ist der Engpass von heute.
Beide Kräfte treffen denselben Punkt: Das Legacy-System ist nicht mehr nur teuer im Betrieb, es begrenzt aktiv, was die Organisation darf und kann. Der Readiness Check übersetzt dieses diffuse Gefühl in eine priorisierbare Diagnose.
Für wen das relevant ist
Der Readiness Check ist relevant, wenn mehrere der folgenden Bedingungen zutreffen: wenn Legacy-Systeme Ihre Fähigkeit verlangsamen, Änderungen auszuliefern; wenn Support- und Wartungsaufwand Jahr für Jahr steigt; wenn Teams sich auf manuelle Workarounds verlassen, um Systemeinschränkungen zu kompensieren; wenn Modernisierung seit Jahren diskutiert, aber nie begonnen wurde, weil der Umfang zu groß erschien; oder wenn Sie KI-Workflows deployen möchten, die darunterliegenden Systeme das aber nicht tragen.
Trifft nichts davon zu, ist Ihr Legacy-Stack wahrscheinlich in Ordnung — betreiben Sie ihn weiter und investieren Sie Ihre Aufmerksamkeit anderswo. Treffen drei oder mehr Punkte zu, haben Sie Modernisierungsdruck. Die einzige offene Frage ist dann, wo Sie den Fokus setzen.
Die sechs Bewertungsdimensionen
Wir bewerten Legacy-Readiness über sechs Dimensionen. Jede erfasst eine andere Art von Reibung und weist auf eine andere Intervention hin. Das Ziel ist nicht, alles zu scoren und in eine Rangliste zu pressen. Es ist, die ein oder zwei Dimensionen zu identifizieren, in denen der Druck am höchsten und Handeln am dringlichsten ist.
Dimension 1: Systemkomplexität und technische Schulden. Die Leitfrage lautet: Wie viel der Systemlogik ist dokumentiert, wie viel implizit? Kann ein neuer Entwickler das System in vertretbarer Zeit verstehen, oder dauert es ein halbes Jahr, bis jemand produktiv ist? Warnsignale sind Business-Logik, die in Stored Procedures, Triggern oder Batch-Skripten lebt, die kein aktuelles Teammitglied geschrieben hat; fehlende oder nicht vertrauenswürdige Testabdeckung; ein Architekturdiagramm, das — falls es existiert — seit Jahren nicht aktualisiert wurde; und der Satz „an dieses Modul fasst niemand ran" als fester Bestandteil von Teamgesprächen. Niedriger Schweregrad: das System ist komplex, aber verstanden, und Änderungen sind mit vertretbarem Aufwand möglich. Hoher Schweregrad: das System ist eine Blackbox, jedes Deployment ist ein Risiko-Event, und das Wissen konzentriert sich auf ein oder zwei Personen.
Dimension 2: Operative Engpässe und manuelle Workarounds. Hier geht es um die Frage, wo Teams auf das System warten oder darum herum arbeiten — und wie viele Prozesse rein dazu existieren, etwas zu kompensieren, das das System eigentlich tun sollte. Warnsignale sind parallele Spreadsheets neben den eigentlichen Systemdaten, Vorgänge, die wegen Systemeinschränkungen Stunden statt Minuten dauern, und einzelne Personen, die für bestimmte Aufgaben unverzichtbar sind, weil nur sie den Workaround kennen. Beim höchsten Schweregrad sind die Workarounds der Prozess: Das System läuft nominell, aber die eigentliche Arbeit passiert außerhalb. In der Praxis sehen wir dieses Muster regelmäßig dort, wo zwei Systeme ohne zuverlässige Datenverbindung nebeneinander laufen und ein ganzes Team de facto zur menschlichen Integrationsschicht wird, die nächtlich Differenzen abgleicht. Das ist kein Personalproblem. Das ist ein Modernisierungssignal.
Dimension 3: Delivery-Friction und Change-Constraints. Wie lange dauert es, eine Änderung von der Idee bis in Produktion zu bringen — und welcher Anteil davon ist echte Entwicklung gegenüber Deployment, Testing, Freigabe und Koordinations-Overhead? Warnsignale sind einfache Änderungen, die Wochen bis Monate brauchen, Deployment-Fenster nur abends oder am Wochenende, manuelles und unzuverlässiges Testing sowie ein Backlog mit Items, die seit Jahren aufgeschoben werden, weil das System sie nicht leicht aufnimmt. Beim höchsten Schweregrad ist das System faktisch eingefroren: Die Organisation routet um es herum statt hindurch, und Feature-Entwicklung ist zugunsten reiner Wartung praktisch zum Erliegen gekommen.
Dimension 4: Integrations- und Datenabhängigkeiten. Wie verbindet sich dieses System mit anderen — Punkt-zu-Punkt oder über eine Integrationsschicht? Wie weit propagiert der Impact, wenn sich etwas ändert? Und wie zugänglich sind die Daten für nachgelagerte Konsumenten wie Reporting, Analytics oder KI-Workflows? Warnsignale sind Integrationen über geteilte Datenbanken, File-Drops oder FTP statt über APIs oder Event-Streams; das Fehlen eines vollständigen Bilds aller abhängigen Systeme; Änderungen, die regelmäßig etwas Nachgelagertes brechen; und ein Datenzugriff, der nur über Batch-Schedules und Custom-Skripte funktioniert. Diese Dimension ist besonders wichtig für die KI-Readiness: KI-Workflows brauchen zuverlässigen, zeitnahen Datenzugriff, und der EU AI Act macht diese Qualitätsanforderung für Hochrisiko-Anwendungen sogar zur Rechtspflicht. Kann das Legacy-System das nicht liefern, brauchen Sie eine Stabilisierungs- oder Entkopplungsintervention, bevor irgendein KI-Workflow tragfähig läuft.
Dimension 5: Support-Last und Wartungsdruck. Wie viel Teamkapazität fließt in den laufenden Betrieb gegenüber echten Verbesserungen — und wohin zeigt der Trend? Warnsignale sind ein wachsender Anteil der Engineering-Kapazität, der in Wartung und Incident-Response versickert; steigende Incident-Häufigkeit; eine Wiederherstellung nach Ausfällen, die Spezialwissen weniger Personen erfordert; und ein Hersteller-Support, der ausgelaufen ist oder ausläuft. Letzteres ist seit NIS2 doppelt brisant, weil nicht mehr unterstützte Komponenten unmittelbar in die Pflicht zu angemessenen technischen Maßnahmen hineinspielen. Beim höchsten Schweregrad ist Support die Haupttätigkeit: Das Team steht im reaktiven Modus, es gibt keine Kapazität für Verbesserungen, und der Netto-Wertzuwachs tendiert gegen null.
Dimension 6: Modernisierungs-Blocker, Risiken und Chancenbereiche. Warum hat Modernisierung bisher nicht stattgefunden? Liegt es am Budget, am Risiko des Wissensverlusts, an einer unklaren Zielarchitektur, an politischen Besitzverhältnissen oder schlicht an der Angst vor Disruption? Den Blocker zu verstehen ist genauso wichtig wie die technischen Schulden zu verstehen — denn ein Programm, das den eigentlichen Blocker ignoriert, scheitert zuverlässig ein zweites Mal. Warnsignale sind ein mehrfach abgelehnter Modernisierungsvorschlag, ein Budget, das immer „nächstes Jahr" kommt, einflussreiche Stakeholder, die vom Status quo profitieren, und frühere gescheiterte Versuche, die organisatorisches Narbengewebe hinterlassen haben. Auf der Gegenseite identifiziert diese Dimension die Chancenbereiche: schnelle Erfolge an Komponenten, die sich risikoarm stabilisieren oder entkoppeln lassen; Bereiche von strategischem Wert, in denen Modernisierung direkt hochwertige KI- oder Automatisierungs-Workflows ermöglicht; Wissensbewahrung durch Dokumentations- und Architektur-Recovery, bevor Schlüsselpersonen das Unternehmen verlassen; und KI-Shift-Opportunities, in denen „jetzt Wert schaffen, später migrieren" die bessere Reihenfolge ist.
Was der Readiness Check liefert
Das Ergebnis eines Readiness Checks ist keine Migrations-Roadmap. Es ist eine Diagnose.
Im Kern steht eine Severity Map über alle sechs Dimensionen, die zeigt, wo der Schmerz am größten und Handeln am dringlichsten ist. Das Ergebnis ist oft überraschend: Das System, das die meisten Beschwerden erzeugt, ist nicht immer das mit dem höchsten Schweregrad — und selten das mit dem höchsten Risiko. Dazu kommen Reibungspunkte mit Business-Impact, also nicht nur „dieses System ist alt", sondern „dieses System kostet uns spürbare Kapazität an manuellen Workarounds und blockiert messbaren Wert, der über KI-Workflows erreichbar wäre". Drittens benennt der Check, wo Modernisierung Hebelwirkung erzeugt — denn nicht alles muss modernisiert werden, und häufig setzt eine gezielte Stabilisierungs- oder Entkopplungsintervention mehr Wert frei als eine Full-Migration. Und schließlich liefert er einen empfohlenen ersten Schritt: keine Zwölf-Monats-Roadmap, sondern eine spezifische, in Wochen gescopte Intervention, die die Dimension mit dem höchsten Schweregrad adressiert. Einen vollständigen Überblick über die Interventionsoptionen finden Sie unter Legacy-Modernisierung für KI.
Was der Readiness Check nicht ist
Er ist kein vollständiges Architektur-Review. Er produziert kein Zielzustands-Design, keine Vendor-Auswahl, keine Plattformbewertung und keine Migrationsplanung. Das sind nachgelagerte Aktivitäten, die den Readiness Check als Input benötigen, ihn aber nicht ersetzen.
Er ist auch kein Urteil über die Menschen, die das Legacy-System gebaut haben oder betreuen. Legacy-Systeme sind das Ergebnis rationaler Entscheidungen unter früheren Rahmenbedingungen. Der Readiness Check bewertet die heutige Situation gegen die heutigen Anforderungen — nicht die Geschichte.
Wie Sie die Ergebnisse nutzen
Der Readiness Check erzeugt drei mögliche Outputs, die jeweils eine klare Handlung tragen.
Kein sofortiger Handlungsbedarf. Das System hat Legacy-Eigenschaften, aber der Schweregrad ist über alle Dimensionen niedrig und es bestehen keine offenen Compliance-Lücken. Beobachten, nicht modernisieren — und in zwölf Monaten neu bewerten.
Gezielte Intervention. Eine oder zwei Dimensionen zeigen hohen Schweregrad. Dann adressieren Sie gezielt: die Integrationsschicht stabilisieren, die Datenpipeline entkoppeln oder die spezifische Komponente modernisieren, die Wertschöpfung oder Compliance blockiert. Das ist Wochen bis wenige Monate Arbeit, nicht Jahre.
Migrations-Trigger. Drei oder mehr Dimensionen zeigen hohen Schweregrad, und der Trend verschlechtert sich — oder eine regulatorische Frist macht die Lücke unhaltbar. Dieses System braucht einen Migrationsplan, und der Readiness Check liefert die Daten, um diesen Case belastbar gegenüber der Geschäftsführung zu machen.
Die Kosten des Diagnose-Verzichts
Der häufigste Fehlermodus bei Legacy-Modernisierung ist, ohne Diagnose loszulegen. Die Organisation committet sich zu einem großen Programm, scopt es auf Basis von Annahmen statt Assessment und stellt auf halbem Weg fest, dass der eigentliche Blocker ein anderer war als erwartet. Bei Modernisierung unter regulatorischem Druck ist dieser Fehler besonders teuer: Wer das falsche System zuerst anfasst, verbrennt Monate, während die nachweispflichtige Lücke offen bleibt.
Ein Readiness Check dauert Tage, nicht Monate. Die Kosten der Durchführung sind trivial im Vergleich zu den Kosten eines falsch gescopteten Modernisierungsprogramms. Der eigentliche Wert liegt im Fokus: genau zu wissen, wo Sie anfangen, warum, und welches Ergebnis Sie erwarten dürfen.
Ein Fit Call übersetzt Ihre Druckpunkte in eine priorisierte Severity Map und einen konkreten ersten Schritt — bevor Sie Budget in ein Mehrjahresprogramm binden, das am falschen System ansetzt.
References: Bundesgesetzblatt, „Gesetz zur Umsetzung der NIS-2-Richtlinie (NIS2UmsuCG)," 2025, https://www.recht.bund.de/bgbl/1/2025/301/VO.html; EU Artificial Intelligence Act, „Article 10: Data and Data Governance," 2024, https://artificialintelligenceact.eu/article/10/.