End-of-Life klingt nach dem Ende. Ist es aber nicht unbedingt.
Magento 1, xt:Commerce oder eine alte Eigenentwicklung: In vielen Unternehmen laufen Softwarelösungen seit Jahren zuverlässig. Sie bilden wichtige Geschäftsprozesse ab, sind individuell angepasst und funktionieren im Alltag. Irgendwann kommt jedoch der Zeitpunkt, an dem der Hersteller die Weiterentwicklung einer Software oder einer bestimmten Version einstellt. Die Software ist dann End-of-Life, kurz EOL.
Das bedeutet nicht automatisch, dass sie ab diesem Tag nicht mehr funktioniert. Ein System kann technisch noch viele Jahre weiterlaufen. Die entscheidende Veränderung ist eine andere: Die Verantwortung verschiebt sich vom Hersteller zum Betreiber.
Es gibt keine regulären Sicherheitsupdates mehr, Fehler werden nicht mehr behoben und Anpassungen an neue Technologien, Betriebssysteme, Datenbanken, Browser oder Schnittstellen bleiben aus. Auch rechtliche oder regulatorische Anforderungen werden vom Hersteller nicht mehr berücksichtigt. Aus einer funktionierenden Software kann so schleichend ein technisches und wirtschaftliches Risiko werden.
Das sind wichtige Fragen. Über den Erfolg eines ERP-Projekts entscheiden sie jedoch nur selten. Denn ein ERP-System zu kaufen, ist vergleichsweise einfach. Es erfolgreich einzuführen, ist die eigentliche Herausforderung.
Der Grund: Ein ERP-Projekt ist kein reines IT-Projekt. Es ist vor allem ein Veränderungsprojekt, das Prozesse, Daten und den Arbeitsalltag der Mitarbeitenden betrifft.
End-of-Life betrifft mehr als die Software selbst
Wenn eine Anwendung offiziell noch unterstützt wird, bedeutet das nicht automatisch, dass auch alle Bestandteile ihres technischen Umfelds aktuell sind. Ein System kann beispielsweise auf einer veralteten PHP-Version laufen, eine nicht mehr unterstützte Datenbank verwenden oder von einem Plugin abhängen, dessen Entwicklung längst eingestellt wurde.
Auch externe Schnittstellen können zum Problem werden: Zahlungsanbieter ändern ihre APIs, Versanddienstleister stellen alte Schnittstellen ein oder ein Betriebssystem erreicht sein Supportende. Deshalb sollte bei EOL nicht nur auf den Namen und die Version der eigentlichen Software geschaut werden, denn entscheidend ist der gesamte Technologie-Stack. Dazu gehören unter anderem:
- Softwareversion
- Programmiersprache und Laufzeitumgebung
- Datenbank
- Webserver und Betriebssystem
- Libraries und Frameworks
- Plugins und Extensions
- Themes
- Eigenentwicklungen
- APIs und Schnittstellen
- ERP- oder Warenwirtschaftsanbindungen
- Zahlungs- und Versanddienstleister
Erst wenn diese Abhängigkeiten bekannt sind, lässt sich beurteilen, wie kritisch der aktuelle Zustand tatsächlich ist.
Nicht sofort migrieren, sondern zuerst das Risiko verstehen
Wenn eine Software End-of-Life erreicht, lautet die erste Frage häufig: „Auf welches System migrieren wir?“.
Aus unserer Sicht ist das nicht die erste Frage. Denn zunächst sollte geklärt werden, was heute überhaupt vorhanden ist und welche Risiken daraus entstehen. Dafür erstellen wir eine technische Bestandsaufnahme. Welche Versionen werden eingesetzt? Welche Komponenten sind noch gepflegt? Wo gibt es Sicherheitslücken? Welche Abhängigkeiten lassen sich noch aktualisieren? Ist der Quellcode verfügbar? Welche Eigenentwicklungen sind im System enthalten?
So entsteht Schritt für Schritt ein Bild der gesamten Systemlandschaft. Besonders wichtig ist dabei die Frage, was bei einer Änderung einzelner Komponenten passiert. Ein Upgrade der PHP-Version kann beispielsweise Auswirkungen auf Extensions oder Eigenentwicklungen haben. Eine neue Datenbankversion kann wiederum Anpassungen an der Anwendung erfordern. EOL ist deshalb kein einzelnes Problem, sondern häufig ein ganzes Geflecht aus Abhängigkeiten.
Technisches Risiko ist nicht gleich wirtschaftliches Risiko
Eine technisch veraltete Software ist nicht automatisch wirtschaftlich wertlos. Vielleicht läuft das System stabil, verändert sich kaum noch und bildet einen Geschäftsprozess ab, der seit Jahren zuverlässig funktioniert. Eine vollständige Migration könnte in diesem Fall sehr teuer und riskant sein, obwohl die Software technisch nicht mehr auf dem neuesten Stand ist. Umgekehrt kann ein scheinbar kleines Altsystem geschäftskritisch sein.
Deshalb sollten neben der Technik auch wirtschaftliche Fragen betrachtet werden:
- Welchen Geschäftsprozess bildet das System ab?
- Wie viel Umsatz hängt davon ab?
- Wie viele Mitarbeitende arbeiten damit?
- Wie viele Kunden nutzen die Anwendung?
- Welche Funktionen sind geschäftskritisch?
- Welche Funktionen werden tatsächlich noch genutzt?
- Was würde eine Stunde, ein Tag oder eine Woche Ausfall kosten?
Erst aus der Kombination von technischem und wirtschaftlichem Risiko entsteht eine belastbare Entscheidungsgrundlage.
Welche Möglichkeiten gibt es?
Eine EOL-Software muss nicht zwangsläufig sofort ersetzt werden. Je nach Situation können unterschiedliche Strategien sinnvoll sein. Wir haben in der Praxis bereits verschiedene dieser Wege begleitet, vom kontrollierten Weiterbetrieb über die Modernisierung bis hin zur Migration auf ein neues System. Die konkreten Erfahrungen daraus möchten wir künftig in einer kleinen Case-Study-Reihe vorstellen.
1. Das bestehende System kontrolliert weiterbetreiben
Wenn das System stabil läuft, die Anforderungen kaum verändert werden und die Sicherheitsrisiken beherrschbar sind, kann ein kontrollierter Weiterbetrieb durchaus sinnvoll sein. Voraussetzung ist, dass der technische Stack noch betrieben werden kann, der Quellcode verfügbar ist und eine Ablösung aktuell wirtschaftlich nicht sinnvoll wäre.
Wichtig ist dabei, die Entscheidung bewusst zu treffen und eine überschaubare Restlaufzeit festzulegen, statt die Ablösung immer weiter aufzuschieben.
2. Das bestehende System selbst weiterpflegen
Auch nach dem Supportende kann ein System weiterbetrieben werden, wenn jemand die Verantwortung für seine technische Pflege übernimmt.
Dazu gehört beispielsweise, Sicherheitslücken zu beobachten, Patches zu analysieren, die Kompatibilität mit der Infrastruktur zu erhalten und notwendige Anpassungen selbst vorzunehmen. Damit übernimmt ein Dienstleister gewissermaßen einen Teil der Rolle, die zuvor beim Hersteller lag.
Das kann eine sinnvolle Übergangslösung sein, wenn eine sofortige Migration nicht möglich oder wirtschaftlich nicht sinnvoll ist.
3. Das bestehende System schrittweise modernisieren
Nicht jede Modernisierung muss mit einem vollständigen Neustart beginnen. Je nach Architektur können einzelne Bestandteile schrittweise aktualisiert oder ersetzt werden:
- PHP-Version aktualisieren
- Datenbank modernisieren
- alte Libraries ersetzen
- einzelne Komponenten herauslösen
- APIs ergänzen oder erneuern
- Frontend ersetzen
- Authentifizierung modernisieren
- externe Dienste auslagern
- Infrastruktur aktualisieren
Ein typisches Beispiel ist eine alte Anwendung, die auf einer nicht mehr unterstützten Laufzeitumgebung basiert. Statt das gesamte System sofort neu zu entwickeln, kann zunächst die technische Umgebung modernisiert werden.
In manchen Fällen lässt sich eine Legacy-Anwendung beispielsweise in einer abgeschotteten Container-Umgebung betreiben, während die übrige Infrastruktur modernisiert wird.
4. Auf ein Nachfolgesystem migrieren
Manchmal ist eine Migration die sinnvollste Lösung. Dabei ist ein Wechsel von Magento 1 auf Magento 2 dafür ein bekanntes Beispiel. Hier sollte man jedoch einen wichtigen Unterschied beachten:
Eine Migration ist kein Update.
Ein Nachfolgesystem funktioniert häufig anders als die bisherige Anwendung. Extensions sind möglicherweise nicht mehr verfügbar, individuelle Funktionen müssen neu entwickelt werden und Schnittstellen müssen angepasst oder komplett neu implementiert werden.
Deshalb sollte eine Migration nicht das Ziel haben, jeden einzelnen historischen Prozess exakt nachzubauen. Viel wichtiger ist die Frage:
Welche Funktionen werden heute tatsächlich benötigt?
Denn ein System, das über viele Jahre gewachsen ist, enthält häufig Funktionen, die inzwischen niemand mehr nutzt oder die längst durch andere Prozesse ersetzt wurden. Eine gute Migration übernimmt deshalb nicht zwangsläufig alles, sondern das, was heute wirklich gebraucht wird.
5. Funktionen in andere Systeme übernehmen
Manchmal muss auch gar kein neues Gesamtsystem entstehen. Vielleicht können einzelne Funktionen in eine bereits vorhandene ERP-, CRM- oder andere Unternehmenssoftware integriert werden.
Aus einem alten System werden dann beispielsweise nur die wirklich benötigten Prozesse übernommen und sinnvoll auf bestehende Anwendungen verteilt.
Auch die vollständige Abschaltung kann eine Option sein, wenn bestimmte Funktionen heute nicht mehr benötigt werden
Sicherheit: EOL wird spätestens hier relevant
Ein nicht mehr gepflegtes System wird besonders dann kritisch, wenn es Sicherheitslücken gibt, die nicht mehr durch den Hersteller geschlossen werden.
Das BSI empfiehlt Unternehmen, einen Überblick über die eingesetzte Hard- und Software zu behalten und Sicherheitsupdates möglichst zeitnah einzuspielen. Informationssicherheit soll dabei als Teil des Risikomanagements verstanden werden.
Bei einer EOL-Anwendung bedeutet das: Sicherheitsmaßnahmen müssen stärker selbst organisiert werden. Dazu können beispielsweise gehören:
- Monitoring von bekannten Schwachstellen und CVEs
- Dependency-Scanning
- regelmäßige Schwachstellenscans
- Log-Monitoring
- Firewall und Netzwerksegmentierung
- sichere Backups und regelmäßige Wiederherstellungstests
Das Ziel ist nicht, ein EOL-System künstlich für immer am Leben zu halten. Es geht darum, das Risiko so lange kontrollierbar zu halten, bis eine nachhaltige Lösung umgesetzt werden kann.
Darf eine EOL-Software überhaupt weiterbetrieben werden?
Neben technischen und wirtschaftlichen Fragen sollte auch geprüft werden, ob der Weiterbetrieb rechtlich und vertraglich vertretbar ist. Je nach Branche und Geschäftsmodell können unterschiedliche Anforderungen relevant sein:
- gesetzliche Vorgaben
- branchenspezifische Anforderungen
- Compliance-Vorgaben
- Versicherungsbedingungen
- Verträge mit Kunden
- Vereinbarungen mit Zahlungs- oder anderen Dienstleistern
- Service Level Agreements
Eine technisch funktionierende Software kann also trotzdem zum Problem werden, wenn ihr Betrieb bestimmte Anforderungen nicht mehr erfüllt.
Hierbei lohnt es sich frühzeitig zu prüfen und nicht erst dann zu beginnen, wenn eine Zertifizierung, ein Audit oder ein Vertragspartner konkrete Nachweise verlangt.
Nicht nur die Software migrieren, sondern auch die Daten
Bei einer Ablösung wird häufig zuerst über Funktionen und Technik gesprochen, dabei sind die Daten mindestens genauso wichtig. Welche historischen Daten werden tatsächlich noch benötigt? Welche müssen übernommen werden? Welche können archiviert werden? Welche Daten können überhaupt sinnvoll in das neue System übertragen werden?
Das kann den Aufwand einer Migration erheblich beeinflussen. Wer beispielsweise zehn Jahre historische Daten vollständig in ein neues System übernehmen möchte, benötigt deutlich mehr Zeit und Aufwand als ein Unternehmen, das nur aktuelle Daten migriert und ältere Informationen separat archiviert.
Datenmigration sollte deshalb frühzeitig Teil der Entscheidungsfindung sein und erst kurz vor dem Go-live.
Eine Migration braucht einen Plan
Wenn die Entscheidung für eine Ablösung gefallen ist, sollte das alte System nicht einfach abgeschaltet werden. In der Regel ist es sinnvoll, das neue System zunächst parallel aufzubauen und zu testen. Dabei müssen unter anderem Datenübernahme, Schnittstellen, Benutzerrechte und die tatsächlichen Geschäftsprozesse geprüft werden. Erst wenn die wichtigsten Abläufe zuverlässig funktionieren, erfolgt die Umstellung.
Je nach Situation kann dabei ein harter Übergang sinnvoll sein, bei dem zu einem definierten Zeitpunkt vollständig auf das neue System gewechselt wird. In anderen Fällen bietet sich ein schrittweiser Übergang an, bei dem einzelne Funktionen oder Nutzergruppen nach und nach umgestellt werden. Welche Variante sinnvoll ist, hängt vom System, den Geschäftsprozessen und dem damit verbundenen Risiko ab.
Fazit
End-of-Life bedeutet nicht automatisch, dass eine Software sofort abgeschaltet werden muss. Es bedeutet aber, dass man sich nicht mehr darauf verlassen kann, dass der Hersteller technische, sicherheitsrelevante oder regulatorische Entwicklungen für das System übernimmt.
Deshalb sollte die erste Reaktion auf EOL nicht sein: „Wir brauchen eine neue Software.“, sondern: „Wir müssen verstehen, welches Risiko wir tatsächlich haben.“.
Eine technische Bestandsaufnahme, die Betrachtung des gesamten Technologie-Stacks und eine wirtschaftliche Bewertung schaffen die Grundlage für die richtige Entscheidung.
Vielleicht ist ein kontrollierter Weiterbetrieb sinnvoll. Vielleicht kann das bestehende System modernisiert werden. Vielleicht übernimmt ein Dienstleister die technische Pflege. Oder eine Migration ist langfristig die beste Lösung.
Die richtige Strategie ist nicht die, die am schnellsten zu einer neuen Software führt. Sondern die, die technische Risiken, wirtschaftliche Anforderungen und den tatsächlichen Nutzen für das Unternehmen sinnvoll zusammenbringt.