Migration von SAP Commerce Cloud (Hybris) zu Shopify Plus: Kosten, Zeitplan und was in SAP bleibt

Ihr Commerce-Team will schnellere Releases. Finance will SAP behalten. Operations will Belege, dass Vertragspreise, Kreditprüfungen und Lageraufträge weiter funktionieren. Diese Anforderungen passen zusammen, aber nur, wenn die Migration den Shop von den Geschäftsprozessen dahinter trennt.

Eine Migration von SAP Commerce Cloud zu Shopify Plus ersetzt die Commerce-Plattform, nicht unbedingt das SAP-ERP. Produkte, Kunden und ausgewählte Historie wandern in ein neues Commerce-Modell, während Preise, Bestand, Kredit und Fulfillment in SAP bleiben können. Die entscheidende Arbeit ist, diese Verbindungen neu zu bauen und vollständige Kaufwege vor dem Go-live zu belegen.

Dieser Leitfaden behandelt diese Grenze: wann Sie migrieren, was neu gebaut werden muss, wie Sie die Arbeit budgetieren und wie Sie die Plattform wechseln, ohne den Bestellprozess halb fertig zurückzulassen.

Sollten Sie von SAP Commerce Cloud zu Shopify Plus migrieren?

Migrieren Sie, wenn die aktuelle Commerce-Implementierung die Änderungen blockiert, die Ihr Unternehmen braucht, und Shopify Plus die geforderten Kaufwege zu akzeptablen Gesamtkosten tragen kann. Bleiben Sie, wenn SAP Commerce gut zu diesen Wegen passt oder wenn der Nachbau wesentlicher Regeln anderswo schwerer wiegt als der operative Nutzen eines Plattformwechsels.

Der stärkste Business Case beginnt mit Belegen aus Ihrem eigenen Betrieb. Messen Sie, wie lange eine Aktion, ein Produktlaunch oder ein Markteintritt dauert. Prüfen Sie Wartungskosten, Produktionsvorfälle, manuelle Bestellkorrekturen und den Entwicklungsaufwand für gewöhnliches Merchandising. Trennen Sie Plattformgrenzen von Verzögerungen durch Freigaben und schwacher Datenverantwortung.

Shopify Plus kann attraktiv sein, wenn das Team mehr Commerce-Arbeit über unterstützte Plattformkonfiguration, Themes und Apps erledigen will. Dieser Vorteil schrumpft, wenn jede Kundeninteraktion einen individuellen Dienst braucht, der die alte Implementierung nachbildet. Bewerten Sie das Ziel-Betriebsmodell, nicht nur eine Shop-Demo.

SAP Commerce bleibt eine glaubwürdige Option für komplexe Unternehmen. SAP beschreibt das aktuelle Produkt als geeignet für B2B, B2C, komplexe Kataloge und Composable-Storefronts. Ein Wechsel zu Shopify ist also nicht automatisch ein Schritt von einer veralteten, nicht-headless Plattform zu einer modernen. SAPs Überblick zu Commerce Cloud erklärt diese Funktionen und den Bezug zum historischen Namen Hybris.

Hybris und Commerce Cloud: die tatsächliche Quelle bestimmen

„Hybris-Migration“ kann eine ältere Implementierung meinen oder ein Team, das den historischen Namen für seine heutige Commerce-Landschaft weiterverwendet. Halten Sie die genaue Produktversion, das Deployment-Modell, die Shop-Technologie, individuelle Erweiterungen und Supportvereinbarungen fest, bevor Sie das Projekt schätzen.

Bauen Sie den Business Case nicht auf der pauschalen Behauptung auf, alle Hybris- oder SAP-Commerce-Umgebungen hätten ein gemeinsames Supportende. Lassen Sie den Wartungsstand für Ihre Version und Ihren Vertrag vom Account-Verantwortlichen bei SAP bestätigen. Das Supportrisiko kann den Zeitplan beeinflussen, beweist aber nicht, dass Shopify das richtige Ziel ist.

Wann Bleiben die bessere Entscheidung ist

