Was ist ein Big-Bang-Go-Live?

Die Umstellung vom alten auf den neuen Shop an einem Stichtag, für alle Kanäle und Märkte gleichzeitig. Bei AQMOS lief das in einem Abendfenster von sieben Stunden; Voraussetzung war, dass jeder der sechs Verkaufskanäle vorher einzeln abgenommen war. Ohne diese Vorarbeit ist der Stichtag kein Plan, sondern eine Wette.

Wie lange dauert ein Parallelbetrieb beim Shop-Wechsel?

So kurz wie möglich, weil zwei Plattformen doppelte Pflege, doppelten Support und Datensynchronisation in beide Richtungen bedeuten. Bei BWT wurden stattdessen sieben Schnittstellen über Monate nacheinander abgenommen und der Cutover selbst auf einen Termin komprimiert; das Ergebnis war eine Migration ohne eine verlorene Bestellung.

Kann man einen Shop ohne Downtime ablösen?

Ohne Umsatzverlust ja, ohne jede Sekunde Unterbrechung selten und meist unnötig. Ein Fenster von wenigen Stunden zur umsatzschwächsten Zeit der Woche kostet weniger als die Technik, die es vermeiden würde. Entscheidend ist, dass Bestellungen aus dem Fenster nicht verloren gehen, sondern nachgetragen werden.

Was passiert, wenn der Go-Live scheitert?

Wenn der Cutover-Plan Abbruchkriterien und einen geprobten Rückweg enthält: Der alte Shop läuft weiter, die Bestellungen des Abends werden nachgetragen, und der nächste Versuch wird terminiert. Wenn er das nicht enthält, wird improvisiert. Das ist der Moment, in dem Bestellungen verloren gehen.

Big Bang oder Wellen: wie Sie einen Shop ablösen, ohne den Umsatz zu riskieren

Sieben Stunden an einem Abend oder elf Monate sequenzierte Abnahme: zwei Projekte, zwei völlig verschiedene Go-Lives. Beide waren richtig. Wann der Big Bang trägt, wann Wellen, warum der Parallelbetrieb meist die teuerste Variante ist und was in jedem Cutover-Plan stehen muss.

Bei AQMOS haben wir an einem Abend umgeschaltet, in sieben Stunden. Bei BWT dauerte es elf Monate: sieben Backend-Systeme wurden nacheinander abgenommen, und am Ende ging keine einzige Bestellung verloren. Beides waren richtige Entscheidungen, getroffen für Systemlandschaften, die unterschiedlicher kaum sein könnten. Und es gibt eine dritte Variante, den Rollout in Wellen, der immer dann in Frage kommt, wenn sich das Geschäft in trennbare Einheiten schneiden lässt. Keine der drei Strategien ist die bessere. Dieser Text erklärt, woran Sie erkennen, welche zu Ihnen passt, und welche Frage Sie Ihrem Anbieter stellen sollten, bevor er Ihnen eine empfiehlt.

Was bedeutet Big Bang, was bedeutet Wellen?

Big Bang heißt: Es gibt einen Stichtag, an dem der alte Shop ausgeht und der neue angeht, und zwar für alle Kunden, alle Kanäle und alle Märkte gleichzeitig. Wellen heißt: Der neue Shop übernimmt schrittweise, etwa Land für Land, Kundengruppe für Kundengruppe oder Kanal für Kanal, und der alte Shop bedient währenddessen den Rest.

Dazwischen liegt der Parallelbetrieb, der in Angeboten gern als Sicherheitsnetz verkauft wird: alter und neuer Shop laufen gleichzeitig, mit synchronisierten Daten. In der Praxis ist das die teuerste der drei Varianten, weil Bestände, Preise und Kunden in zwei Richtungen abgeglichen werden müssen und jede Abweichung ein Support-Fall ist.

Und es gibt die Scheinvariante, die wir am häufigsten sehen: ein wochenlanger Soft-Launch mit eingefrorenem Sortiment, in dem niemand etwas ändern darf und der Vertrieb wartet. Das ist kein Parallelbetrieb. Das ist ein verlängerter Big Bang, bei dem der Umsatzverlust vorher anfällt statt nachher.

Wann ist der Big Bang die richtige Wahl?

Wenn es ein führendes System für Bestellungen gibt und sich jeder Kanal vorher vollständig durchspielen lässt. Dann ist der Stichtag kein Risiko, sondern das Ergebnis der Vorbereitung.

