Von SAP Hybris zur Commerce Cloud in 90 Tagen: ein Migrations-Playbook

90 Tage vom Kickoff bis zum Go-live sind für ein SAP-Commerce-Projekt schnell. Die meisten Unternehmen planen für den Weg von SAP Hybris zu SAP Commerce Cloud acht bis zwölf Monate, und für grosse, stark angepasste Plattformen ist das auch richtig. Für eine mittelgrosse Plattform mit vorbereitetem Team und fixiertem Scope sind 90 Tage machbar. Dieser Beitrag beschreibt die Methode, mit der wir das angehen: was vor dem Start der Uhr passiert, was jeder Sprint liefert und was wir bewusst weglassen.

Das Tempo kennen wir aus eigener Arbeit. Bei Franke haben wir die SAP-Commerce-Cloud-Plattform in 90 Tagen live gebracht; die Angabe bezieht sich auf den Commerce-Launch, Teil einer längeren Partnerschaft, in der wir eine Altplattform durch eine Headless-Architektur ersetzt haben. Das Projekt erhielt den SAP Quality Award für «Rapid Time to Value» (Franke-Erfolgsgeschichte).

Kurzfassung: Eine mittelgrosse SAP-Hybris-Plattform kann in 90 Tagen in SAP Commerce Cloud ankommen, wenn 30 Tage Vorbereitung vorausgehen: Plattform-Audit, Datenprofiling, Umgebungen, Teamabstimmung. Dann folgen drei Sprints: Kernplattform und erster Datenload (Tage 1 bis 21), Integrationen und Frontend (Tage 22 bis 50), Performance, Abnahme, Generalprobe und Go-live (Tage 51 bis 90). Tragend sind Scope-Disziplin, parallele Arbeitsstränge und wöchentliche Demos. Seit die Mainstream-Wartung für On-Premise am 31. Juli 2026 geendet hat, ist derselbe Plan der schnellste Weg hinaus.

Lieber einen Partner als eine Anleitung zum Selbermachen? Spadoom ist SAP Gold Partner für Cloud ERP und Customer Experience und setzt SAP Commerce Cloud in der Schweiz, in Deutschland, Österreich und Italien um, sowohl die Cloud Edition als auch die ERP Edition für S/4HANA Public Cloud. Scoping-Gespräch anfragen.

Warum sind 90 Tage machbar?

Nach unserer Erfahrung werden lange Migrationszeitpläne eher durch Leerlauf aufgebläht als durch Komplexität. Eine 90-Tage-Migration kürzt nichts ab; sie entfernt drei Dinge, die Zeit kosten, ohne Wert zu schaffen.

Analyse-Lähmung. Teams verbringen Monate damit, Anforderungen zu dokumentieren, die im laufenden System längst existieren. Die aktuelle Plattform ist die beste Spezifikation, die Sie haben; lesen Sie sie, statt sie neu zu schreiben.

Eins-zu-eins-Nachbau von Anpassungen, die niemand braucht. Ein Workaround aus dem Jahr 2017 gehört nicht auf die neue Plattform, nur weil er auf der alten existiert.

Sequenzielle Phasen mit Übergabeverzögerungen. Jede Freigabe, Übergabe und jeder Kontextwechsel zwischen Teams kostet Tage, oft eine Woche.

Fallen diese drei weg, passt die eigentliche Arbeit (Datenmigration, Plattformkonfiguration, Neuanbindung der Integrationen, Tests) für eine mittelgrosse Commerce-Plattform in 90 Tage. Bei grösseren Plattformen verkürzt dieselbe Methode das Projekt ebenfalls, nur nicht auf 90 Tage; unsere Migrations-Checkliste zeigt die typischen Spannen je Szenario.

Was passiert, bevor die Uhr läuft? (Wochen -4 bis 0)

Die 90-Tage-Uhr startet mit dem Kickoff. Die 30 Tage davor entscheiden, ob das Projekt ein kontrollierter Sprint wird oder ein Gerangel.

Plattform-Audit (Wochen -4 bis -3)