Bleiben Sie oder verschieben Sie den Wechsel, wenn wesentliche Konfigurations-, Beschaffungs- oder Bestellprozesse auf der Zielplattform noch nicht abbildbar sind. Dasselbe gilt, wenn die aktuelle Plattform gut funktioniert und die geplante Migration nur ein ungelöstes Problem in ERP, Produktdaten oder Organisation verschiebt.

Der Freigabetest ist konkret: Welche wiederkehrenden Einschränkungen verschwinden, welche neuen Verantwortlichkeiten entstehen, und wer kann das Ergebnis betreiben? Ein glaubwürdiger Vorschlag beantwortet alle drei Fragen.

Was bleibt nach der Commerce-Migration in SAP?

SAP-ERP kann weiter für Finanzen, Beschaffung, Bestandsführung und operative Auftragsabwicklung verantwortlich sein, während Shopify Plus das Kauferlebnis und die Auftragserfassung übernimmt. Diese Aufteilung muss je Prozess und Datenobjekt vereinbart werden. SAP zu behalten, erhält bestehende Commerce-Integrationen nicht automatisch; Schnittstellen und ihre fachliche Bedeutung müssen weiterhin geprüft werden.

Shopify unterscheidet in seinem Leitfaden zur Cloud-ERP-Architektur die kundenseitige Rolle von Commerce von der finanziellen und operativen Rolle des ERP. Nutzen Sie diese Unterscheidung als Ausgangspunkt und prüfen Sie dann Ihre tatsächliche Implementierung. Eine Preisregel kann im ERP, in Commerce, in der Middleware oder in einem individuellen Dienst liegen.

Erstellen Sie eine Verantwortlichkeitsmatrix, bevor Sie entscheiden, welchen Connector Sie kaufen. Das Folgende ist ein vorgeschlagenes Designmuster, keine Beschreibung jeder SAP-Installation.

Die Zeile zu Produktinhalten verdient Aufmerksamkeit. Liefert Commerce heute Produktanreicherung an mehrere Kanäle, entfernt die Abschaltung mehr als einen Shop. Übertragen Sie diese Verantwortung an ein bestehendes PIM, an Shopify oder an einen anderen gesteuerten Ablauf, bevor Sie die Quelle abschalten.

Erfassen Sie Kennungen so sorgfältig wie Verantwortlichkeiten. SAP-Materialnummern, Kundenkonten sowie Auftraggeber- und Warenempfänger-Kennungen können sich von Produkt-, Firmen- und Standort-IDs in Shopify unterscheiden. Pflegen Sie ausdrückliche Querverweise. Eine E-Mail-Adresse allein ist keine verlässliche Zuordnung für ein Enterprise-Konto.

Ist auch eine ERP-Transformation geplant, vergleichen Sie die Reihenfolgen ausdrücklich. Commerce zuerst braucht eine Schnittstelle, die den späteren ERP-Wechsel übersteht. ERP zuerst verzögert die Vorteile des Shops. Eine gemeinsame Umstellung braucht eine gemeinsame Generalprobe und einen Wiederherstellungsplan. Entscheiden Sie nach Abhängigkeiten und Teamkapazität, nicht nach dem Wunsch, alles zugleich zu ersetzen.

Wie lassen sich SAP-Kataloge, Inhalte und individueller Code auf Shopify abbilden?

Migrieren Sie die Bedeutung des Katalogs vor seinem Volumen. SAP-Katalogversionen, Klassifizierungsmerkmale, verkaufbare Varianten und Content-Workflows brauchen ausdrückliche Zieldesigns. Produktdatensätze lassen sich umwandeln, doch Commerce-Erweiterungen und Shop-Komponenten sind keine übertragbare Shopify-Funktionalität. Ordnen Sie jedes geforderte Verhalten einer Standardkonfiguration, einer App, einem externen Dienst oder einer bewussten Prozessänderung zu.

SAP dokumentiert getrennte Kataloge und Katalogversionen, darunter eine Staged- und eine Online-Version. Eine Migration sollte beide nicht zu doppelten Live-Produkten zusammenfalten. Legen Sie den gewünschten veröffentlichten Stand fest und bestimmen Sie, wie freigegebene, aber unveröffentlichte Änderungen in den neuen Ablauf kommen.

