Von SAP Hybris zur Commerce Cloud in 90 Tagen: Ein Migrations-Leitfaden

Wenn wir erzählen, dass wir Franke in 90 Tagen von SAP Hybris zu SAP Commerce Cloud migriert haben, ist die erste Reaktion Ungläubigkeit. Neunzig Tage klingt ambitioniert für etwas, das die meisten Unternehmen als 8-12-Monats-Projekt einschätzen.

Aber wir haben es geschafft. Und SAP hat das Projekt mit einem Quality Award für die Effizienz und Qualität der Umsetzung ausgezeichnet. Dieser Beitrag teilt den Leitfaden — nicht die Marketing-Version, sondern die tatsächliche Methodik, den Zeitplan und die Entscheidungen, die es möglich gemacht haben.

Wenn Sie die EoMM-Deadline im Juli 2026 vor sich haben, ist das direkt auf Ihre Situation anwendbar.

Warum 90 Tage erreichbar sind

Eine 90-Tage-Migration bedeutet nicht, Abkürzungen zu nehmen. Sie bedeutet, Verschwendung zu eliminieren. Die meisten langen Migrationszeitpläne sind durch drei Dinge aufgebläht:

1. Analyse-Paralyse. Teams verbringen Monate damit, Anforderungen zu dokumentieren, die bereits im laufenden System existieren.
2. 1:1-Replikation unnötiger Anpassungen. Code migrieren, der auf der Zielplattform nicht benötigt wird.
3. Sequenzielle Phasen mit Übergabe-Verzögerungen. Warten auf Freigaben, Übergaben und Kontextwechsel zwischen Teams.

Entfernen Sie das, und die eigentliche Arbeit — Datenmigration, Plattformkonfiguration, Integrationsanbindung und Testing — passt in 90 Tage für eine mittelgrosse Commerce-Plattform.

Die Vorbereitungsphase (Woche -4 bis 0)

Die 90-Tage-Uhr startet beim Kickoff. Aber 30 Tage Vorbereitung vor dem Kickoff machen den Unterschied zwischen einem kontrollierten Sprint und einem chaotischen Hauruckverfahren.

Plattform-Audit (Woche -4 bis -3)

Wir erfassen alles in der bestehenden SAP Hybris-Instanz:

• Custom Extensions: Zählen, klassifizieren (noch benötigt / ersetzbar / obsolet), Migrationsaufwand pro Extension schätzen.
• Datenmodelle: Custom Types, Relationen und Attribute dokumentieren. Identifizieren, was direkt auf Commerce Cloud abgebildet wird und was Transformation braucht.
• Integrationen: Jede ein- und ausgehende Verbindung auflisten — ERP, PIM, CRM, Payment, Shipping, Tax. Protokolle, Datenformate und Frequenzen dokumentieren.
• Anpassungs-Hotspots: Die 20 % Custom Code identifizieren, die 80 % der Geschäftslogik abdecken.

Beim Franke-Projekt ergab dieses Audit, dass 35 % der Custom Extensions Workarounds für On-Prem-Einschränkungen waren. Wir haben sie sofort aus dem Scope genommen und damit 3 Wochen Migrationsaufwand gespart.

Daten-Profiling (Woche -3 bis -2)

Bevor Sie die Migrationstools anfassen, verstehen Sie Ihre Daten:

• Jede Datenentität auf Vollständigkeit, Konsistenz und Qualität prüfen
• Duplikate, verwaiste Datensätze und Daten identifizieren, auf die seit 2+ Jahren nicht zugegriffen wurde
• Datenmigrationsstrategie festlegen: vollständige historische Migration vs. rollendes Zeitfenster vs. Neustart für nicht-essenzielle Daten
• ETL-Pipeline mit einem kleinen Daten-Sample aufbauen und testen

Umgebungen einrichten (Woche -2 bis -1)

• SAP Commerce Cloud-Umgebungen provisionieren (Entwicklung, Staging, Produktion)
• CI/CD-Pipelines konfigurieren
• Monitoring und Alerting einrichten
• Zugang für alle Teammitglieder sicherstellen

Team-Alignment (Woche -1)

