Migration ohne Big Bang: Alt- und Neusystem kontrolliert parallel betreiben.

Der klassische Migrationsplan kulminiert in einem einzigen Moment: Der alte Shop wird abgeschaltet, DNS oder Routing werden umgestellt und ab diesem Zeitpunkt übernimmt das neue System vollständig. Dieses Big-Bang-Modell ist verständlich. Es vermeidet eine lange Parallelphase und erzeugt einen eindeutigen Übergang.

Bei komplexen Commerce-Landschaften kann genau dieser eine Zeitpunkt jedoch sehr viel Risiko bündeln. Produktdaten, Preise, Kundenkonten, Bestellungen, Zahlungen, ERP-Übergaben und Weiterleitungen müssen gleichzeitig funktionieren. Ein Fehler in nur einer kritischen Kette kann den gesamten Vertrieb beeinträchtigen.

Eine kontrollierte Koexistenz von Alt- und Neusystem kann das Risiko reduzieren. Sie ist allerdings nicht automatisch sicherer. Ohne klare Zuständigkeiten erzeugt sie doppelte Datenpflege, widersprüchliche Zustände und schwer beherrschbare Synchronisationen.

Wann eine Parallelphase sinnvoll ist

Ein paralleler Betrieb lohnt sich besonders, wenn:

• mehrere geschäftskritische Integrationen umgestellt werden,
• Datenqualität erst gegen reale Quellsysteme überprüft werden kann,
• verschiedene Märkte oder Mandanten schrittweise migriert werden,
• ein hoher Anteil wiederkehrender Bestandskunden existiert,
• Preis- und Verfügbarkeitslogik komplex ist,
• das neue System zunächst nur einen Teil des Sortiments übernimmt,
• ein sofortiger vollständiger Rollback schwer wäre,
• die Kosten eines fehlerhaften Go-lives deutlich höher als die einer Übergangsphase sind.

Nicht sinnvoll ist eine Parallelphase, wenn sie nur aus Unsicherheit immer weiter verlängert wird. Sie benötigt von Anfang an einen klaren Zweck, messbare Prüfungen und ein geplantes Ende.

Koexistenz ist nicht gleich Dual Write

Der gefährlichste Reflex in einer Parallelphase lautet: Beide Systeme sollen vorübergehend alles lesen und schreiben können.

Damit entsteht Dual Write. Eine Kundenänderung muss in zwei Systeme übertragen werden, eine Bestellung könnte doppelt entstehen und Statusänderungen laufen in beide Richtungen. Schon kleine Verzögerungen oder Fehler erzeugen Abweichungen.

Besser sind klar definierte Koexistenzmuster.

Read Shadow

Das neue System liest und verarbeitet reale Daten, beeinflusst aber den operativen Prozess noch nicht. Ergebnisse werden mit dem Altsystem verglichen.

Beispiel:

• Beide Systeme berechnen die Verfügbarkeit eines Produkts.
• Nur der alte Shop verkauft.
• Abweichungen werden protokolliert und untersucht.

Traffic Split

Ein abgegrenzter Teil des Traffics oder Geschäfts läuft über das neue System.

Mögliche Grenzen:

• ein Land,
• eine Marke,
• eine Kundengruppe,
• ein Sortiment,
• interne Testnutzer,
• ein definierter Prozentanteil.

Read from New, Write to Old

Das neue Frontend oder Portal zeigt Daten aus der neuen Architektur, operative Änderungen werden aber noch in das bestehende Kernsystem geschrieben.

Write to New, Mirror to Old

Das neue System wird führend. Daten werden nur noch für Übergangszwecke in das alte System gespiegelt, etwa damit bestehende Backoffice-Prozesse weiterarbeiten können.

Historical Split

Neue Vorgänge entstehen im neuen System, alte Bestellungen und Konten bleiben read-only im bisherigen System oder werden über ein Archiv zugänglich gemacht.

Der wichtigste Grundsatz lautet:

Shadow Checks machen Unterschiede sichtbar

Ein Shadow Check verarbeitet denselben fachlichen Fall in Alt- und Neusystem, ohne dass beide Ergebnisse produktiv wirksam werden.

Mögliche Vergleiche:

• Preisberechnung,
• Steuer,
• Versandkosten,
• Verfügbarkeit,
• Kundengruppenzuordnung,
• Produktfilter,
• ERP-Mapping,
• Gesamtbetrag einer Bestellung.

Dabei ist wichtig, nicht nur „gleich" oder „ungleich" zu speichern. Die Abweichung muss fachlich analysierbar sein.

Beispiel:

Produkt: A-4711
Kunde: K-882
Menge: 25
Altpreis: 412,50 EUR
Neupreis: 418,75 EUR
Differenz: Metallzuschlag im neuen System mit aktuellem Tageswert
Bewertung: erwartete Abweichung

Nicht jede Abweichung ist ein Fehler. Das neue System kann bewusst andere Regeln verwenden. Deshalb benötigen Shadow Checks Kategorien wie:

• identisch,
• erwartete Abweichung,
• tolerierbare Rundungsdifferenz,
• ungeklärte Abweichung,
• kritischer Fehler.

Daten während der Übergangsphase synchronisieren

Auch bei klarer Schreibhoheit müssen manche Informationen zwischen beiden Welten ausgetauscht werden.

Beispiele:

• neue Kundenkonten,
• Bestellstatus,
• geänderte Produktdaten,
• Preis- und Bestandsinformationen,
• Weiterleitungs- oder URL-Mappings.

Für jeden Datenfluss sollten dokumentiert sein:

• Quelle,
• Ziel,
• Richtung,
• Rhythmus,
• erlaubte Verzögerung,
• Fehlerbehandlung,
• Wiederholungsstrategie,
• Eigentümer des Prozesses,
• Abschaltzeitpunkt.

Übergangsschnittstellen sollten nicht unbemerkt zu dauerhaften Kernkomponenten werden. Ihr Verfallsdatum gehört in die Architekturentscheidung.

Cutover-Kriterien statt Bauchgefühl

Der endgültige Wechsel sollte an messbare Bedingungen geknüpft sein.

Mögliche Kriterien:

Daten

• definierter Anteil der aktiven Produkte erfolgreich migriert,
• keine ungeklärten kritischen Identitätskonflikte,
• Preise und Bestände innerhalb vereinbarter Aktualität,
• Medien und Dokumente vollständig für das aktive Sortiment.

Prozesse

• repräsentative Bestellfälle erfolgreich Ende zu Ende getestet,
• ERP-Übergabe und Statusrückfluss stabil,
• Storno, Rückerstattung und Sonderfälle geprüft,
• Kundenkonto und Passwortprozess funktionsfähig.

Qualität

• Shadow Checks unterhalb definierter Fehlergrenzen,
• keine offenen Fehler der höchsten Priorität,
• Performance und Verfügbarkeit innerhalb der Zielwerte.

Betrieb

• Monitoring und Alerts aktiv,
• Support- und Eskalationswege besetzt,
• Runbooks vorhanden,
• Backup und Wiederherstellung geprüft,
• Verantwortlichkeiten für die ersten Betriebstage geklärt.

Ein Go-live-Datum bleibt wichtig. Es sollte aber nicht das einzige Kriterium sein.

Rollback ist mehr als DNS zurückdrehen

Ein technischer Rückwechsel auf den alten Shop ist nur dann ein echter Rollback, wenn die währenddessen entstandenen Geschäftsvorgänge berücksichtigt werden.

Zu klären ist:

• Was passiert mit Bestellungen, die bereits im neuen System entstanden sind?
• Sind Kundenkonten oder Passwörter verändert worden?
• Wurden Gutscheine eingelöst?
• Haben sich Bestände oder Reservierungen verändert?
• Welche Daten müssen in das Altsystem nachgezogen werden?
• Können Zahlungen und Erstattungen weiterhin verarbeitet werden?

Deshalb kann ein vollständiger Rollback nach dem ersten produktiven Schreibvorgang schwieriger sein als eine gezielte Vorwärtskorrektur. Der Plan sollte beide Optionen enthalten:

• technischer Rückfall vor produktiven Writes,
• kontrollierter Vorwärtsbetrieb mit deaktivierten Teilfunktionen nach produktiven Writes.

Das Altsystem bewusst stilllegen

Nach erfolgreichem Cutover bleibt das alte System häufig aus Sicherheitsgründen erreichbar. Ohne klare Regelung wird daraus ein dauerhaftes Schattenarchiv, das weiterhin Kosten, Sicherheitsrisiken und Unklarheit erzeugt.

Ein Stilllegungsplan definiert:

• welche Daten archiviert werden,
• wer noch Zugriff benötigt,
• wann Schreibzugriffe enden,
• welche rechtlichen Aufbewahrungsfristen gelten,
• wann Infrastruktur abgeschaltet wird,
• wie alte URLs und Integrationen behandelt werden,
• welche Übergangsschnittstellen entfernt werden.

Das Ende des Altsystems ist ein eigener Projektmeilenstein – nicht nur eine spätere Aufräumaufgabe.