Die ImpEx-Import- und Exportfunktion von SAP kann beim Export aus der Quelle helfen. Sie ist keine Shopify-Laufzeitumgebung und keine vollständige Migrationsspezifikation. Exporte brauchen weiterhin eine Reihenfolge der Abhängigkeiten, Transformationen, Medienverarbeitung, Validierung und eine vereinbarte Behandlung von Datensätzen, die nicht mitwandern sollen.

Testen Sie schwierige Produkte zuerst: konfigurierbare Artikel, mehrere Mengeneinheiten, Ersatzteile, lokalisierte Spezifikationen und Produkte mit vielen Variantenkombinationen. Shopify dokumentiert derzeit höchstens 2.048 Varianten und drei Optionen pro Produkt, mit Einschränkungen bei der Kompatibilität mit Themes, Apps und Kanälen. Diese Grenzen machen einen Produktkonfigurator nicht austauschbar mit gewöhnlichen Varianten. Die Shopify-Dokumentation zu Varianten nennt die aktuellen Details.

Trennen Sie eine Anweisung der Käuferin von einer verkaufbaren Identität. Einen Gravurtext können Sie als Zusatzinformation erfassen; eine Auswahl, die Preis, Bestand oder Fertigung verändert, braucht eine maßgebliche Verarbeitung, die über ein Textfeld hinausgeht.

Ist die Quelle headless, entscheiden Sie, ob sich die Anpassung des bestehenden Frontends lohnt. Das visuelle Design zu behalten, heißt nicht, die SAP-API-Verträge zu behalten. Ein Neubau auf Theme-Basis kann den Pflegeaufwand senken; ein individuelles Frontend kann bei besonderen Anforderungen an das Erlebnis gerechtfertigt sein. Keiner der beiden Wege erspart die Prüfung von Checkout und Backend in Shopify.

Kann Shopify Plus die B2B-Preis- und Einkaufsregeln von SAP abbilden?

Shopify Plus ist ein Kandidat für eine SAP-B2B-Migration, keine Garantie für identisches Verhalten. Prüfen Sie Firmenstrukturen, kundenspezifische Kataloge, Freigaben, Kreditkontrollen, Beschaffung und Preise getrennt. Die schwierigste Frage ist, ob der richtige Käufer die richtige Bestellung unter denselben kaufmännischen Einschränkungen aufgeben kann, auch wenn ein vorgelagertes System nicht erreichbar ist.

Das B2B-Organisationsmodell von SAP umfasst Einheiten und damit verbundene Strukturen wie Budgets und Kostenstellen. Gehen Sie nicht davon aus, dass sich ein Organisationsbaum direkt in Shopify-Firmen und -Standorte importieren lässt und dabei jede Rechte- und Freigabebeziehung erhalten bleibt.

Bauen Sie Tests um echte Einkaufsrollen: eine lokale Einkäuferin, einen regionalen Freigeber, einen zentralen Beschaffungsnutzer und ein Konto mit Kreditsperre. Beziehen Sie Käufer ein, die für mehrere Lieferadressen bestellen. Kennzeichnen Sie jede Anforderung als nativ, konfiguriert, extern durchgesetzt, neu gestaltet oder von der vorgeschlagenen Lösung nicht unterstützt.

Warum Plus und nicht ein Standardtarif von Shopify?

B2B allein ist keine ausreichende Begründung mehr. Die aktuelle Shopify-Dokumentation führt B2B-Grundfunktionen in Basic, Grow, Advanced und Plus. Plus-spezifische Unterschiede sind unter anderem unbegrenzte B2B-Marktkataloge, die direkte Zuordnung von Katalogen zu Firmen oder Standorten und erweiterte Zahlungsfunktionen. Gleichen Sie die B2B-Matrix je Tarif mit Ihren Anforderungen ab, statt sich auf ältere Vergleiche zu verlassen.

Auch Anforderungen an den Checkout können den Tarif bestimmen. Shopify dokumentiert, dass Apps, die die Seiten für Daten, Versand und Zahlung anpassen, sowie individuelle Apps mit Shopify Functions nur in Plus verfügbar sind. Das sind definierte Erweiterungspunkte, kein unbeschränkter Zugang, um SAP-Checkout-Code nachzubauen. Der Vergleich der Checkout-Apps von Shopify erklärt die Grenzen.

