Webapp ablösen & migrieren: Alt durch Neu, ohne Stillstand

Die alte Webanwendung läuft - irgendwie. Sie ist langsam, niemand traut sich mehr an den Code, der ursprüngliche Entwickler ist längst weg, und jede kleine Änderung wird zum Risiko. Trotzdem hängt das halbe Tagesgeschäft daran. Sie wissen: Das muss abgelöst werden. Die Frage ist nur, wie - ohne dass der Laden stillsteht.

Nach über 25 Jahren, in denen ich gewachsene Systeme abgelöst und ersetzt habe, sage ich Ihnen die wichtigste Lehre gleich vorweg: Der große Knall - alt aus, neu an, über Nacht - geht fast immer schief. Es gibt einen besseren Weg.

TL;DR - Die Kurzfassung

• Der „Big Bang" - alles auf einmal ersetzen - ist der häufigste und teuerste Migrationsfehler.
• Schrittweise ablösen ist sicherer: Stück für Stück, bei laufendem Betrieb.
• Die Daten sind das Wertvollste, nicht der Code. Ihre Migration ist der heikelste Teil.
• Parallelbetrieb (alt und neu eine Zeit lang nebeneinander) nimmt das Risiko raus.
• Nicht alles muss mit. Eine Ablösung ist die Chance, Altlasten und tote Features loszuwerden.

Warum der große Knall fast immer scheitert

Die verführerische Idee: Wir bauen die neue Anwendung komplett fertig, schalten an einem Wochenende um, und Montag läuft alles neu. In der Theorie sauber. In der Praxis ein Minenfeld:

• Das alte System kann mehr, als jeder weiß. In gewachsenen Anwendungen stecken Jahre von Sonderfällen, Workarounds und stillen Annahmen. Niemand hat sie vollständig dokumentiert. Beim Big Bang fallen sie alle gleichzeitig auf - am Montagmorgen, im Echtbetrieb.
• Kein Zurück. Ist umgeschaltet, gibt es keinen sanften Rückweg. Wenn etwas Zentrales klemmt, steht das Geschäft.
• Alles-oder-nichts-Risiko. Monate Entwicklung münden in einen einzigen Stichtag. Verschiebt er sich (was er fast immer tut), wächst der Druck, mit halbfertigem Stand live zu gehen.

Je größer der Umschalt-Moment, desto größer der Knall, wenn etwas schiefgeht. Die Kunst der Migration besteht darin, den Moment klein zu machen - oder ganz aufzulösen.

Der bessere Weg: schrittweise ablösen

Die bewährte Strategie heißt im Fachjargon „Strangler" - das Neue wächst um das Alte herum und ersetzt es Stück für Stück, bis vom Alten nichts mehr übrig ist. Das Bild dahinter: Statt das Haus abzureißen und neu zu bauen, während die Familie auf der Straße steht, renoviert man Raum für Raum bei laufendem Wohnen.

Praktisch heißt das: Man identifiziert einen abgegrenzten Teil der Anwendung - ein Modul, einen Bereich, eine Funktion - und ersetzt nur diesen durch eine neue, saubere Umsetzung. Alt und neu laufen zusammen, der Nutzer merkt idealerweise nichts. Dann der nächste Teil. Und der nächste.

Die Vorteile

• Risiko in kleinen Portionen: Geht ein Schritt schief, betrifft es einen Teil - nicht das ganze System.
• Früher Nutzen: Der erste abgelöste Teil bringt sofort Verbesserung, nicht erst nach Monaten.
• Lernen unterwegs: Jeder Schritt macht das Team sicherer für den nächsten - statt am Ende alles auf einmal zu riskieren.
• Jederzeit pausierbar: Geht das Budget oder die Zeit aus, hat man trotzdem schon einen funktionierenden, teilmodernisierten Stand.

Das Wertvollste sind die Daten, nicht der Code

Eine Wahrheit, die oft übersehen wird: Code lässt sich neu schreiben - Ihre Daten nicht. Jahre von Kundendaten, Aufträgen, Belegen, Historie: Das ist das eigentliche Kapital in der alten Anwendung. Die Datenmigration ist deshalb der heikelste und wichtigste Teil jeder Ablösung.

Was dabei wirklich Arbeit macht (und im Angebot eines unerfahrenen Anbieters gern unterschätzt wird):

• Altdaten verstehen: Wie sind die Daten im Altsystem strukturiert - und was bedeuten die Felder wirklich? In gewachsenen Systemen wird ein Feld oft für drei verschiedene Dinge zweckentfremdet. Das muss man erst entschlüsseln.
• Bereinigen statt blind übernehmen: Dubletten, Karteileichen, inkonsistente Formate - eine Migration ist die Gelegenheit, mit sauberen Daten neu zu starten, statt den Müll mitzunehmen.
• Abbildung ins neue Modell: Das neue System hat (hoffentlich) eine sauberere Struktur. Die Altdaten müssen verlustfrei dorthin überführt werden - jeder Datensatz, nachvollziehbar.
• Prüfen, prüfen, prüfen: Nach der Migration muss bewiesen werden, dass nichts verloren ging und nichts verfälscht wurde. Stichproben reichen nicht - es braucht Abgleiche über die Gesamtmenge.

