Das Wichtigste
- Komplette Neubauten scheitern häufiger an Umfang und Timing als an der Technik.
- Erst eine stabile Schnittstelle vor das Altsystem setzen, dann dahinter ersetzen.
- Eine Geschäftsfunktion nach der anderen ersetzen und in Produktion beweisen, bevor die nächste folgt.
- Alt und Neu parallel betreiben und Ergebnisse vergleichen, bevor der Verkehr umgeschaltet wird.
Ein kompletter Neubau verspricht einen Neuanfang und liefert meist ein langes, riskantes Projekt. Ein Altsystem schrittweise abzulösen hält das Geschäft am Laufen und beweist jeden Schritt.
Warum komplette Neubauten ins Stocken geraten
Ein Altsystem ist meist aus gutem Grund alt: Es funktioniert, und das Geschäft hängt davon ab. Jahre an Regeln, Ausnahmen und Korrekturen stecken darin, viele davon undokumentiert. Ein Neubau muss sie alle neu entdecken, während sich das alte System weiter verändert.
Das Ergebnis ist ein bekanntes Muster. Das neue System dauert länger als geplant, das alte braucht zwischendurch dringende Änderungen, und der Umstellungstermin verschiebt sich. Währenddessen bezahlt das Unternehmen zwei Systeme und profitiert von keinem.
Mit einer stabilen Schnittstelle beginnen
Der erste Schritt ist nicht, neuen Code für den Kern zu schreiben. Er besteht darin, eine Schnittstelle – meist eine API-Schicht – vor das bestehende System zu setzen, sodass andere Anwendungen mit dieser Schnittstelle sprechen statt direkt mit der alten Datenbank oder den alten Masken.
Sobald Nutzer von der Schnittstelle statt von der Implementierung abhängen, lässt sich dahinter Stück für Stück etwas ändern. Das nennt man oft Strangler-Pattern: Das neue System wächst nach und nach um das alte herum, bis das alte abgeschaltet werden kann.
Nach Geschäftsfunktionen priorisieren
Wählen Sie die erste abzulösende Funktion nach zwei Kriterien: wie viele Probleme sie heute verursacht und wie isoliert sie ist. Ein guter erster Kandidat hat klare Ein- und Ausgaben und wenige Abhängigkeiten – etwa die Angebotserstellung, Benachrichtigungen oder das Reporting.
Beginnen Sie nicht mit dem zentralsten, am stärksten vernetzten Teil des Systems. Frühe Phasen sollen Vertrauen und gemeinsames Verständnis aufbauen, nicht das ganze Projekt aufs Spiel setzen.
- Funktionen und die Daten, die jede besitzt, erfassen.
- Jede Funktion nach geschäftlichem Schmerz und Kopplung bewerten.
- Dort beginnen, wo der Schmerz hoch und die Kopplung gering ist.
- Den Kern der Transaktionsverarbeitung aufheben, bis das Team die Domäne gut kennt.
Jeden Schritt im Parallelbetrieb beweisen
Bevor eine Funktion umgestellt wird, laufen alte und neue Implementierung mit denselben Eingaben parallel, und die Ergebnisse werden verglichen. Abweichungen decken undokumentierte Regeln schneller auf als jeder Anforderungsworkshop.
Schalten Sie den Verkehr schrittweise um – nach Filiale, Kundengruppe oder Prozentsatz – und halten Sie einen dokumentierten Weg zurück bereit. Ein Migrationsschritt, der sich nicht rückgängig machen lässt, braucht noch mehr Vorbereitung.
Datenmigration als eigenes Projekt behandeln
Daten überleben Code. Alte Daten enthalten oft Dubletten, uneinheitliche Formate und Felder, die für etwas anderes genutzt werden als vorgesehen. Planen Sie Bereinigung, Zuordnung und Prüfung ausdrücklich, mit Zählungen und Prüfsummen, die belegen, dass nichts verloren ging.
Wenn die letzte Funktion umzieht, sollte die Abschaltung des Altsystems eine Formalität sein: Alle Nutzer verwenden bereits die neue Schnittstelle, alle Daten sind geprüft, und das Unternehmen arbeitet seit Wochen mit dem neuen System.
Hat es Ihnen gefallen? Den nächsten Beitrag per E-Mail erhalten.