Wenn das Luma-Theme deines Magento-2-Shops beim mobilen LCP bei 5 Sekunden hängt, steht die Frontend…
Big Bang oder progressiv? Warum die Migrationsstrategie über dein Saisonrisiko entscheidet
Jede Frontend-Migration hat einen Stichtag im Kopf. Die Frage ist nur, ob es einer ist oder viele. Ein Big-Bang-Cutover schaltet den neuen Storefront zu einem festen Zeitpunkt scharf und nimmt den alten vom Netz. Ein progressiver Ansatz verschiebt Seitentypen oder Routen nach und nach. Beide führen ans selbe Ziel, aber sie verteilen das Risiko völlig unterschiedlich - und genau diese Verteilung entscheidet, wie gefährlich eine Migration in der Nähe der Peak-Season wird. Dieser Beitrag zeigt, warum die Strategie eine Leadership-Entscheidung ist, nicht nur eine technische.
Was ein Big-Bang-Cutover wirklich riskiert
Beim Big Bang bündelt sich das gesamte Migrationsrisiko auf einen einzigen Moment. Alles muss gleichzeitig funktionieren: Routing, Checkout, Tracking, SEO-Signale, Caching, Redirects. Läuft etwas schief, betrifft es nicht einen Seitentyp, sondern den kompletten Store. Der Rollback ist binär - zurück auf das alte System oder nicht. Zwischen "alles neu" und "alles alt" gibt es keinen halben Zustand, in dem du kontrolliert nachjustierst.
Das Problem ist selten die Technik allein. Es ist die Gleichzeitigkeit. Ein Fehler im Produktdetail-Rendering, ein gebrochenes hreflang-Set, eine Regression bei den Core Web Vitals - jeder einzelne Punkt wäre isoliert handhabbar. Am Stichtag treffen sie gemeinsam auf den vollen Live-Traffic, und die Diagnose läuft unter maximalem Druck.
Warum die Saison das Risiko verschärft
Der Kalender macht aus einem beherrschbaren Risiko ein existenzielles. Fällt der Cutover in die Wochen vor Q4 oder direkt in die Aktionsphase, trifft ein potenzieller Ausfall auf den umsatzstärksten Traffic des Jahres. Die Kosten eines schlechten Tages skalieren mit dem Volumen dieses Tages.
Dazu kommt der Freeze: Viele Organisationen frieren zwischen November und Januar bewusst alle Änderungen am Storefront ein. Ein Big-Bang-Plan, der auch nur leicht rutscht, kollidiert mit diesem Fenster. Entweder man zieht den Termin gewaltsam durch, oder man verschiebt die gesamte Migration um ein halbes Jahr. Beide Optionen sind teuer.
Der progressive Pfad: Strangler statt Stichtag
Der progressive Ansatz folgt dem Strangler-Pattern: Der neue Storefront übernimmt Route für Route, während der alte den Rest weiter bedient. Statt einer großen Wette gibt es viele kleine, jede mit begrenztem Radius. Beginnt die Migration mit einem Content-Seitentyp mit moderatem Traffic, ist ein Fehler dort ärgerlich, aber nicht geschäftskritisch. Das Team lernt am echten Traffic, ohne den Checkout zu gefährden.
Der entscheidende Unterschied ist die Pausierbarkeit. Zeigt eine migrierte Route eine Regression, hältst du an, korrigierst und fährst weiter - ohne den ganzen Store zurückzudrehen. Das Risiko ist nicht verschwunden, aber es ist in verdauliche Stücke zerlegt.
Wie ein entkoppelter Frontend-Layer progressive Migration ermöglicht
Damit "manche Routen neu, andere alt" mehr ist als eine Absichtserklärung, braucht es eine Schicht, die den Verkehr bewusst aufteilt. Genau das leistet eine Frontend Management Platform (FMP): ein entkoppelter Composable Frontend-Layer über deinem Backend, der pro Route entscheidet, ob der neue oder der bestehende Storefront rendert.
Technisch heißt das: Ein Routing-Layer verteilt Anfragen anhand von Pfadmustern. /magazin/* läuft bereits über das neue Frontend, /produkt/* noch über den alten Store. Für Nutzer und Suchmaschinen bleibt es eine Domain, ein konsistentes Erlebnis. Als betriebene Schicht - Frontend as a Service - trägt diese Ebene Deployment, Caching und Beobachtbarkeit, sodass die Umschaltung pro Route ein kontrollierter Vorgang ist und kein Sprung ins Ungewisse.
Entlang Seitentypen und Routen schneiden
Die Kunst des progressiven Vorgehens liegt im Schnitt. Ein sinnvoller Reihenfolgevorschlag: erst niedrig frequentierte Content- und Landingpages, dann Kategorie- und Listenseiten, dann das Produktdetail, zuletzt der Checkout-nahe Bereich. Jeder Schritt liefert eine echte Referenz für den nächsten.
Zwei Aspekte verdienen früh Aufmerksamkeit. Erstens die Core Web Vitals: Jede migrierte Route sollte gegen dieselbe Performance-Baseline gemessen werden, damit die neue Schicht messbar besser ist und nicht nur anders. Zweitens SEO-Kontinuität - Canonical, Redirects und hreflang müssen über die Grenze zwischen alt und neu hinweg konsistent bleiben. Der Frontend-Layer ist der natürliche Ort, um diese Signale aus einer Quelle abzuleiten.
Um saisonale Peaks herum planen
Die Freeze-Fenster sind kein Hindernis für progressive Migration, sondern ihr größter Vorteil. Weil jede Route ein eigener kleiner Meilenstein ist, lässt sich der Plan präzise um den Peak legen: unkritische Seitentypen vor dem Freeze migrieren, umsatznahe Routen bewusst hinter das Fenster schieben. Kommt der Freeze, befindet sich das System in einem stabilen Zwischenzustand statt mitten im Umbau.
Ein Big-Bang-Plan kennt diesen stabilen Zwischenzustand nicht. Er ist entweder vor oder nach dem Stichtag - und wenn der Stichtag in den Freeze rutscht, gibt es keinen sicheren Ort, an dem man anhalten kann.
Wann Big Bang trotzdem vertretbar ist
Progressiv ist nicht automatisch immer richtig. Ein kleiner Store mit wenigen Seitentypen, klarer Saisonferne und einem Team, das den Cutover in einer ruhigen Woche stemmt, kann mit einem Big Bang schneller und günstiger fahren - der Koordinationsaufwand einer parallelen Doppelschicht entfällt. Die ehrliche Entscheidungsfrage lautet: Wie hoch ist der Umsatz pro Ausfallstunde, und wie nah liegt der Termin am Peak? Je größer beide Werte, desto stärker spricht alles für den progressiven Weg.
Nächste Schritte
Wenn eine Migration ansteht und der Kalender eng ist, lohnt der Blick auf die Schicht, die den Verkehr aufteilt. Sieh dir an, wie das Composable Frontend von Laioutr progressive Migration Route für Route ermöglicht.
Weitere Themen
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und arbeitet täglich an der Frage, wie E-Commerce-Teams ihren Frontend-Stack modernisieren, ohne den laufenden Betrieb und die Peak-Season zu gefährden. Mehr auf LinkedIn.
Alle Daten basieren auf öffentlich verfügbaren Informationen, Erfahrungen aus Sales-Gesprächen mit DACH-E-Commerce-Brands sowie eigenen Plattform-Tests. Stand: Juli 2026. Genannte Produktfunktionen können sich weiterentwickelt haben.