• Backlog mit priorisierten Arbeitspaketen finalisieren
• Klare Verantwortlichkeiten pro Workstream zuweisen: Plattform, Daten, Integrationen, Frontend, Testing
• Definition of Done für jedes Delivery-Inkrement vereinbaren
• Tägliche Standups und wöchentliche Stakeholder-Demos etablieren

Sprint 1: Kernplattform (Tag 1-21)

Die ersten drei Wochen konzentrieren sich darauf, die Kernplattform auf Commerce Cloud mit Ihren Datenmodellen und der Basiskonfiguration zum Laufen zu bringen.

Was erledigt wird

• Datenmodell-Migration. Custom Types, Enums und Relationen auf Commerce Cloud übertragen. Gegen das Plattform-Audit validieren.
• Kern-Geschäftslogik. Die kritischen 20 % der im Audit identifizierten Anpassungen migrieren. Warenkorbberechnung, Preisregeln, Promotions-Engine-Konfiguration, Steuerberechnung.
• Basis-Storefront. Composable Storefront mit Ihrem Produktkatalog deployen. Noch kein Custom Styling — funktionale Korrektheit zuerst.
• Erster Datenladevorgang. Vollständige Datenmigration auf Staging ausführen. Datensatzzahlen, Datenintegrität und zentrale Geschäftsabläufe validieren.

Was NICHT erledigt wird

• Visuelle Design-Feinschliffe
• Nicht-kritische Integrationen (Analytics, Bewertungsplattformen, Loyalty)
• Performance-Optimierung
• Edge-Case-Geschäftslogik

Meilenstein an Tag 21

Ein funktionierender Storefront auf Commerce Cloud Staging mit echten Daten, Kern-Geschäftslogik und Basis-Checkout-Flow. Stakeholder können Produkte durchsuchen, in den Warenkorb legen und eine Bestellung abschliessen. Es sieht noch nicht perfekt aus. Es funktioniert.

Sprint 2: Integrationen und Frontend (Tag 22-50)

Mit der bewiesenen Kernplattform verbindet Sprint 2 das Ökosystem wieder und verfeinert das Erlebnis.

Integrationsanbindung (Tag 22-36)

Integrationen in der Reihenfolge der Geschäftskritikalität bearbeiten:

1. ERP/Auftragsmanagement: Auftragsexport, Bestandssynchronisation, Preisaktualisierungen
2. Zahlungsanbieter: Payment Gateway mit Commerce Clouds Payment-Extension verbinden
3. Versand/Logistik: Tarifberechnung, Label-Generierung, Tracking-Updates
4. PIM/Content: Produktdaten-Feeds, Media-Asset-Synchronisation
5. CRM/CDP: Kundendaten-Synchronisation

Für jede Integration:

• Prüfen, ob der bestehende API-Vertrag noch funktioniert
• Endpoint-URLs und Authentifizierung aktualisieren
• End-to-End-Tests mit echten Daten durchführen
• Allfällige Verhaltensunterschiede dokumentieren

Frontend-Verfeinerung (Tag 30-50)

Parallel zur Integrationsarbeit:

• Marken-Styling auf Composable Storefront anwenden
• Im Audit identifizierte Custom-UI-Komponenten implementieren
• Für Mobile optimieren (responsive Layouts, Touch-Interaktionen)
• SEO-Anforderungen umsetzen (Meta-Tags, strukturierte Daten, URL-Redirects von alten Pfaden)

Meilenstein an Tag 50

Ein vollständig integriertes Commerce Cloud-Deployment mit allen kritischen Integrationen live, markenkonformem Frontend und funktionierendem End-to-End-Bestellfluss vom Browsen bis zur Abwicklung.

Sprint 3: Härtung und Go-Live (Tag 51-90)

Die letzte Phase dreht sich um Vertrauen. Sie haben bereits ein funktionierendes System. Jetzt beweisen Sie, dass es produktionsreif ist.

Performance-Testing (Tag 51-60)

• Lasttests mit realistischen Traffic-Mustern (Spitzentag-Simulation)
• Engpässe identifizieren und beheben
• Auto-Scaling-Verhalten validieren
• Seitenladezeiten gegen Zielwerte benchmarken

User Acceptance Testing (Tag 55-70)