Wer hier tiefer einsteigen will: Dazu gibt es einen eigenen Beitrag zur Datenmigration von Altdaten und zur Legacy-Modernisierung allgemein.

Parallelbetrieb: das Sicherheitsnetz

Der sicherste Übergang lässt alt und neu eine Zeit lang nebeneinander laufen. Das gibt es in mehreren Spielarten:

• Lesend parallel: Das neue System zeigt schon Daten an, geschrieben wird aber noch im alten. Man sieht früh, ob das Neue korrekt rechnet.
• Modulweise umschalten: Ein Bereich läuft schon komplett neu, der Rest noch alt. Die beiden teilen sich die Daten über eine saubere Schnittstelle.
• Schatten-Betrieb: Das neue System verarbeitet im Hintergrund dieselben Vorgänge wie das alte - man vergleicht die Ergebnisse, bevor man wirklich umschaltet.

Parallelbetrieb kostet etwas mehr Aufwand, ist aber das wirksamste Mittel gegen den „am Montag steht alles"-Albtraum. Man schaltet erst dann endgültig um, wenn das Neue sich im echten Betrieb bewiesen hat.

Der kritische Punkt dabei: Solange alt und neu parallel laufen, muss eindeutig festgelegt sein, welches System bei welchem Datensatz führt - wer also die „Quelle der Wahrheit" ist. Sobald beide Seiten dieselben Daten schreiben dürfen (Dual-Write), laufen sie früher oder später auseinander - und man hat genau die Inkonsistenzen erzeugt, die man mit der Ablösung eigentlich loswerden wollte. Die saubere Regel lautet deshalb: pro Datenbereich schreibt zu jedem Zeitpunkt nur ein System, das andere liest. Erst wenn ein Bereich vollständig übergeben ist, wechselt die Führung.

Nicht alles muss mit

Eine Ablösung ist auch eine Chance: In jedem gewachsenen System gibt es Features, die einmal jemand wollte und die heute niemand mehr nutzt. Reports, die nie geöffnet werden. Sonderfälle für einen Kunden, den es nicht mehr gibt.

Diese Altlasten 1:1 mitzunehmen, ist verschwendetes Geld. Vor der Ablösung lohnt sich die ehrliche Frage: Was wird wirklich gebraucht? Oft schrumpft der Umfang spürbar - und damit Aufwand und Kosten. Das neue System wird schlanker, klarer und wartbarer als das alte.

Wie ich eine Ablösung angehe

1. Bestand verstehen: Was kann das alte System wirklich, wer nutzt was, wo liegen die Daten? Ohne dieses Bild ist jede Migration ein Blindflug.
2. Schneiden: In welche ablösbaren Teile lässt sich das System zerlegen? Womit fängt man an - idealerweise dort, wo der Schmerz am größten oder das Risiko am kleinsten ist.
3. Ersten Teil ablösen, parallel: Ein abgegrenztes Modul neu bauen, neben dem Alten laufen lassen, absichern.
4. Daten sauber migrieren & prüfen: Der kritische Schritt - mit vollständigem Abgleich.
5. Schritt für Schritt fortsetzen, bis das Alte abgeschaltet werden kann - ohne dass es je einen Stillstand gab.

Ich arbeite zu Festpreisen auf Basis von PHP, PostgreSQL und eigenen Servern. Weil eine schrittweise Ablösung planbar ist, lässt sich auch das Budget in überschaubaren Etappen statt als ein riesiges Alles-oder-nichts-Projekt fassen.

Checkliste: Ablösung planen

• Was genau stört am alten System - Tempo, Wartbarkeit, fehlende Funktionen, Sicherheit?
• Welche Daten stecken drin, und wie wertvoll/sensibel sind sie?
• Lässt sich das System in ablösbare Teile zerlegen?
• Welcher Teil zuerst - größter Schmerz oder kleinstes Risiko?
• Ist Parallelbetrieb möglich (Sicherheitsnetz)?
• Welche Features kann man getrost weglassen?
• Gibt es noch jemanden, der das Altsystem kennt?

Fazit: Raum für Raum statt Abrissbirne

Eine alte Webanwendung abzulösen ist kein Grund zur Panik - aber auch kein Wochenendprojekt. Der Schlüssel ist, den großen Knall zu vermeiden: schrittweise ersetzen, bei laufendem Betrieb, mit den Daten als kostbarstem Gut und Parallelbetrieb als Sicherheitsnetz.

So wird aus einer riskanten Operation am offenen Herzen ein planbarer Umbau - bei dem das Geschäft die ganze Zeit weiterläuft und am Ende ein schlankeres, schnelleres, wartbares System steht.

Ihre alte Webanwendung macht Ihnen Sorgen, aber Sie können sich keinen Stillstand leisten? Schreiben Sie mir kurz, was das System tut und wo es klemmt - ich zeige Ihnen einen Weg zur schrittweisen Ablösung und einen Festpreis-Rahmen für den ersten Schritt.