Die Transaktion belegen, nicht nur den angezeigten Preis

Nehmen wir einen fiktiven Distributor. Ein Käufer sieht einen Vertragspreis von 42 € pro Stück und fragt 200 Stück an. SAP hat 150 für dieses Konto verfügbar, und die Buchhaltung hat eine Kreditsperre gesetzt.

42 € auf der Produktseite anzuzeigen, belegt nur einen Teil des Weges. Die Zielplattform muss auch die freigegebene Menge zurückgeben, die Kreditsperre einhalten und keine falsche Zahlungs- oder Fulfillment-Anweisung weitergeben.

Legen Sie das zulässige Verhalten vorab fest: Bestellung ablehnen, zur Prüfung weiterleiten, eine Teilmenge anbieten oder einen anderen vereinbarten Weg. Ob sich dieses Verhalten im erforderlichen Schritt durchsetzen lässt, ist ein Test der Machbarkeit der Implementierung. Ein Hinweis im Shop oder eine spätere E-Mail setzt keine Checkout-Einschränkung durch.

Testen Sie Mengenstaffeln, auslaufende Verträge, Währung, steuerliche Behandlung, das Zusammenspiel mit Aktionen, Mindestmengen und Bestellschritte. Verfolgen Sie bei Punchout oder CPQ den gesamten Beschaffungsweg, einschließlich der Rückkehr ins Einkaufssystem und der maßgeblichen Bestellreferenz. Eine App im Angebot zu nennen, beweist nicht, dass der Weg funktioniert.

Wie sollte Shopify Plus an die verbleibenden SAP-Systeme angebunden werden?

Gestalten Sie jede Integration um ihren fachlichen Vertrag: wem die Daten gehören, wie schnell sie ankommen müssen, was sie identifiziert und was bei einer fehlgeschlagenen Zustellung passiert. Ein Connector liefert Transport und Mappings, entscheidet aber nicht über maßgebliche Preise, Auftragsannahme oder Wiederherstellung. Diese Entscheidungen gehören in den Umfang der Migration.

Erfassen Sie die bestehenden Schnittstellen, einschließlich geplanter Dateien und manueller Uploads. Stellen Sie fest, welche an Commerce-spezifischen Objekten hängen und welche wiederverwendbar sind. Prüfen Sie die vorhandene Middleware des Teams, bevor Sie eine weitere Integrationsplattform einführen, und rechnen Sie die Betriebskosten des gewählten Ansatzes ein.

Unterscheiden Sie replizierte Daten von Entscheidungen, die eine zeitnahe, maßgebliche Antwort brauchen. Periodisch veröffentlichte Beschreibungen vertragen eine andere Verzögerung als eine Kreditsperre. Eine Bestandsmenge ist nicht unbedingt ein Lieferversprechen. Eine erfolgreich übermittelte Bestellung ist nicht unbedingt ein angenommener Kundenauftrag.

Dokumentieren Sie für jeden Datenfluss:

• Quelle, Ziel und die fachlich verantwortliche Person für die Richtigkeit.

• Kennungen, Transformationsregeln, Schemaversionen und Umrechnung von Einheiten.

• Anforderungen an die Aktualität und das Verhalten bei veralteten oder nicht verfügbaren Daten.

• Erkennung von Duplikaten, Umgang mit Wiederholungen und einen sicheren Weg für fehlgeschlagene Datensätze.

• Abgleich, Verantwortung für Alarme und Anweisungen für die operative Wiederherstellung.

Shopify warnt, dass die Zustellung von Webhooks nicht immer garantiert ist, und empfiehlt Abgleichsjobs. Die Event-Verarbeitung sollte also einen Weg enthalten, fehlende Updates zu erkennen, nicht nur eine gelungene Webhook-Demo. Siehe die Hinweise von Shopify zu Webhooks.

Testen Sie Fehler bewusst. Geben Sie eine Bestellung auf, während SAP nicht erreichbar ist, wiederholen Sie eine bereits verarbeitete Nachricht und stellen Sie den Dienst nach einem Rückstau wieder her. Prüfen Sie, dass die Bestellung nicht doppelt entsteht, der Bestand nicht zweimal sinkt und die Kundenkommunikation den tatsächlichen Stand zeigt.