Wir erfassen alles in der bestehenden SAP-Hybris-Instanz:

• Eigene Extensions: zählen, einordnen (weiterhin nötig, ersetzbar, obsolet) und den Aufwand je Extension schätzen.
• Datenmodelle: eigene Typen, Relationen und Attribute, und welche davon direkt auf Commerce Cloud passen.
• Integrationen: jede ein- und ausgehende Verbindung (ERP, PIM, CRM, Zahlung, Versand, Steuern) mit Protokoll, Format und Frequenz.
• Anpassungs-Hotspots: der kleine Teil des eigenen Codes, der den Grossteil der Geschäftslogik trägt.

Das Audit zeigt regelmässig, dass ein Teil der Extensions Workarounds für On-Premise-Grenzen waren, die Commerce Cloud im Standard abdeckt. Diese fallen sofort aus dem Scope, und jede davon ist Code, den Sie nicht migrieren, testen und warten müssen. Die fünf häufigsten Fehler bei der Migration beginnen genau dort, wo dieses Audit übersprungen wird.

Datenprofiling (Wochen -3 bis -2)

Bevor jemand die Migrationswerkzeuge anfasst, müssen die Daten verstanden sein. Profilieren Sie jede Entität auf Vollständigkeit, Konsistenz und Qualität. Finden Sie Dubletten, verwaiste Datensätze und Daten, die seit Jahren niemand angefasst hat. Bauen und testen Sie die Extraktions- und Ladepipeline mit einer kleinen Stichprobe. Probleme, die hier auffallen, kosten Stunden; in Sprint 3 kosten sie Wochen.

Umgebungen aufsetzen (Wochen -2 bis -1)

Stellen Sie die SAP-Commerce-Cloud-Umgebungen bereit (Entwicklung, Staging, Produktion), konfigurieren Sie die Build- und Deployment-Pipelines im Cloud Portal, richten Sie Monitoring und Alerting ein und geben Sie allen Zugang. Unspektakuläre Arbeit, und alles davon notwendig. Die Dokumentation zu SAP Commerce Cloud beschreibt Umgebungs- und Deployment-Modell im Detail.

Teamabstimmung (Woche -1)

Backlog finalisieren. Jedem Arbeitsstrang (Plattform, Daten, Integrationen, Frontend, Test) eine klare Verantwortung geben. Die Definition of Done je Inkrement vereinbaren, tägliche Stand-ups und wöchentliche Stakeholder-Demos aufsetzen, damit am ersten Tag alle wissen, woran sie arbeiten.

Was wird in Sprint 1 erledigt? (Tage 1 bis 21)

Die ersten drei Wochen bringen die Kernplattform mit Ihren Datenmodellen und der Grundkonfiguration auf Commerce Cloud.

• Migration des Datenmodells: eigene Typen, Enums und Relationen, gegen das Audit validiert.
• Zentrale Geschäftslogik: die im Audit identifizierten kritischen Anpassungen, etwa Warenkorbberechnung, Preisregeln, Promotionen und Steuerberechnung.
• Basis-Storefront: der SAP Composable Storefront mit Ihrem Produktkatalog. Noch kein eigenes Styling; funktionale Korrektheit zuerst.
• Erster Datenload: eine vollständige Migration nach Staging, mit validierten Datensatzzahlen, Datenintegrität und zentralen Geschäftsabläufen.

Was in Sprint 1 nicht passiert: visuelle Verfeinerungen, nicht kritische Integrationen (Analytics, Bewertungen, Loyalty), Performance-Tuning und Logik für Sonderfälle. Genau dieses Nein hält den Sprint im Zeitplan.

Meilenstein an Tag 21: ein funktionierender Storefront auf Commerce-Cloud-Staging mit echten Daten, zentraler Geschäftslogik und einfachem Checkout. Stakeholder können Produkte durchsuchen, in den Warenkorb legen und bestellen. Es sieht noch nicht fertig aus, aber es funktioniert.

Wie kommen die Integrationen in Sprint 2 zusammen? (Tage 22 bis 50)