AQMOS ist das Beispiel. Zwei Anläufe mit anderen Anbietern waren gescheitert, und die naheliegende Empfehlung wäre gewesen, es beim dritten Mal besonders vorsichtig anzugehen: Parallelbetrieb, monatelang. Wir haben das Gegenteil gemacht. Jeder Prozess wurde einzeln bewertet, jede Versandart, jede Rechnungsregel und jeder Feed pro Kanal getestet: der eigene Shop, Amazon inklusive Business-Kunden mit Übernahme der USt-ID, eBay inklusive korrekt zugeordneter Selbstabholung, Google Shopping, Dropshipping und die Belieferung des stationären Handels. Erst als jeder Kanal einzeln abgenommen war, gab es einen Termin: den 19. Mai 2026, ein Abendfenster von sieben Stunden. Seitdem laufen alle sechs Kanäle in einer Shopware-6-Instanz, mit einem Bestand, einem Bestellprozess und einer Wahrheit für die Buchhaltung.

Drei Bedingungen müssen dafür erfüllt sein, sonst ist der Big Bang Mut statt Methode. Erstens ein einziges führendes System für Aufträge und Bestände, damit nichts in zwei Richtungen synchronisiert werden muss. Zweitens ein Rückweg, der in Stunden funktioniert: DNS zurück, alter Shop hochfahren, Bestellungen des Abends nachtragen. Das Ganze geprobt, nicht nur beschrieben. Drittens ein Zeitfenster mit dem geringsten Umsatz der Woche, das Sie kennen, weil Sie Ihre Bestelldaten nach Wochentag und Uhrzeit angeschaut haben.

Wann sind Wellen die richtige Wahl?

Wenn Ihr Geschäft aus Einheiten besteht, die eigene Sortimente, Preise oder Logistik haben und sich sauber voneinander trennen lassen. Dann ist jede Welle ein kleiner, überschaubarer Go-Live, und die erste Welle liefert das Wissen für die zweite.

Die natürliche Einheit ist meistens der Markt. Bei thyssenkrupp materials4me etwa verteilt sich dasselbe Geschäft auf drei Länder-Shops mit rund 2.400 Artikeln, fünf angebundenen Marktplätzen und eigenen Schnittstellen in Warenwirtschaft und Lager. Das ist eine Landschaft, die sich entlang der Länder schneiden ließe. Es kann genauso die Kundengruppe sein (B2C zuerst, B2B später), der Kanal (eigener Shop zuerst, Marktplätze später) oder die Marke. Entscheidend ist, dass die Einheiten nicht dieselben Bestände, Preise und Kundenkonten teilen. Tun sie es doch, sind es keine Wellen, sondern ein Parallelbetrieb mit anderem Namen.

Der Preis der Wellen steht selten im Angebot: Zwischen der ersten und der letzten Welle betreiben Sie zwei Plattformen. Zwei Deployments, zwei Monitoring-Setups, zwei Ansprechpartner im Support. Und jede Sortimentsänderung muss in beiden Welten passieren, bis die letzte Welle durch ist. Wer Wellen plant, hält diese Doppelphase so kurz wie möglich und setzt den Abschalttermin für das Altsystem fest, bevor die erste Welle live geht. Nicht danach: Ein Termin, der erst nach dem ersten Erfolgserlebnis verhandelt wird, verschiebt sich.

Der häufigste Fehler ist aber ein anderer. Die erste Welle wird der kleinste, unwichtigste Markt, weil das am wenigsten wehtut. Dann lernen Sie nichts. Die erste Welle muss groß genug sein, dass ihre Probleme die Probleme der restlichen Wellen sind.

Und wenn das Risiko nicht im Shop liegt, sondern in den Schnittstellen?

Dann ist beides falsch, und die Antwort heißt sequenzierte Abnahme mit einem Cutover am Ende. Das ist die Variante für Systemlandschaften, in denen nicht der Shop das Risiko ist, sondern das, was an ihm hängt.

Bei BWT hingen sieben Backend-Systeme am neuen Shop: das Sitecore-CMS aller Ländergesellschaften, ein zentraler Identity Server für das gemeinsame Benutzerkonto, CRM, Newsletter-System, Customer-Service-Tools, die Lagerverwaltung über vier Lagerstellen und die bestehende Warenwirtschaft aus ERP und PIM. Man kann sieben Systeme nicht an einem Abend umschalten und hoffen. Man kann sie aber nacheinander abnehmen: Für jede Schnittstelle gab es einen testbaren Satz, etwa diesen: Eine Bestellung mit zwei Positionen aus zwei Lagerstellen erzeugt genau einen Lieferschein und eine korrekte Bestandsbuchung in beiden Lagern. Solche Sätze wurden mit echten Artikeln und echten Preisen durchgespielt, Schnittstelle für Schnittstelle, über Monate. Wie diese Abnahmesätze im Detail aussehen, steht in unserem Artikel über Schnittstellen und Systemintegration.