Gehen Sie nicht davon aus, dass sich beliebige Echtzeit-Aufrufe ans ERP überall im Checkout einfügen lassen. Belegen Sie die verfügbaren Erweiterungspunkte, Latenzgrenzen und das Ausweichverhalten mit der gewählten Implementierung. Lässt sich die geforderte Kontrolle nicht durchsetzen, gestalten Sie den Weg neu oder prüfen Sie die Eignung der Plattform erneut, bevor die vollständige Entwicklung beginnt.

Welche Daten sollten migriert werden, und was sollte anderswo zugänglich bleiben?

Übernehmen Sie die Daten, die zum Verkaufen, zur Kundenbetreuung und zum Betrieb der neuen Plattform nötig sind. Bewahren Sie andere Datensätze in einem vereinbarten Archiv oder Quellsystem auf, wenn ihr Import operativ nichts bringt. Produkte, Kundenprofile, B2B-Beziehungen, offene Transaktionen und historische Bestellungen brauchen unterschiedliche Migrationsmethoden, Prüfregeln und Entscheidungen zur Verantwortung.

Legen Sie getrennte Vorgehensweisen fest für aktive Produkte, ausgelaufene Produkte mit Suchnachfrage, aktive Konten, inaktive Konten, historische Bestellungen, offene Bestellungen, Retouren, Gutschriften und offene Angebote. Ein einziges Versprechen zu „allen Daten“ verdeckt diese Unterschiede.

Eine importierte historische Bestellung beweist nicht, dass ihr Lebenszyklus aus Zahlung, Fulfillment oder Erstattung in Shopify weiterlaufen kann. Legen Sie fest, wo Retouren aus der Zeit vor dem Go-live bearbeitet werden und welcher Zahlungsanbieter die ursprüngliche Transaktion erstatten kann. Halten Sie Bestellreferenzen aus der Quelle für den Kundenservice sichtbar und gleichen Sie Summen mit dem operativen Quellsystem ab.

Die Kundenidentität braucht einen eigenen Plan. Shopify erklärt ausdrücklich, dass sich Passwörter nicht per Kunden-CSV aus einem anderen Shop übernehmen lassen. Wählen und testen Sie das geplante Anmeldeerlebnis, die Zuordnung von Konten und die Kundenkommunikation. Versprechen Sie keine durchgehenden Passwörter allein auf Basis eines Profilimports. Die Shopify-Dokumentation zum Kundenimport beschreibt diese Grenze.

Klären Sie bei gespeicherten Zahlungsmitteln oder Abos den unterstützten Übertragungsweg mit dem Zahlungsanbieter und der Ziel-App, bevor Sie Kontinuität zusagen. Ein Kundendatensatz enthält kein übertragbares Zahlungsmittel.

Führen Sie vor dem endgültigen Import mindestens eine repräsentative Generalprobe durch. Vergleichen Sie Datensatzzahlen, Pflichtfelder, Beziehungen und, wo relevant, finanzielle Summen. Führen Sie ein Ausnahmenregister mit benannter Verantwortung und Lösung, statt eine Erfolgsquote zu akzeptieren, die die schwierigsten Konten ungelöst lässt.

Was kostet eine Migration von SAP Commerce Cloud zu Shopify Plus?

Die Kosten ergeben sich aus der Funktionalität, die ersetzt wird, den Schnittstellen, die neu gebaut werden, und den Nachweisen, die vor dem Go-live nötig sind. Schätzen Sie Discovery, Shop-Arbeit, Datentransformation, SAP-Integration, B2B-Verhalten, Tests und Übergabe getrennt. Vergleichen Sie das daraus entstehende Implementierungsbudget mit den laufenden Kosten für Plattform, Apps, Integrationen und Support, nicht nur mit den Abogebühren.

Einen belastbaren Einheitspreis für „Hybris zu Shopify“ gibt es nicht. Ein vorwiegend D2C-orientierter Shop mit einem stabilen, bleibenden ERP ist ein anderes Projekt als eine B2B-Landschaft mit mehreren Gesellschaften, live Vertragspreisen und Beschaffungsintegrationen.