Ist die Kernplattform bewiesen, verbindet Sprint 2 das Ökosystem neu, in der Reihenfolge der geschäftlichen Bedeutung:

1. ERP und Auftragsverwaltung: Auftragsexport, Bestandsabgleich, Preisaktualisierungen
2. Zahlungsanbieter: Anbindung des Payment Gateways über die Zahlungsintegration von Commerce Cloud
3. Versand und Logistik: Frachtberechnung, Etiketten, Sendungsverfolgung
4. PIM und Inhalte: Produktdaten-Feeds, Mediensynchronisation
5. CRM und CDP: Synchronisation der Kundendaten

Für jede Integration: bestehenden API-Vertrag validieren, Endpunkte und Authentifizierung aktualisieren, End-to-End-Tests mit echten Daten fahren und Verhaltensunterschiede dokumentieren.

Parallel setzt das Frontend-Team das Branding um, baut eigene UI-Komponenten, optimiert für Mobilgeräte und kümmert sich um SEO: Metadaten, strukturierte Daten und Redirects von den alten URLs.

Meilenstein an Tag 50: ein vollständig integriertes Commerce-Cloud-Deployment mit allen kritischen Integrationen, einem markenkonformen Frontend und einem durchgängigen Auftragsfluss vom Stöbern bis zur Auslieferung.

Was macht Sprint 3 anders? (Tage 51 bis 90)

In der letzten Phase geht es um Vertrauen. Das System funktioniert; jetzt beweisen Sie, dass es produktionsreif ist.

Performancetests (Tage 51 bis 60). Lasttests mit realistischen Verkehrsmustern und einer Simulation des Spitzentags. Engpässe finden und beheben, Auto-Scaling validieren, Ladezeiten mit den Zielwerten vergleichen.

Abnahmetests (Tage 55 bis 70). Fachanwender testen jeden kritischen Ablauf mit echten Kundenkonten und Produktdaten, dazu alle Integrationen unter realistischen Bedingungen. Alle P1- und P2-Fehler werden behoben.

Generalprobe der Datenmigration (Tage 65 bis 75). Die ganze Pipeline Ende zu Ende durchlaufen lassen und die Dauer messen, die Ihr Cutover-Fenster bestimmt. Die Delta-Migration für Daten zwischen Generalprobe und Go-live validieren und das Rollback-Verfahren testen. Dieser Schritt ist nicht optional.

Go-live und Stabilisierung (Tage 85 bis 90). Runbook ausführen: Delta-Migration, DNS-Umstellung, danach 48 Stunden Monitoring mit dem ganzen Team in Bereitschaft.

Was hält einen 90-Tage-Zeitplan?

Im Rückblick auf unsere schnellsten Commerce-Launches, Franke eingeschlossen, haben fünf Faktoren den Unterschied gemacht.

Scope-Disziplin. Wir migrieren, was das Geschäft braucht, nicht alles, was existiert. Obsolete Anpassungen bleiben zurück, ohne Nostalgie.

Parallele Arbeitsstränge. Plattform, Daten, Integrationen und Frontend laufen parallel mit täglichen Abstimmungspunkten. Ist ein Team blockiert, arbeiten die anderen weiter.

Frühe Investition in die Daten. Das Profiling beginnt vor dem Kickoff, sodass am ersten Tag alle wissen, was migriert wird und was zurückbleibt.

Iterative Lieferung mit wöchentlichen Demos. Stakeholder sehen jede Woche Fortschritt, Probleme zeigen sich früh, und Kurskorrekturen dauern Tage statt Monate.

Ein erfahrenes Team. Wer das schon gemacht hat, erkennt Muster und Stolpersteine früh. Diese Erfahrung spart mehr Zeit als jedes Werkzeug.

Tempo und Qualität sind keine Gegensätze. Bei Franke wurde der SAP Quality Award für «Rapid Time to Value» vergeben, und genau das sagt er aus.

Die EoMM-Frist ist schon vorbei?

