SAP Commerce Cloud ist stark darin, komplexe B2B- und B2C-Modelle auf einem Backend zu betreiben: me…
WEBSALE Headless: Frontend erneuern ohne Backend-Anfassen
Replatforming klingt nach einem 12-Monats-Projekt mit hohem Risiko. Es gibt einen anderen Weg: das Frontend phasenweise erneuern, während das WEBSALE-Backend unverändert läuft. Kein Big-Bang, kein paralleler Betrieb zweier Backends, keine doppelte Datenhaltung. Dieser Artikel zeigt, wie das konkret aussieht, was realistisch in welchem Zeitraum geht, und wo Rollback-Punkte sind.
Das Grundprinzip: Frontend-First, Backend bleibt
WEBSALE betreibt eine REST-basierte Storefront-API. Diese API ist der einzige Touchpoint zwischen Backend und Frontend. Laioutr bindet sich an diese API, ohne dass WEBSALE-seitig etwas geändert wird. Das Backend - Produktdaten, Preislogik, B2B-Konfigurationen, Abo-Funktionen, Bestellabwicklung - läuft unverändert weiter.
Das bedeutet: Replatforming im klassischen Sinne (Backend wechseln, Daten migrieren, parallel zwei Systeme betreiben) ist nicht notwendig. Was erneuert wird, ist der Frontend-Layer.
Phasenmodell: Wie der Übergang aussieht
Phase 0 - Vorbereitung (Woche 1 bis 2)
Vor dem ersten Code laufen zwei Aufgaben:
WEBSALE API-Review: Welche Endpunkte werden genutzt? Produktdaten, Kategoriestruktur, Warenkorb, Checkout, Account? Sind alle nötigen Endpunkte dokumentiert und stabil? Gibt es B2B-spezifische Logik (Kundengruppen, Preislisten, Freigabe-Workflows), die im Checkout-Flow verankert ist?
Sitemap und Priorisierung: Welche Seiten werden zuerst migriert? Empfehlung: mit Landingpages und Kategorieseiten anfangen (hohe Marketing-Wirkung, kein Transaktions-Risiko), dann Produktdetailseiten, zuletzt Warenkorb und Checkout.
Phase 1 - Basis-Anbindung und erste Seiten (Woche 2 bis 4)
Laioutr-Connector für WEBSALE wird konfiguriert. API-Endpunkte werden hinterlegt, Datenmapping wird geprüft, erste Komponenten (Produktliste, Hero-Banner, Navigationselemente) werden mit echten WEBSALE-Daten validiert.
Deliverable nach Phase 1: Ein Preview-Environment mit echten WEBSALE-Produktdaten, in dem Marketing erste Seiten-Entwürfe sehen kann. Nichts ist live; alles ist reversibel.
Phase 2 - Landingpages und Kategorieseiten (Woche 4 bis 8)
Neue Seiten entstehen parallel zur bestehenden WEBSALE-Storefront. Traffic läuft noch vollständig über das bestehende Frontend. Neue Laioutr-Seiten werden auf einer Staging-Domain vorabgenommen; SEO-Redirects werden vorbereitet (aber noch nicht aktiviert).
Rollback-Punkt: Bis zum Ende dieser Phase ist ein Stopp ohne Produktions-Impact möglich. Kein Customer sieht die neuen Seiten.
Phase 3 - Soft-Launch für ausgewählte Seiten (Woche 8 bis 10)
Einzelne Landingpages oder Kategorienseiten werden auf das neue Laioutr-Frontend geleitet (per A/B-Routing oder DNS-Routing auf URL-Ebene). Bestehende Storefront läuft weiter. SEO-Impact wird gemessen; Performance-Metriken (LCP, CLS, INP) werden über beide Varianten verglichen.
Was hier nicht passiert: Kein Warenkorb, kein Checkout-Wechsel, kein Account-Wechsel. Nur redaktionelle und Kategorie-Seiten. Transaktionsrisiko ist null.
Rollback: DNS-Änderung rückgängig machen. 5 Minuten.
Phase 4 - Produktdetailseiten (Woche 10 bis 14)
Produktdetailseiten werden migriert. Das ist der erste Schritt mit echtem Commerce-Kontext (Add-to-Cart-Button), aber Warenkorb und Checkout laufen weiterhin über WEBSALE-native Endpoints. Technisch ist die WEBSALE-Storefront-API der Kleber: Add-to-Cart geht direkt an WEBSALE, der Checkout-Flow ist WEBSALE-nativ.
Phase 5 - Warenkorb und Checkout (optional, ab Woche 14)
Wenn der Laioutr Headless Checkout genutzt werden soll: jetzt. Das ist der einzige Schritt mit echtem Transaktionsrisiko. Vor dem Go-Live: vollständige End-to-End-Tests für alle relevanten Checkout-Szenarien (B2B-Kundengruppen, Gutscheine, verschiedene Zahlungsmethoden, Freigabe-Workflows).
Rollback-Plan: Bei kritischen Fehlern im Laioutr Checkout kann innerhalb von Minuten auf den WEBSALE-nativen Checkout zurückgerouted werden. Der Cart-State wird per Session verwaltet und ist nicht Backend-gebunden.
Phase 6 - Full Migration und Cleanup (Woche 14 bis 18)
Alle Seiten laufen auf dem neuen Frontend. Die alte WEBSALE-Storefront-Konfiguration kann deaktiviert werden. SEO-Redirects sind aktiv und verifiziert. Performance-Baseline ist dokumentiert.
Realistischer Zeitrahmen
- 0 - Vorbereitung: Wochen: 1 bis 2 · Risikostufe: Keine · Rollback möglich?: Nicht nötig
- 1 - Basis-Anbindung: Wochen: 2 bis 4 · Risikostufe: Sehr niedrig · Rollback möglich?: Ja, vollständig
- 2 - Landingpages/Kategorien: Wochen: 4 bis 8 · Risikostufe: Niedrig · Rollback möglich?: Ja, vollständig
- 3 - Soft-Launch: Wochen: 8 bis 10 · Risikostufe: Niedrig · Rollback möglich?: Ja, 5 Minuten
- 4 - Produktdetailseiten: Wochen: 10 bis 14 · Risikostufe: Mittel · Rollback möglich?: Ja, DNS
- 5 - Checkout (optional): Wochen: ab 14 · Risikostufe: Mittel bis hoch · Rollback möglich?: Ja, Routing
- 6 - Full Migration: Wochen: 14 bis 18 · Risikostufe: Niedrig · Rollback möglich?: Nicht mehr nötig
Gesamtdauer bis zur vollen Migration: 14 bis 18 Wochen, bei klarer Vorbereitung und konsequenter Phasendisziplin.
Wichtig: Diese Wochen-Zahlen setzen einen fokussierten Umsetzungskontext voraus. Wenn das Projekt nebenbei läuft, sind 6 Monate realistischer. Frontend-First-Migrationen scheitern häufig nicht am Konzept, sondern an der Ressourcen-Priorisierung.
SEO-Risikominimierung
Jede Frontend-Migration trägt SEO-Risiko. Die wichtigsten Schutzmaßnahmen:
Pre-Launch-Crawl: Vor jeder Phase-Aktivierung einen Crawl der Ziel-URLs mit Screaming Frog oder ähnlichem Tool - Status-Codes, Title-Tags, Meta-Descriptions, Canonicals prüfen.
Redirect-Mapping vorbereiten: Wenn URL-Strukturen sich ändern, 301-Redirects vor dem Go-Live vorbereiten und testen. WEBSALE und Laioutr-Seiten können vorübergehend parallel unter verschiedenen Domains laufen.
GSC-Monitoring: Google Search Console vor Beginn mit beiden Domains verknüpfen. Traffic-Einbruch innerhalb von 48 Stunden sichtbar.
Lighthouse-Baseline: Performance vor und nach jedem Phasenwechsel messen. LCP-Verschlechterung ist SEO-Signal; mit Laioutr typisch eine Verbesserung (LCP-Median 1,2 s in Live-Frontends).
Häufige Fallstricke
B2B-Logik im Checkout unterschätzen: Wenn WEBSALE mit Kundengruppen, individuellen Preislisten oder Freigabe-Workflows betrieben wird, braucht Phase 5 (Checkout-Migration) deutlich mehr Test-Aufwand. Plane mindestens 2 bis 4 Wochen für B2B-Checkout-Testing.
SEO-Redirects zu spät aktivieren: 301-Redirects müssen am Tag des Go-Lives aktiv sein, nicht danach. Fehlende Redirects bedeuten temporäre 404s - Google wertet das als Content-Entfernung.
Alle Seiten gleichzeitig migrieren wollen: Big-Bang-Migrationen haben eine schlechte Erfolgsrate. Phasenweise vorgehen ist nicht nur sicherer, sondern auch schneller im Gesamtergebnis.
Stakeholder-Alignment vergessen: Marketing und IT müssen dieselbe Phasendefinition haben. Wer entscheidet über den Go-Live von Phase 3? Wer triggert den Rollback? Das vor dem Start klaren.
Interne Links
FAQ
Muss WEBSALE zustimmen oder mitarbeiten?
Nein. Die Storefront-API ist der einzige Touchpoint. WEBSALE-seitige Konfigurationsänderungen sind nicht notwendig. Das WEBSALE-Supportsystem wird durch die Migration nicht beeinflusst.
Was passiert mit bestehenden WEBSALE-Anpassungen (Custom-Templates, Plugins)?
Diese Anpassungen laufen auf Backend-Ebene weiter. Nur Frontend-seitige Darstellungslogik wird durch Laioutr übernommen. Backend-Plugins, die Commerce-Logik steuern (z.B. Steuerkalkulation, Versandlogik, B2B-Preisfindung), sind nicht betroffen.
Wie sichere ich SEO-Rankings während der Migration?
Redirect-Mapping vor Go-Live, Pre-Launch-Crawl, GSC-Monitoring, Lighthouse-Baseline. Laioutr verbessert typisch Performance-Metriken, was langfristig SEO-positiv ist.
Kann ich nur einen Teil der Seiten migrieren und den Rest bei WEBSALE lassen?
Ja. Die Phasenstrategie erlaubt partielle Migration. Landingpages, die häufig Marketing-Content brauchen, eignen sich besonders für den ersten Schritt.
Was ist, wenn etwas im Checkout schiefgeht?
Routing-Rollback auf WEBSALE-nativen Checkout ist in Minuten möglich. Cart-State bleibt erhalten, da er Session-basiert in WEBSALE verwaltet wird.
Wird Laioutr auch Daten aus WEBSALE migrationieren (z.B. Kundendaten, Bestellhistorie)?
Nein. Laioutr ist Frontend-Layer. Kundendaten, Bestellhistorie und alle Commerce-Daten bleiben in WEBSALE. Es gibt keine Datenmigration.