Das Folgende ist ein Budgetierungsbeispiel, kein Marktvergleich, keine Preisliste von Flatline und kein Angebot. Gehen Sie von einem Shop aus, einem bleibenden ERP, einem abgegrenzten Katalog, einem festgelegten B2B-Umfang und keinem gleichzeitigen ERP-Wechsel.

Bei einem angenommenen Mischsatz von 120 € pro Stunde ergibt dieses Modell 120.000 € bis 216.000 € an Umsetzungsaufwand. Mit einem Beispielpuffer von 15 % ergeben sich 138.000 € bis 248.400 €. Ersetzen Sie Stunden und Satz durch abgegrenzte Schätzungen von Anbietern; die Rechnung ist nützlich, sagt aber nichts über den wahrscheinlichen Preis Ihres Projekts.

Das Beispiel enthält keine Abos, Transaktions- und Zahlungsgebühren, Steuern, interne Arbeitszeit, Änderungen an ERP-Lizenzen, laufenden Support und keinen längeren Parallelbetrieb. Auch eine neue CPQ-Implementierung, ein eigenes Headless-Frontend und weitere Shop-Rollouts sind nicht enthalten. Jeder dieser Punkte kann das Budget deutlich verändern.

Vergleichen Sie für den Business Case die Kosten über drei Jahre bei gleichem Umfang: Implementierung, überlappende Verträge, Shopify, Apps, Middleware, Monitoring, Support und die verbleibenden SAP-Leistungen. Ziehen Sie nur SAP-Kosten ab, die wirklich wegfallen können. Bleibt Commerce als Abhängigkeit für Produktinhalte oder Integrationen aktiv, entfallen manche erwarteten Einsparungen. Flatlines Leitfaden zu den Gesamtbetriebskosten im E-Commerce bietet den breiteren Kostenrahmen.

Wie viel Zeit sollten Sie für die Migration einplanen?

Bauen Sie den Zeitplan aus dem Abschluss von Abhängigkeiten auf, nicht nur aus der Zahl der Produkte. Zugang zur Quelle, Bereitschaft der SAP-Schnittstellen, Machbarkeit von B2B, Datenqualität und fachliche Freigabe können das Go-live-Datum bestimmen. Eine Kalenderschätzung wird erst glaubwürdig, wenn jede Phase eine verantwortliche Person, verfügbare Beteiligte und messbare Abschlusskriterien hat, die die nächste Phase freigeben.

Zur Veranschaulichung: Das oben abgegrenzte Projekt ließe sich über 24 Wochen planen. Das ist ein Planungsbeispiel, keine typische Dauer und keine Lieferzusage. Aufwandsbudget und Laufzeit messen Verschiedenes: Mehrere Fachleute können parallel arbeiten, während Zugänge, Reviews und Freigaben Wartezeit erzeugen.

Arbeit kann sich überlappen, sobald die Abhängigkeiten stabil sind. Sie sollte sich nicht überlappen, indem man annimmt, dass ungelöste Preisregeln oder nicht verfügbare SAP-Endpunkte irgendwie bereit sind, wenn die Tests beginnen.

Ein schrittweiser Rollout kann den Umfang des ersten Releases verkleinern, doch wählen Sie eine Marke, einen Markt oder eine Kundengruppe, die sich wirklich abtrennen lässt. Kanäle zu trennen, die Verträge, Bestandszuteilung und Serviceteams teilen, kann mehr Komplexität erzeugen, als es beseitigt.

Nehmen Sie kaufmännische Fristen in denselben Plan auf: Verlängerungs- und Kündigungstermine bei SAP, Verkaufsspitzen, Lagerstopps und die Verfügbarkeit von ERP-Fachleuten. Ein technisch fertiger Shop kann nicht sicher live gehen ohne die Menschen, die seine Backend-Prozesse prüfen und wiederherstellen können.

Wie schützen Sie SEO und behalten die Umstellung im Griff?