Die Mainstream-Wartung für SAP Commerce On-Premise endete am 31. Juli 2026 (SAP Help Portal). Wenn Sie noch On-Premise sind, laufen Sie jetzt auf kundenspezifischer Wartung: keine regulären Sicherheitspatches, keine gesetzlichen Updates, individuell bepreister Support. Was das im Detail bedeutet und welche Übergangsmassnahmen sinnvoll sind, steht in SAP Commerce On-Premise: Der Support ist zu Ende, was jetzt?.

Die Rechnung des Playbooks bleibt dieselbe: 30 Tage Vorbereitung plus 90 Tage Migration ergeben rund 120 Tage. Geändert hat sich, dass jeder dieser Tage jetzt ausserhalb der Mainstream-Wartung läuft. Das ist ein Grund, die Vorbereitung jetzt zu beginnen, statt auf den perfekten Moment zu warten, und den Scope so eng zu halten, wie das Playbook es verlangt. Ist Ihre Plattform für 90 Tage zu gross, teilen Sie sie in Wellen, damit die ersten Märkte das On-Premise-System früh verlassen.

Einen breiteren Blick darauf, was SAP Commerce Cloud heute leistet, bietet unsere Seite zu SAP Commerce Cloud. Wenn Sie noch einen Implementierungspartner suchen, nennt unsere Übersicht über die besten SAP-Commerce-Cloud-Partner in der Schweiz die Kriterien, die zählen.

---

Wir prüfen Ihre SAP-Hybris-Instanz, erfassen Ihre Anpassungen, profilieren Ihre Daten und erstellen einen realistischen Migrationsplan, 90 Tage, wo der Scope es zulässt. Nehmen Sie Kontakt auf.

Häufig gestellte Fragen

Sind 90 Tage für jede SAP-Commerce-Migration realistisch?

Nein. 90 Tage funktionieren für mittelgrosse Commerce-Plattformen mit sauberer Vorbereitung und fixiertem Scope. Vorhaben mit mehreren Storefronts, viel Integrationsarbeit oder grossen Datenmengen brauchen meist vier bis sechs Monate oder mehr. Entscheidend ist, wie viel unnötige Anpassung und technische Schuld die Plattform mitschleppt.

Was ist das grösste Risiko einer 90-Tage-Migration?

Die Datenmigration. Deshalb beginnt das Datenprofiling in der Vorbereitungsphase, bevor die 90-Tage-Uhr läuft. Am ersten Tag von Sprint 1 kennen Sie Datenvolumen, Qualitätsprobleme und Transformationsregeln, und die Generalprobe in Sprint 3 validiert die ganze Pipeline vor dem Go-live.

Wie viele Personen braucht eine 90-Tage-Migration?

Typisch ist ein schlankes Team: einige Spadoom-Beraterinnen und -Berater für SAP Commerce, Frontend und Integration, dazu Product Owner, Business Analyst und IT-Verbindungsperson auf Kundenseite. Parallele Arbeitsstränge mit klarer Verantwortung zählen mehr als die Kopfzahl; ein grösseres Team mit sequenziellen Übergaben ist meist langsamer.

Was passiert mit der SEO bei der Migration von Hybris zu Commerce Cloud?

URL-Änderungen brauchen einen vollständigen Redirect-Plan: alle alten URLs zuordnen, 301-Redirects umsetzen, Metadaten und strukturierte Daten übernehmen und die neue Sitemap einreichen. Sind die Redirects vollständig, erholt sich der organische Traffic meist innerhalb weniger Wochen. Überwachen Sie die Search Console im ersten Monat täglich und beheben Sie 404-Fehler am selben Tag.

Können die alte Hybris-Plattform und Commerce Cloud parallel laufen?

Ja, und wir empfehlen es. Die alte Plattform bedient weiter den Produktionstraffic, während Abnahme- und Performancetests auf Commerce Cloud laufen. Das Cutover-Fenster für Delta-Migration und DNS-Umstellung dauert typischerweise einige Stunden. Ein Zurückstellen des DNS ist nur dann ein sauberer Rollback, wenn Aufträge, die nach dem Cutover auf der neuen Plattform eingingen, ins alte System nachgespielt werden; planen Sie diesen Schritt im Runbook ein.