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 erstellen. Zwölf Monate später existiert die Roadmap, nichts wurde migriert, 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 modernisiert werden soll oder wann modernisiert werden soll, müssen Sie verstehen, wo der Druck tatsächlich liegt. Nicht jedes Legacy-System braucht sofortige Aufmerksamkeit. Nicht jede technische Schuld erzeugt gleiche Reibung. Die Systeme, die sich am schlimmsten anfühlen, sind nicht immer diejenigen, die den meisten Wert blockieren.
Genau das soll der Legacy Readiness Check beantworten: Wo ist der Modernisierungsdruck am höchsten, und was sollten Sie zuerst dagegen tun?
Für wen das relevant ist
Der Readiness Check ist relevant, wenn eine oder mehrere dieser Bedingungen zutreffen:
- Legacy-Systeme verlangsamen Ihre Fähigkeit, Änderungen auszuliefern
- Support- und Wartungsaufwand steigt Jahr für Jahr
- Teams verlassen sich auf manuelle Workarounds, um Systemeinschränkungen zu kompensieren
- Modernisierung wird seit Jahren diskutiert, aber nie begonnen, weil der Umfang zu groß erschien
- Sie möchten KI-Workflows deployen, aber die darunterliegenden Systeme können sie nicht unterstützen
Wenn nichts davon zutrifft, ist Ihr Legacy-Stack wahrscheinlich in Ordnung. Betreiben Sie ihn weiter.
Wenn drei oder mehr zutreffen, haben Sie Modernisierungsdruck. Die Frage ist, wo Sie den Fokus setzen.
Die sechs Bewertungsdimensionen
Wir bewerten Legacy-Readiness über sechs Dimensionen. Jede Dimension erfasst eine andere Art von Reibung und weist auf eine andere Intervention hin. Das Ziel ist nicht, alles zu scoren und zu ranken. Es ist, die ein oder zwei Dimensionen zu identifizieren, wo der Druck am höchsten und Handeln am dringlichsten ist.
Dimension 1: Systemkomplexität und technische Schulden
Worauf Sie achten sollten:
Wie viel der Systemlogik ist dokumentiert versus implizit? Wie viele Abhängigkeiten bestehen zwischen Modulen? Wie fragil ist die Deployment-Kette? Kann ein neuer Entwickler das System in einer vertretbaren Einarbeitungszeit verstehen, oder dauert es sechs Monate, bis jemand produktiv ist?
Warnsignale:
- Business-Logik lebt in Stored Procedures, Triggern oder Batch-Skripten, die kein aktuelles Teammitglied geschrieben hat
- Das System hat keine automatisierte Testabdeckung, oder Tests existieren, aber niemand vertraut ihnen
- Deployment erfordert manuelle Schritte, bestimmte Reihenfolgen oder Koordination über mehrere Teams
- „An dieses Modul fasst niemand ran" ist ein regelmäßig verwendeter Satz in Teamgesprächen
- Das Architekturdiagramm, falls eines existiert, wurde seit Jahren nicht aktualisiert
Schweregrad-Indikatoren:
Niedrig: Das System ist komplex, aber verstanden. Dokumentation existiert. Änderungen sind mit vertretbarem Aufwand möglich.
Mittel: Zentrale Teile des Systems werden von wenigen Personen verstanden. Änderungen erfordern erhebliche Planung. Manche Bereiche werden gemieden, weil das Risiko unbeabsichtigter Auswirkungen zu hoch ist.
Hoch: Das System ist eine Blackbox für das aktuelle Team. Änderungen werden mit Angst vorgenommen. Jedes Deployment ist ein Risiko-Event. Wissen ist auf ein oder zwei Personen konzentriert.
Dimension 2: Operative Engpässe und manuelle Workarounds
Worauf Sie achten sollten:
Wo warten Teams auf das System? Wo arbeiten sie drumherum? Wie viele Prozesse existieren rein dazu, etwas zu kompensieren, das das System tun sollte, aber nicht tut? Wie viel Zeit wird für Datenkorrekturen, manuelle Abstimmungen oder „den Freitagsexport" aufgewendet?
Warnsignale:
- Teams pflegen parallele Spreadsheets, weil die Systemdaten unzuverlässig oder unzugänglich sind
- Prozesse, die Minuten dauern sollten, dauern Stunden wegen Systemeinschränkungen
- Bestimmte Teammitglieder werden für bestimmte Aufgaben benötigt, weil nur sie den Workaround kennen
- Fehlerkorrektur ist ein routinemäßiger Bestandteil des Workflows statt eine Ausnahme
- Monats- oder Quartalsende erzeugt vorhersehbare Krisenpunkte
Schweregrad-Indikatoren:
Niedrig: Workarounds existieren, sind aber gering. Sie erzeugen Reibung, blockieren aber keine Wertschöpfung.
Mittel: Workarounds verbrauchen erhebliche Kapazität. Teams haben Ineffizienz normalisiert. Der Aufwand mehrerer FTEs fließt in die Kompensation von Systemeinschränkungen.
Hoch: Die Workarounds sind der Prozess. Ohne sie würde die Geschäftsfunktion nicht operieren. Das System läuft nominell, aber die eigentliche Arbeit passiert außerhalb.
Ein DACH-Versicherungsunternehmen, das wir bewertet haben, hatte 14 FTEs über drei Abteilungen, deren Hauptaufgabe darin bestand, Lücken zwischen zwei Systemen zu überbrücken, die keine zuverlässige Datenverbindung hatten. Das ist kein Personalproblem. Das ist ein Modernisierungssignal.
Dimension 3: Delivery-Friction und Change-Constraints
Worauf Sie achten sollten:
Wie lange dauert es, eine Änderung von der Idee bis in Produktion zu bringen? Welcher Anteil dieser Zeit ist tatsächliche Entwicklungsarbeit versus Deployment, Testing, Freigabe und Koordinations-Overhead? Wie viele Änderungen werden aufgeschoben, weil der Aufwand für das Deployment den gelieferten Wert übersteigt?
Warnsignale:
- Einfache Änderungen brauchen Wochen oder Monate bis zur Produktion
- Deployment-Fenster sind auf bestimmte Zeiten beschränkt, oft abends oder am Wochenende
- Testing ist manuell, langsam und unzuverlässig
- Das Backlog enthält Items, die seit Jahren aufgeschoben werden, weil das System sie nicht leicht aufnehmen kann
- Feature-Entwicklung hat faktisch aufgehört; der gesamte Engineering-Aufwand fließt in die Wartung
Schweregrad-Indikatoren:
Niedrig: Änderungen werden in Tagen bis Wochen ausgeliefert. Der Prozess ist etwas langsam, aber funktional.
Mittel: Änderungen werden in Wochen bis Monaten ausgeliefert. Die Delivery-Geschwindigkeit ist materiell niedriger als sie sein sollte. Das Team kennt die Reibung, hat sie aber als normal akzeptiert.
Hoch: Das System ist faktisch eingefroren. Änderungen werden vermieden, weil Risiko und Aufwand zu hoch sind. Die Organisation routet um das System herum statt hindurch.
Dimension 4: Integrations- und Datenabhängigkeiten
Worauf Sie achten sollten:
Wie verbindet sich dieses System mit anderen Systemen? Wie viele dieser Verbindungen sind Punkt-zu-Punkt versus über eine Integrationsschicht vermittelt? Was passiert, wenn sich ein System ändert? Wie weit propagiert der Impact? Wie zugänglich sind die Daten für nachgelagerte Konsumenten wie Reporting, Analytics oder KI-Workflows?
Warnsignale:
- Integrationen nutzen geteilte Datenbanken, File-Drops oder FTP statt APIs oder Event-Streams
- Niemand hat ein vollständiges Bild aller Systeme, die von diesem abhängen
- Eine Änderung in einem System bricht regelmäßig ein anderes
- Datenextraktion erfordert Custom-Skripte oder manuelle Eingriffe
- Echtzeit-Datenzugriff ist unmöglich; alles läuft über Batch-Schedules
Schweregrad-Indikatoren:
Niedrig: Integrationen existieren und funktionieren größtenteils. Manche sind fragil, aber handhabbar.
Mittel: Mehrere kritische Integrationen sind fragil, undokumentiert oder werden von einer einzelnen Person betreut. Änderungen an einem System erzeugen Kaskadenprobleme.
Hoch: Das System ist ein Hub in einem Abhängigkeitsnetz. Es anzufassen betrifft mehrere nachgelagerte Systeme. Integrationsfehler sind regelmäßig und verbrauchen erheblichen operativen Aufwand.
Diese Dimension ist besonders wichtig für die KI-Readiness. KI-Workflows brauchen zuverlässigen, zeitnahen Datenzugriff. Wenn das Legacy-System das nicht bieten kann, brauchen Sie eine Stabilisierungs- oder Entkopplungsintervention, bevor der KI-Workflow laufen kann.
Dimension 5: Support-Last und Wartungsdruck
Worauf Sie achten sollten:
Wie viel der Teamkapazität fließt in den laufenden Systembetrieb versus Verbesserungen? Was ist der Trend? Ist die Support-Last stabil, steigend oder sinkend? Was passiert bei einem Systemausfall? Wie lange dauert die Wiederherstellung?
Warnsignale:
- Mehr als 40 % der Engineering-Kapazität fließt in Wartung und Incident-Response
- Incident-Häufigkeit steigt im Zeitverlauf
- Wiederherstellung nach Ausfällen erfordert Spezialwissen, das wenige besitzen
- Das System erfordert regelmäßige „Pflege", die in der Planung nicht sichtbar ist, aber reale Kapazität verbraucht
- Herstellersupport ist ausgelaufen oder läuft aus
Schweregrad-Indikatoren:
Niedrig: Die Support-Last ist handhabbar und stabil. Das Team verbringt die meiste Zeit mit wertschöpfender Arbeit.
Mittel: Die Support-Last ist erheblich und wachsend. Das Team verbringt mehr Zeit mit Wartung als geplant. Wertschöpfende Arbeit wird verdrängt.
Hoch: Support ist die Haupttätigkeit. Das Team ist im reaktiven Modus. Es gibt keine Kapazität für Verbesserungen, und der Trend verschlechtert sich.
Ein Industrieunternehmen in Süddeutschland hatte ein Legacy-MES-System, bei dem drei von fünf Ingenieuren über 60 % ihrer Zeit mit System-Incidents und manuellen Datenkorrekturen verbrachten. Die verbleibenden 40 % gingen dafür drauf, das Backlog nicht wachsen zu lassen. Netto neu geschaffener Wert: faktisch null.
Dimension 6: Modernisierungs-Blocker, Risiken und Chancenbereiche
Worauf Sie achten sollten:
Warum hat Modernisierung bisher nicht stattgefunden? Was hat die Organisation am Handeln gehindert? Ist es das Budget? Risiko von Wissensverlust? Unklare Zielarchitektur? Politische Besitzverhältnisse? Angst vor Disruption? Den Blocker zu verstehen ist genauso wichtig wie die technischen Schulden zu verstehen.
Warnsignale:
- Modernisierung wurde mehrfach vorgeschlagen und abgelehnt
- Das Budget für Modernisierung ist immer „nächstes Jahr"
- Wichtige Stakeholder profitieren vom aktuellen System und widersetzen sich Veränderung
- Die Organisation weiß nicht, wohin sie migrieren würde
- Frühere Modernisierungsversuche sind gescheitert und haben organisatorisches Narbengewebe hinterlassen
Chancenbereiche zur Identifikation:
- Schnelle Erfolge: Komponenten, die mit minimalem Risiko stabilisiert oder entkoppelt werden können
- Strategischer Wert: Bereiche, wo Modernisierung direkt hochwertige KI- oder Automatisierungs-Workflows ermöglicht
- Wissensbewahrung: Dokumentation und Architektur-Recovery, bevor Schlüsselpersonen das Unternehmen verlassen
- KI-Shift-Opportunities: Bereiche, wo jetzt Wert schaffen und später migrieren die bessere Option sein könnte
Was der Readiness Check liefert
Das Ergebnis eines Readiness Checks ist keine Migrations-Roadmap. Es ist eine Diagnose:
Eine Severity Map über alle sechs Dimensionen. Sie 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.
Reibungspunkte mit Business-Impact. Nicht nur „dieses System ist alt", sondern „dieses System kostet uns X Stunden pro Monat an manuellen Workarounds und blockiert Y an potenziellem Umsatz durch KI-Workflows."
Wo Modernisierung Hebelwirkung erzeugt. Nicht alles muss modernisiert werden. Der Readiness Check identifiziert die spezifischen Komponenten, bei denen eine Intervention den meisten Wert freisetzt. Oft ist das eine Stabilisierungs- oder Entkopplungsintervention statt einer Full-Migration.
Ein empfohlener erster Schritt. Keine Zwölf-Monats-Roadmap. Eine spezifische Intervention, gescopt in Wochen, 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. Er umfasst keine Vendor-Auswahl, Plattformbewertung oder Migrationsplanung. Das sind nachgelagerte Aktivitäten, die den Readiness Check als Input benötigen.
Er ist auch kein Urteil über die Menschen, die das Legacy-System gebaut oder betreuen. Legacy-Systeme sind das Ergebnis rationaler Entscheidungen unter früheren Rahmenbedingungen. Der Readiness Check bewertet die aktuelle Situation, nicht die Geschichte.
Wie Sie die Ergebnisse nutzen
Der Readiness Check erzeugt drei mögliche Outputs:
Kein sofortiger Handlungsbedarf. Das System hat Legacy-Eigenschaften, aber der Schweregrad ist über alle Dimensionen niedrig. Beobachten, nicht modernisieren. In 12 Monaten neu bewerten.
Gezielte Intervention. Ein oder zwei Dimensionen zeigen hohen Schweregrad. Gezielt adressieren: Integrationsschicht stabilisieren, Datenpipeline entkoppeln oder die spezifische Komponente modernisieren, die Wertschöpfung blockiert. Das ist Wochen bis Monate an Arbeit, nicht Jahre.
Migrations-Trigger. Drei oder mehr Dimensionen zeigen hohen Schweregrad, und der Trend verschlechtert sich. Dieses System braucht einen Migrationsplan. Der Readiness Check liefert die Daten, um diesen Case 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 echte Blocker nicht das war, was erwartet wurde.
Ein Readiness Check dauert Tage, nicht Monate. Die Kosten der Durchführung sind trivial im Vergleich zu den Kosten eines falsch gescopteten Modernisierungsprogramms. Und der Wert liegt im Fokus: genau zu wissen, wo man anfängt, warum und welches Ergebnis man erwarten kann.
Nächster Schritt
Wenn Legacy-Systeme in Ihrer Organisation Reibung erzeugen und Sie eine strukturierte Sicht auf die Druckpunkte wollen, starten Sie mit einem Readiness Check. Wenn Sie bereits ein klares Bild haben und Interventionsoptionen besprechen möchten, vereinbaren Sie ein Erstgespräch und bringen Sie Ihre Erkenntnisse mit.
Dieser Artikel ist Teil der Serie Legacy-Modernisierung für KI von Andreas Anding. Zur Frage des Migrationstimings siehe Die KI-Shift-Migrationsstrategie.