Sichern Sie die Migration ab, indem Sie Auffindbarkeit und Kontinuität der Transaktionen gleichermaßen testen. Erfassen Sie wertvolle URLs, erhalten Sie nützliche Inhalte, prüfen Sie Weiterleitungen und beobachten Sie die Indexierung. Proben Sie getrennt davon das letzte Datendelta, die Übergabe der Schnittstellen, den Abgleich der Bestellungen und die Entscheidung zur Wiederherstellung. Eine funktionierende Startseite ist kein ausreichender Beleg, dass der neue Commerce-Betrieb Bestellungen annehmen kann.

Bauen Sie die URL-Liste aus Crawls, Sitemaps, Analysen, der Search Console und verlinkten Altseiten auf. Beziehen Sie Produktseiten, Kategorien, lokalisierte Seiten, redaktionelle Inhalte und wertvolle Dokumente ein. Ordnen Sie jeder wichtigen Quell-URL das passendste Ziel zu, statt alles auf die Startseite zu leiten.

Prüfen Sie Weiterleitungen, interne Links, Canonicals, Sprachannotationen, strukturierte Daten und Indexierbarkeit auf der gerenderten Zielplattform. Erhalten Sie Inhalte, die Produktsuche und Kaufentscheidungen unterstützen. Google weist darauf hin, dass ein Website-Umzug zu schwankenden Rankings führen kann, während URLs neu gecrawlt und indexiert werden; kein Migrationsplan kann unveränderte Rankings garantieren. Folgen Sie den Hinweisen von Google zum Website-Umzug.

Die Übergabe als Ereignis der Auftragsabwicklung proben

Legen Sie den letzten maßgeblichen Schreibvorgang in der Quelle fest, das Zeitfenster des letzten Exports und den Moment, ab dem neue Bestellungen in Shopify eingehen. Gleichen Sie späte Bestellungen und Updates ab, statt anzunehmen, dass ein Content-Freeze alle Transaktionen stoppt.

Verhindern Sie, dass alte und neue Integrationen dieselbe Bestellung oder Bestandsbuchung zweimal verarbeiten. Klären Sie, welches System offene Warenkörbe, Angebote, Bestellungen aus der Zeit vor dem Go-live und Retouren bearbeitet. Testen Sie die genaue Go-live-Reihenfolge in der Generalprobe, einschließlich Kundennachrichten und unterdrückter doppelter Benachrichtigungen.

Objektive Go/No-Go-Kriterien festlegen

Vereinbaren Sie Freigabeschranken, bevor der Druck des Go-lives steigt:

• Kritische Kaufszenarien bestehen, einschließlich gesperrter Konten und Integrationsausfällen.

• Die Zuordnungen von Produkten, Kunden und Bestellungen stimmen nach vereinbarten Abnahmekriterien.

• Die Verantwortung für Zahlung, Auftragsannahme, Fulfillment und Erstattung ist ausdrücklich geregelt.

• Wertvolle URLs lösen korrekt auf, und die Live-Website ist wie vorgesehen crawlbar.

• Monitoring, Zugang für die Wiederherstellung und benannte fachliche Entscheider sind verfügbar.

Ein Rollback ist nicht einfach das Zurückstellen eines DNS-Eintrags. Hat Shopify einmal Bestellungen angenommen, Zahlungen eingezogen oder Lageraktivität ausgelöst, muss der Wiederherstellungsplan diese Transaktionen berücksichtigen. Legen Sie das Entscheidungsfenster für ein Rollback fest, die verantwortliche Person und wann eine Reparatur nach vorn sicherer ist als der Rückweg.

Halten Sie die alte Umgebung nur für den vereinbarten Wiederherstellungs- und Zugriffsbedarf bereit, mit kontrollierten Schreibrechten. Schalten Sie sie ab, sobald Abhängigkeiten, aufbewahrte Datensätze und Supportprozesse freigegeben sind. Sonst zahlt die Organisation womöglich auf Dauer für zwei Commerce-Plattformen.

Bleibt SAP als ERP bestehen, ist die eigentliche Frage vielleicht, ob die Commerce-Schicht überhaupt ersetzt werden muss. Wenn Sie noch zwischen Plattformwechsel, Neuaufbau und Bleiben entscheiden, beginnen Sie dort; ist Shopify Plus die Antwort, plant unsere Shopify-Migration SAP-Schnittstellen, B2B-Preise und Go-live als ein Programm.