• Business-User testen jeden kritischen Flow: Suche, Browsen, Warenkorb, Checkout, Bestellverfolgung, Retouren
• Test mit echten Kundenkonten und echten Produktdaten
• Alle Integrationen unter realistischen Bedingungen verifizieren
• Alle P1- und P2-Probleme dokumentieren und lösen

Generalprobe Datenmigration (Tag 65-75)

• Die vollständige Datenmigrations-Pipeline end-to-end durchlaufen
• Laufzeit messen — das definiert Ihr Cutover-Fenster
• Delta-Migration für Daten validieren, die zwischen der Generalprobe und Go-Live erstellt werden
• Rollback-Prozeduren testen

Go-Live-Vorbereitung (Tag 75-85)

• Go-Live-Runbook erstellen: Schritt-für-Schritt-Aktionen, Verantwortliche, Timing, Rollback-Trigger
• DNS und CDN konfigurieren
• URL-Redirects von alten zu neuen Pfaden einrichten
• Support-Team briefen
• Wartungsfenster an Stakeholder kommunizieren

Go-Live und Stabilisierung (Tag 85-90)

• Go-Live-Runbook ausführen
• Delta-Datenmigration durchführen
• DNS umschalten
• 48 Stunden mit dem gesamten Team in Bereitschaft überwachen
• Allfällige Post-Go-Live-Probleme lösen

Was die Franke-Migration zum Erfolg gemacht hat

Rückblickend haben fünf Faktoren den 90-Tage-Zeitrahmen möglich gemacht:

1. Kompromissloses Scope-Management. Wir haben nicht alles migriert. Wir haben migriert, was das Geschäft brauchte. Die 35 % unnötiger Anpassungen blieben zurück.

2. Parallele Workstreams. Plattform, Daten, Integrationen und Frontend liefen parallel mit täglichen Sync-Punkten. Keine sequenziellen Übergaben.

3. Frühes Daten-Investment. Das Daten-Profiling begann vor dem Kickoff. An Tag 1 wussten wir genau, was wir migrieren und was wir zurücklassen.

4. Iterative Delivery mit wöchentlichen Demos. Stakeholder sahen jede Woche Fortschritte. Probleme kamen früh ans Licht. Kurskorrekturen passierten in Tagen, nicht Monaten.

5. Erfahrenes Team. Unser Team hatte das schon gemacht. Wir kannten die SAP Commerce Cloud-Plattform, die Migrationspatterns und die typischen Fallstricke. Diese Erfahrung komprimierte die Lernkurve auf nahezu null.

Die SAP Quality Award-Anerkennung

SAP zeichnete die Franke-Migration mit einem Quality Award aus — die Anerkennung für Projekte, die Exzellenz in Methodik, Stakeholder-Engagement und Delivery-Qualität zeigen. Für uns bestätigte es, dass Geschwindigkeit und Qualität keine Gegensätze sind. Eine fokussierte, gut geplante Migration liefert beides.

Ihre 90-Tage-Timeline beginnt mit Tag -30

Der Leitfaden funktioniert. Wir haben es bewiesen. Aber die 90-Tage-Uhr tickt erst, wenn die Vorbereitung abgeschlossen ist. Wenn Sie die EoMM-Deadline im Juli 2026 vor sich haben, ist die Rechnung einfach:

• 30 Tage Vorbereitung + 90 Tage Migration = 120 Tage insgesamt
• Für ein Go-Live bis Juli 2026 muss die Vorbereitung spätestens im März 2026 beginnen
• Für ein komfortables Go-Live mit Puffer starten Sie bis Januar 2026

Je später Sie beginnen, desto komprimierter wird der Zeitrahmen. Und komprimierte Zeitrahmen kosten mehr.

Starten Sie Ihr Migrations-Assessment

Wir prüfen Ihre SAP Hybris-Instanz, erfassen Ihre Anpassungen, profilieren Ihre Daten und erstellen einen realistischen 90-Tage-Plan, der auf Ihre spezifische Situation zugeschnitten ist. Keine generischen Vorlagen. Ein Plan, der auf realer Erfahrung aus dem Franke-Projekt und Dutzenden weiterer SAP Commerce-Migrationen basiert.

Kontaktieren Sie uns — lassen Sie uns Ihre EoMM-Deadline in eine 90-Tage-Erfolgsgeschichte verwandeln.