Legacy ist kein Synonym für wertlos
Bestehende Systeme enthalten oft Jahre an Fachwissen. Sie bilden Sonderfälle ab, die in keiner Dokumentation stehen, und unterstützen Prozesse, von denen das Unternehmen täglich abhängt. Genau deshalb ist eine Modernisierung anspruchsvoll: Die technische Qualität kann problematisch sein, während der fachliche Wert sehr hoch ist.
Eine vollständige Neuentwicklung wirkt attraktiv, weil sie einen sauberen Neustart verspricht. In der Praxis müssen jedoch alle Regeln, Daten und Integrationen gleichzeitig verstanden und ersetzt werden. Das Risiko steigt, je tiefer das System im Betrieb verankert ist.
Das Ziel einer Modernisierung ist nicht neuer Code. Das Ziel ist ein System, das sich wieder sicher verändern lässt.
PMMB Engineering
Zuerst die gewünschten Ergebnisse klären
Bevor Technologien gewählt werden, müssen die konkreten Probleme benannt werden. Ist die Auslieferung zu langsam? Fehlen Tests? Sind Betriebskosten zu hoch? Können neue Kanäle nicht angebunden werden? Ohne messbares Ziel wird Modernisierung zu einem offenen Umbauprojekt.
- Durchlaufzeit für Änderungen verkürzen.
- Ausfallrisiko kritischer Prozesse reduzieren.
- Veraltete Laufzeiten und Abhängigkeiten ablösen.
- Daten und Schnittstellen für neue Produkte nutzbar machen.
- Betrieb und Fehlersuche transparenter gestalten.
Das System kartieren
Eine belastbare Planung benötigt eine technische und fachliche Landkarte. Dazu gehören Module, Datenbanken, Batch-Prozesse, Schnittstellen, Nutzergruppen und bekannte Betriebsprobleme. Besonders wichtig sind implizite Kopplungen: Dateien, gemeinsam genutzte Tabellen oder manuelle Abläufe, die offiziell nicht Teil des Systems sind.
Logs, Datenbankzugriffe und Netzwerkverkehr können helfen, reale Nutzung von vermuteter Nutzung zu unterscheiden. Funktionen, die niemand mehr verwendet, sollten nicht automatisch migriert werden.
Schrittweise ersetzen statt Big Bang
Der Strangler-Ansatz modernisiert ein System schrittweise. Neue oder geänderte Funktionen werden außerhalb des alten Kerns aufgebaut. Eine Routing- oder Integrationsschicht entscheidet, welcher Teil eine Anfrage verarbeitet. Mit jeder Iteration wandert mehr Verhalten in die neue Struktur.
Dieser Ansatz erzeugt vorübergehend zusätzliche Komponenten. Das ist kein Fehler, sondern der Preis für kontrollierbares Risiko. Wichtig ist, Übergangslösungen bewusst zu dokumentieren und wieder zu entfernen.
Geeignete Schnittstellen im Bestand schaffen
Legacy-Systeme besitzen selten saubere Modulgrenzen. Deshalb werden zunächst sogenannte Seams geschaffen: Stellen, an denen Verhalten abgefangen, getestet oder ersetzt werden kann. Das kann eine API vor einer Datenbank, ein Adapter um einen Dateiexport oder ein neues Ereignis nach einer Transaktion sein.
final class CustomerLookup
{
public function __construct(
private LegacyCustomerGateway $legacy,
private CustomerApi $modern
) {
}
public function find(string $customerId): Customer
{
if ($this->modern->owns($customerId)) {
return $this->modern->find($customerId);
}
return $this->legacy->find($customerId);
}
}Verhalten vor dem Umbau absichern
In schlecht getesteten Systemen ist der erste Schritt nicht immer Refactoring, sondern Beobachtung. Characterization-Tests halten das tatsächliche Verhalten fest, auch wenn es nicht ideal ist. Contract-Tests sichern Schnittstellen zu anderen Systemen. Dadurch kann intern verändert werden, ohne unbeabsichtigt Kunden oder Prozesse zu brechen.
- Kritische Geschäftsabläufe als Ende-zu-Ende-Tests erfassen.
- Schnittstellenantworten und Dateiformate dokumentieren.
- Produktionsdaten anonymisiert für realistische Tests verwenden.
- Fehlerfälle und Wiederanläufe testen.
- Messwerte vor und nach jeder Migration vergleichen.
Datenmigration als eigenes Produkt behandeln
Daten sind häufig schwieriger als Code. Felder besitzen historisch mehrere Bedeutungen, Referenzen sind unvollständig und alte Zustände widersprechen neuen Regeln. Eine Migration benötigt deshalb Validierung, Wiederholbarkeit und fachliche Abnahme.
Bei langen Übergängen kann eine zeitweise Synchronisation notwendig sein. Dabei muss klar sein, welches System schreiben darf. Bidirektionale Synchronisation sollte nur eingesetzt werden, wenn sie wirklich unvermeidbar ist, weil Konflikte und Fehlerbehandlung stark zunehmen.
Kleine Releases und schnelle Rückwege
Modernisierung sollte in kleinen, beobachtbaren Schritten ausgeliefert werden. Feature Flags, schrittweise Aktivierung und definierte Rückfallpfade reduzieren das Risiko. Ein Rollback ist nur dann realistisch, wenn Datenänderungen und externe Effekte berücksichtigt wurden.
Fazit
Legacy-Modernisierung gelingt, wenn fachlicher Wert erhalten und technisches Risiko schrittweise reduziert wird. Klare Ziele, Systemtransparenz, Tests und kleine Releases sind wichtiger als ein möglichst radikaler Technologiewechsel. So entsteht früh Nutzen, während der Betrieb weiterhin verlässlich bleibt.