Häufig gestellte Fragen

Können wir SAP S/4HANA oder SAP ECC beim Wechsel zu Shopify Plus behalten?

Ja. SAP Commerce zu ersetzen, erfordert nicht automatisch, auch SAP-ERP zu ersetzen. Das bleibende ERP kann weiter die finanziellen und operativen Prozesse verantworten, während Shopify den Commerce übernimmt. Prüfen Sie aber die genaue ERP-Version, verfügbare Schnittstellen, Middleware und Supportvereinbarungen. Bestehende Commerce-Integrationen müssen überprüft werden; das ERP zu behalten, lässt die Verbindungen nicht unverändert.

Kann eine Migrations-App die gesamte Hybris-Implementierung übertragen?

Nein. Ein Migrationswerkzeug kann beim Übertragen unterstützter Datensätze helfen, doch eine ganze Implementierung enthält auch Geschäftsregeln, individuelle Erweiterungen, Content-Workflows und Integrationsverhalten. Diese brauchen Bewertung und Zieldesigns. Beurteilen Sie ein Werkzeug nach den Entitäten, Beziehungen, Transformationen, Wiederholungen und Prüfungen, die es unterstützt, nicht nach dem Versprechen, alles automatisch zu übertragen.

Müssen wir das Website-Design neu bauen?

Die Implementierung muss neu gebaut oder angepasst werden, die visuelle Identität muss sich aber nicht ändern. Bestehende Designassets und freigegebene Inhalte können die Grundlage des neuen Shops bilden. SAP-spezifische Templates, Komponenten und API-Verbindungen funktionieren nicht selbstverständlich auf Shopify. Trennen Sie bei der Schätzung von Kosten und Zeit notwendige technische Anpassung von einem optionalen Redesign.

Können wir zuerst D2C starten und B2B später migrieren?

Ja, wenn sich die Kanäle operativ trennen lassen. Prüfen Sie gemeinsame Kundendatensätze, Verträge, Bestandszuteilung, Auftragsrouting und Serviceprozesse, bevor Sie diese Reihenfolge wählen. Legen Sie vorübergehende Regeln für Verantwortlichkeiten fest und die Kosten für den Betrieb beider Plattformen. Ein schrittweiser Start ist nützlich, wenn er Abhängigkeiten verringert, nicht nur, wenn er das Projekt in Termine aufteilt.

Senkt ein Wechsel zu Shopify Plus automatisch die Betriebskosten?

Nein. Einsparungen hängen davon ab, welche Lizenzen, Umgebungen und Wartungspflichten tatsächlich wegfallen und welche neuen Kosten an ihre Stelle treten. Beziehen Sie Apps, Integrationssupport, internen Aufwand und überlappende Verträge in den Vergleich ein. Viel individuelles Verhalten beizubehalten oder SAP Commerce für andere Aufgaben aktiv zu lassen, kann den erwarteten finanziellen Nutzen schmälern.

Das Wichtigste in Kürze

• Ersetzen Sie SAP Commerce erst, wenn belegt ist, dass Shopify die geschäftskritischen Kaufwege unterstützt.

• Legen Sie fest, was in SAP bleibt, einschließlich maßgeblicher Preise, Kreditkontrolle und Auftragsannahme.

• Behandeln Sie Katalogversionen, B2B-Beziehungen und individuelles Verhalten als Designarbeit, nicht als einfache Exporte.

• Schätzen Sie Kosten und Zeitplan aus abgegrenzten Abhängigkeiten, mit ausdrücklichen Annahmen und Ausschlüssen.

• Gehen Sie erst live, wenn Daten, SEO, Transaktionen und Wiederherstellungsabläufe ihre Freigabeschranken bestanden haben.

Möchten Sie Unterstützung beim Abgrenzen des Umfangs auf der Commerce-Seite, sprechen Sie mit dem Shopify-Plus-Team von Flatline. Bringen Sie die aktuelle Architektur, die schwierigen Kaufszenarien und die Rahmenbedingungen des SAP-Teams mit, damit das Gespräch bei Eignung, Verantwortung und einem prüfbaren Migrationsplan beginnt.