Erst als alle sieben abgenommen waren, gab es den eigentlichen Cutover. Der war dann, wie bei AQMOS, ein Termin mit Prüfpunkten und Rückweg, kein Wagnis. Elf Monate von der Entscheidung bis zum Go-Live, über 1 Mio. € Projektvolumen, keine einzige verlorene Bestellung. Heute verlassen über 250 Bestellungen pro Tag die vier Lagerstellen, und der Umsatz hat sich nach der Umstellung verdoppelt.

Der Punkt für Ihr Gremium: Die elf Monate waren nicht die Dauer des Risikos, sondern die Dauer der Abnahme. Das Risiko selbst war auf einen Abend komprimiert. Wer die Projektlaufzeit als Risikozeitraum liest, verwechselt Vorbereitung mit Gefahr und kürzt genau an der Stelle, die den Go-Live trägt.

Welche Frage entscheidet wirklich über die Strategie?

Nicht die Größe des Unternehmens und nicht das Budget, sondern: Wie viele Systeme müssen am selben Tag umschalten, und wie viele voneinander unabhängige Geschäftseinheiten hängen daran? Aus diesen zwei Zahlen ergibt sich die Strategie fast von selbst.

Ein führendes System, alle Kanäle vorab testbar. Big Bang, gut vorbereitet, in einem Abendfenster.

Mehrere Märkte oder Kundengruppen mit eigenem Sortiment, eigenen Preisen, eigener Logistik. Wellen entlang dieser Einheiten, mit fixem Abschalttermin für das Altsystem.

Viele Backend-Systeme mit verschiedenen Zuständigen, aber ein gemeinsames Geschäft. Sequenzierte Abnahme jeder Schnittstelle, dann ein einziger Cutover.

Genauso wichtig ist, was die Entscheidung nicht bestimmen darf. Nicht die Angst: Ein Parallelbetrieb aus Vorsicht kostet mehr Umsatz, als er schützt, weil er das Sortiment einfriert und das Team lähmt. Nicht die Sorge um Rankings; die wird durch Redirects, URL-Strategie und strukturierte Daten gelöst, nicht durch die Rollout-Form. Was dabei zählt, steht in Relaunch ohne Ranking-Verlust. Und nicht der Komfort des Anbieters.

Fragen Sie ihn deshalb zwei Dinge: warum er genau diese Strategie für Ihre Systemlandschaft empfiehlt, und welche er in seinem letzten Projekt dieser Größe gewählt hat. Wer immer dieselbe Antwort hat, hat nicht auf Ihre Landschaft geschaut.

Was muss in jedem Cutover-Plan stehen?

Sechs Dinge, unabhängig von der Strategie. Fehlt eines davon, ist der Plan ein Deployment-Skript, aber kein Cutover-Plan.

Erstens das Zeitfenster, gewählt nach Ihren Bestelldaten, nicht nach dem Kalender der Agentur. Zweitens die Reihenfolge der Systeme und pro Schritt ein Prüfpunkt, der mit Ja oder Nein beantwortet wird; „sieht gut aus” ist kein Prüfpunkt. Drittens Abbruchkriterien, vorab festgelegt: bei welchem Ergebnis abgebrochen wird, ohne dass jemand um 21 Uhr diskutieren muss. Viertens der Rückweg, geprobt, mit Zeitangabe. Fünftens die Freeze-Regeln: was ab wann nicht mehr geändert werden darf, im alten wie im neuen System, und wer Ausnahmen genehmigt. Sechstens der Entscheider: eine Person mit Befugnis, die am Abend erreichbar ist und den Go oder No-Go gibt.

Der sechste Punkt ist der, der am häufigsten fehlt, und zugleich der einzige, den Ihr Dienstleister nicht für Sie erfüllen kann. Ein Cutover ist ein Termin mit Entscheider, kein Deployment.

Wenn Sie vor dieser Entscheidung stehen und noch nicht wissen, ob Ihr Shop an einem Abend umzieht oder in Wellen: Genau das ist die Frage, die sich in einem Gespräch klären lässt. Sie schildern Ihre Systemlandschaft und Ihre Märkte, wir sagen Ihnen, welche Rollout-Strategie wir wählen würden und warum. Wie eine Migration darüber hinaus aufgesetzt wird, steht in der Leistungsbeschreibung zur Shopware-Migration; wie ein Neustart nach einem gescheiterten ersten Anlauf abläuft, in Shop-Projekt gescheitert.