Legacy-Modernisierung in Energiebranche und Industrie: Warum ein Neustart fast nie die richtige Antwort ist

Legacy-Systeme gibt es in jeder Branche. Aber in Energieversorgung, Netzbetrieb und industrieller Fertigung kommen Bedingungen zusammen, die eine Modernisierung besonders anspruchsvoll machen.

Das erste Merkmal ist die Kritikalität. Viele dieser Systeme sind nicht nur betriebsrelevant, sondern im Sinne von NIS2 und dem KRITIS-Dachgesetz regulatorisch eingestuft. Ein Netzkontrollsystem, das ausfällt, ist keine IT-Panne, sondern ein Versorgungsproblem. Ausfallzeiten, die in anderen Branchen tolerierbar wären, sind hier nicht akzeptabel. Das setzt eine strenge Anforderung an jede Migrationsstrategie: Sie muss den laufenden Betrieb sicherstellen, auch während die Modernisierung läuft.

Das zweite Merkmal sind lange Lebenszyklen. Industrieanlagen und Energieinfrastruktur werden für Jahrzehnte geplant. Software wird mitgekauft, als Teil einer Anlage oder eines Steuerungssystems, und läuft dann einfach. Während sich die Anforderungen rundherum ändern, neue Regulierungen kommen, neue Einspeisungstypen integriert werden müssen, neue Schnittstellen zu Marktdatensystemen entstehen, bleibt die Software statisch. Das erzeugt technische Schulden in einem Tempo, das irgendwann unbeherrschbar wird.

Das dritte Merkmal ist die Dokumentationslage. Systeme, die über viele Jahre und von unterschiedlichen Teams weiterentwickelt wurden, sind selten gut dokumentiert. Wissen steckt in den Köpfen von Mitarbeitenden, die inzwischen in Rente sind. Konfigurationen sind in undokumentierten Parametern versteckt. Abhängigkeiten zwischen Systemen sind historisch gewachsen und nirgends vollständig erfasst. Bevor man modernisieren kann, muss man oft erst verstehen, was überhaupt vorhanden ist.

Es gibt keine universell richtige Antwort auf die Frage, wie man ein Legacy-System modernisiert. Die Wahl der Strategie hängt vom System, seinem Risikoprofil, der verfügbaren Ressource und dem Zeithorizont ab. Drei Grundansätze prägen die Praxis.

Beim Replatforming wird der Funktionsumfang des bestehenden Systems im Wesentlichen erhalten, aber auf eine modernere technische Plattform gehoben. Der Anwendungsfall ist klar: Das System funktioniert fachlich gut, aber die zugrundeliegende Infrastruktur ist nicht mehr wartbar, der Technologiestack wird nicht mehr unterstützt oder die Deployment-Umgebung ist zu einem Sicherheitsrisiko geworden. Ein Java-EE-Monolith, der auf einem veralteten Applikationsserver läuft, ist ein typischer Kandidat: Die Geschäftslogik hat ihren Wert behalten, die Plattform darunter nicht. Replatforming ist schneller als eine komplette Neuentwicklung, trägt aber auch die Risiken der Altlast mit: Wenn die bestehende Architektur strukturelle Schwächen hat, werden diese mitgemigriert.

Inkrementelle Modernisierung ist oft die realistischste Option für Systeme, die im laufenden Betrieb bleiben müssen. Anstatt alles auf einmal abzulösen, werden einzelne Module oder Komponenten schrittweise modernisiert, während der Rest des Systems weiterläuft. Das Strangler-Fig-Muster ist hierfür der bekannteste Ansatz: Eine neue Schicht wächst um das Legacy-System herum, übernimmt sukzessive Funktionen und verdrängt das Alte, bis es schließlich vollständig ersetzt ist, ohne jemals offline gehen zu müssen.

Dieser Ansatz erfordert eine saubere Architekturstrategie von Beginn an: klare Schnittstellendefinitionen, eine durchdachte Datenmigrationsstrategie und ein Team, das sowohl das alte als auch das neue System kennt. Das Risiko liegt in der Übergangsphase: Zwei Systeme parallel zu betreiben ist aufwändig und fehleranfällig, wenn die Abstimmung nicht sorgfältig geplant ist.

Die komplette Neuentwicklung auf der grünen Wiese ist die Option, die am meisten Freiheit verspricht, und die die meisten Risiken trägt. In der Praxis scheitern „Big Bang“-Migrationen überproportional häufig, weil das Wissen über das bestehende System unterschätzt wird. Implizite Geschäftslogik, die nirgends dokumentiert ist, aber seit Jahren korrekt ausgeführt wird, taucht erst auf, wenn das neue System sie nicht reproduziert. In regulierten Umgebungen mit laufenden Betriebspflichten kommt hinzu, dass ein Parallelbetrieb über lange Zeiträume besonders kostspielig ist.

Eine Neuentwicklung ist sinnvoll, wenn das bestehende System fachlich und technisch überholt ist, wenn neue regulatorische Anforderungen eine grundlegend andere Architektur erfordern und wenn die Möglichkeit besteht, den Übergang kontrolliert und phasenweise zu gestalten. Sie ist keine Abkürzung, sondern der aufwändigste Weg, der die höchste Entschlossenheit und Ressource erfordert.

