Legacy ist eine Risikolage, kein Baujahr
Eine ältere Anwendung kann über Jahre zuverlässig arbeiten und ihren Zweck gut erfüllen. Gleichzeitig kann ein junges System bereits schwer wartbar sein, wenn Quellstand, Tests, Deployment und Zuständigkeiten unklar sind. Der Begriff Legacy beschreibt deshalb weniger das Alter als die Kosten und Risiken von Veränderungen.
Typische Signale sind eine nicht mehr unterstützte Laufzeit, blockierte Abhängigkeiten, versteckte Geschäftslogik, manuelle Serveränderungen, fehlende Tests und einzelne Personen als einzige Wissensquelle. Diese Faktoren verstärken sich gegenseitig: Weil Änderungen riskant sind, werden Updates verschoben; weil Updates fehlen, wird jeder spätere Schritt größer.
Modernisierung soll diese Spirale unterbrechen. Sie ist erfolgreich, wenn das System wieder sicherer änderbar, beobachtbar und betreibbar wird – nicht erst, wenn jede Datei neu geschrieben wurde.
Warum der Big Bang attraktiv wirkt
Ein kompletter Neuaufbau verspricht eine saubere Architektur ohne Altlasten. In einer Präsentation ist das überzeugend: neue Technologie, klare Module und ein definierter Starttermin. In der Praxis liegt die größte Unsicherheit jedoch selten nur im Code. Sie liegt in den über Jahre entstandenen Regeln, Daten und Ausnahmen.
Wird alles gleichzeitig ersetzt, müssen diese Regeln vollständig erkannt, neu implementiert, migriert und zu einem festen Termin umgeschaltet werden. Das alte System verändert sich währenddessen häufig weiter. So entstehen zwei konkurrierende Wahrheiten, eine wachsende Migrationslücke und hoher Druck kurz vor dem Go-live.
Ein Big Bang kann trotzdem richtig sein. Er sollte aber das Ergebnis einer bewussten Bewertung sein, nicht die Reaktion auf unübersichtlichen Code. Ohne vorherige Bestandsaufnahme wird Unklarheit nur in ein größeres Projekt verschoben.
Modernisierung beginnt mit Schutzgeländern
Bevor Strukturen verändert werden, braucht das Projekt Möglichkeiten, Fehler zu erkennen und Änderungen zurückzunehmen. Dazu gehören aktuelle Backups mit bekanntem Restore-Weg, ein nachvollziehbarer Quellstand, getrennte Konfiguration, geeignete Testdaten, aussagekräftige Logs und ein kontrolliertes Deployment.
Diese Schutzgeländer müssen zum Risiko passen. Eine betriebliche Auswertungsseite benötigt andere Maßnahmen als ein Checkout, der Zahlungen und Bestellungen verarbeitet. Entscheidend ist, die kritischen Geschäftswege zu identifizieren und dort zuerst Beobachtbarkeit und Prüfungen aufzubauen.
Ein pragmatisches Mindestset
- Produktiven Stand im Repository nachvollziehbar machen
- Konfiguration und Geheimnisse vom Code trennen
- Datenbank- und Dateibackups samt Wiederherstellung klären
- Fehlerprotokolle zentral auffindbar machen
- Kritische fachliche Prüffälle dokumentieren
- Deployment und Rückfallweg festlegen
Das System in veränderbare Bereiche teilen
Große Legacy-Anwendungen wirken oft wie ein Block. Tatsächlich lassen sich Verantwortlichkeiten und Datenflüsse schrittweise sichtbar machen: Benutzerverwaltung, Produktimport, Reporting, E-Mail-Versand, Zahlungsabgleich oder Administrationsoberfläche. Nicht jeder Bereich muss sofort technisch getrennt werden. Schon eine klare fachliche Grenze hilft, Änderungen einzugrenzen.
An einer solchen Grenze können Eingaben, Ausgaben und Fehlerfälle dokumentiert werden. Tests schützen das beobachtete Verhalten. Neue Logik wird möglichst außerhalb des riskanten Kerns aufgebaut und über eine definierte Schnittstelle angebunden. Dieses Vorgehen wird oft als Strangler-Muster beschrieben: Neue Teile übernehmen schrittweise Funktionen, während der alte Kern kontrolliert kleiner wird.
Die Grenze darf nicht nur auf dem Architekturdiagramm existieren. Datenhoheit, Transaktionen und Betrieb müssen ebenfalls klar sein. Wenn alter und neuer Teil dasselbe Feld unabhängig verändern, entsteht kein sauberer Übergang, sondern eine neue Konfliktquelle.
Laufzeit und Abhängigkeiten in Etappen aktualisieren
Eine Migration von einer alten PHP-Version auf eine unterstützte Version kann mehrere Arten von Inkompatibilität enthalten: entfernte Sprachfunktionen, veränderte Fehlerbehandlung, nicht kompatible Erweiterungen und Bibliotheken sowie unklare Seiteneffekte im eigenen Code. Je größer der Versionssprung, desto wichtiger sind automatisierte Analyse, Tests und ein stufenweiser Plan.
Zuerst wird erfasst, welche PHP-Version tatsächlich produktiv läuft und welche Erweiterungen benötigt werden. Paketabhängigkeiten und manuell eingebundene Bibliotheken werden getrennt bewertet. Danach lassen sich Kompatibilitätsprobleme in kleinen Paketen beheben. Wenn möglich, werden Zwischenstände in einer nicht produktiven Umgebung ausgeführt und gegen die kritischen Geschäftswege geprüft.
Ein Laufzeitupdate ist kein Selbstzweck. Es reduziert das Risiko aus fehlenden Sicherheitskorrekturen und eröffnet unterstützte Bibliotheksversionen. Gleichzeitig darf „läuft ohne Fatal Error“ nicht mit fachlich korrektem Verhalten verwechselt werden.
Datenbankmodernisierung ohne Datenüberraschung
Datenbanken enthalten oft die langlebigste Wahrheit des Systems. Spalten haben historische Bedeutungen, Statuswerte wurden ergänzt und Korrekturskripte haben Daten verändert. Eine strukturelle Bereinigung muss diese Geschichte berücksichtigen.
Schemaänderungen werden versioniert, mit realistischen Datenmengen getestet und nach Möglichkeit rückwärtskompatibel ausgerollt. Bei größeren Änderungen kann eine Übergangsphase sinnvoll sein: neue Spalte ergänzen, Anwendung auf beide Varianten vorbereiten, Daten nachziehen, Nutzung umstellen und erst später die alte Struktur entfernen.
Performanceoptimierung beginnt mit Messung. Ein Index kann eine Abfrage beschleunigen, aber Schreibkosten erhöhen oder das eigentliche Modellproblem verdecken. Langsame Pfade werden anhand realer Abfragen und Datenmengen untersucht.
Fortschritt nicht an neu geschriebenen Zeilen messen
Modernisierung erzeugt geschäftlichen Wert, wenn Risiken sinken und Änderungen verlässlicher werden. Geeignete Fortschrittssignale sind beispielsweise ein reproduzierbarer Build, ein getesteter Restore, weniger unbekannte Abhängigkeiten, abgedeckte kritische Regeln, eine unterstützte Laufzeit oder ein aus dem Altcode herausgelöster Prozess.
Reine Mengenkennzahlen wie ersetzte Dateien oder Codezeilen können in die falsche Richtung führen. Guter Fortschritt kann auch darin bestehen, einen stabilen Bereich nicht anzufassen und stattdessen seine Schnittstelle zu dokumentieren.
Eine realistische Modernisierungsroadmap
Eine Roadmap ordnet Maßnahmen nach Risiko, Nutzen, Voraussetzung und Prüfbarkeit. Akute Sicherheits- und Betriebsprobleme stehen meist vor Komfortverbesserungen. Beobachtbarkeit und Deployment können Voraussetzung für ein Laufzeitupdate sein; das Laufzeitupdate wiederum Voraussetzung für eine neue Bibliothek.
Jedes Paket sollte ein fachlich verständliches Ergebnis, einen Testweg und eine Auslieferungsstrategie haben. Unbekannte Teile erhalten zunächst Analyseaufgaben statt fiktiver Festschätzungen. So bleibt die Roadmap ein Steuerungswerkzeug und wird nicht zu einer Liste von Wunschdaten.
Beispielhafte Reihenfolge
- Backups, Quellstand und Zugänge absichern
- Logs und kritische Prüffälle ergänzen
- Akute Fehler und exponierte Risiken begrenzen
- Deployment reproduzierbar machen
- Abhängigkeiten inventarisieren und entkoppeln
- PHP-Version und Bibliotheken stufenweise aktualisieren
- Einzelne fachliche Bereiche modernisieren oder ablösen
- Nicht mehr genutzte Pfade nach Prüfung entfernen
Wann der schrittweise Weg an Grenzen stößt
Eine inkrementelle Modernisierung braucht eine noch nutzbare Basis. Wenn das System nicht reproduzierbar betrieben werden kann, zentrale Komponenten rechtlich oder technisch untragbar sind oder jede Änderung unverhältnismäßig viele Seiteneffekte erzeugt, kann ein Ersatz sinnvoller werden.
Auch dann bleibt der schrittweise Gedanke relevant: Datenexporte, fachliche Regeln, Integrationen und Nutzergruppen werden einzeln erschlossen. Ein Parallelbetrieb oder eine gestufte Migration kann den Umstieg absichern. Der Unterschied liegt darin, dass das Zielsystem neu entsteht – nicht darin, dass alle Risiken an einem Tag gelöst werden.