Einer der zeitintensivsten Teile jeder Legacy-Modernisierung ist das Verstehen des bestehenden Systems. Code, der über Jahrzehnte gewachsen ist, lässt sich nicht in wenigen Wochen vollständig durchdringen. KI-gestützte Codeanalyse-Werkzeuge können diesen Prozess heute erheblich beschleunigen.

Konkret helfen KI-Tools dabei, Codebases systematisch zu analysieren und implizite Abhängigkeiten sichtbar zu machen, die in keiner Dokumentation auftauchen. Sie können Geschäftslogik in altem COBOL-Code, in gewachsenen Java-Monolithen oder in undokumentierten Stored Procedures extrahieren und in lesbare Dokumentation überführen. Sie können Testsuiten für Legacy-Systeme generieren, die als Sicherheitsnetz dienen, bevor die eigentliche Migration beginnt. Und sie unterstützen bei der Erstellung einer Software Bill of Materials, die nach CRA mittlerweile ohnehin verpflichtend ist.

Bei BAYOOTEC entsteht ein erheblicher Teil des neuen Codes KI-gestützt, und wir nutzen KI-Automatisierungen für Pull-Request-Reviews und Security-Scans. In Modernisierungsprojekten setzen wir KI gezielt für die initiale Analyse und Dokumentation des bestehenden Systems ein, was die Discovery-Phase deutlich verkürzt und die Qualität der Migrationsstrategie erhöht. Damit KI auch in regulierten Umfeldern regelkonform bleibt, haben wir einen internen KI-Compliance-Verantwortlichen mit TÜV-Qualifikation etabliert.

Legacy-Modernisierung war lange ein Thema, das intern von IT-Abteilungen priorisiert, aber von Geschäftsführungen aufgeschoben wurde. Das ändert sich gerade, weil regulatorischer Druck von außen entscheidet, was intern nicht entschieden wurde.

NIS2 verpflichtet betroffene Unternehmen zu nachweisbarem Risikomanagement und Auditierbarkeit ihrer IT-Systeme. Ein Legacy-System, das keine ordentlichen Logging-Mechanismen hat, das nicht dokumentiert ist und das keine kontrollierten Update-Prozesse kennt, erfüllt diese Anforderungen strukturell nicht. Es ist kein schlechtes System geworden, es war nie für diese Anforderungen gebaut worden. Aber das ist für den Gesetzgeber kein Unterschied.

Der Cyber Resilience Act, der ab Dezember 2027 vollumfänglich gilt, schreibt für alle Produkte mit digitalen Elementen eine Software Bill of Materials, aktives Schwachstellenmanagement und sichere Update-Mechanismen vor. Für Hersteller industrieller Software bedeutet das: Systeme, die diese Anforderungen nicht erfüllen, dürfen ab diesem Zeitpunkt in der EU nicht mehr in Verkehr gebracht werden. Auch für Betreiber verschärft sich die Situation, denn sie müssen die Konformität ihrer Lieferkette nachweisen.

Und im Energiesektor konkret: Redispatch 3.0 wird neue Anforderungen an Kommunikation und Datenverarbeitung zwischen Netzbetreibern und Einspeisern stellen, für die viele bestehende Systeme technisch nicht ausgelegt sind. Wer bereits modernisiert hat, kann diese Anforderungen modular integrieren. Wer noch auf Legacy läuft, steht vor einem Projekt unter Zeitdruck.

BAYOOTEC modernisiert Legacy-Systeme seit über 20 Jahren, und zwar nicht als generisches IT-Projekt, sondern mit dem Branchenverständnis, das in regulierten Umgebungen den Unterschied macht. Einige unserer Entwicklerinnen und Architekten bringen akademische und praktische Expertise aus der Energiewirtschaft mit: Das Wissen, was Redispatch bedeutet, wie Bilanzkreise funktionieren und welche Anforderungen NIS2 an die Auditierbarkeit stellt, ist bei uns keine Einarbeitungszeit, sondern Ausgangspunkt.

Unser Ansatz bei Legacy-Projekten beginnt nicht mit dem Code, sondern mit dem Verstehen. Eine strukturierte Discovery-Phase, die mit modernen Analyse-Werkzeugen und KI-gestützter Codeanalyse den tatsächlichen Zustand des Systems erfasst, ist die Grundlage für jede belastbare Modernisierungsstrategie. Auf dieser Basis entscheiden wir gemeinsam mit unseren Kunden, ob Replatforming, inkrementelle Modernisierung oder ein schrittweiser Neubau der richtige Weg ist, und planen die Migration so, dass der laufende Betrieb zu keinem Zeitpunkt gefährdet wird.

Alle Projekte, die wir begonnen haben, haben wir erfolgreich in den produktiven Betrieb überführt. Das ist in einem Feld, in dem Projekte überproportional häufig zu spät, zu teuer oder unvollständig enden, kein selbstverständliches Versprechen. Es ist das Ergebnis einer Arbeitsweise, die technische Qualität, Branchenverständnis und eine ehrliche Projektkommunikation konsequent verbindet.

Wenn Du wissen möchtest, welche Modernisierungsstrategie für Dein System sinnvoll ist, starten wir gerne mit einer kompakten Discovery-Phase, die den Ist-Zustand erfasst, Risiken bewertet und einen konkreten Fahrplan entwickelt. Nimm gerne Kontakt auf.