5 Fehler, die Unternehmen bei der SAP Commerce Migration machen

Wir haben SAP-Commerce-Plattformen für Franke, ANWR und Distrelec migriert. Jedes einzelne Projekt hat uns etwas gelehrt. Aber die wertvollsten Lektionen kamen von den Fehlern, die wir Kunden ersparen konnten (oder aus denen wir sie herausholen mussten, wenn sie schon hineingetreten waren).

83 % der Datenmigrationsprojekte scheitern oder überschreiten Budget und Zeitplan (Bloor Group, 2023). SAP-Commerce-Migrationen sind keine Ausnahme. Die fünf Fehler unten erklären, warum die meisten dieser Projekte aus dem Ruder laufen.

TL;DR: 83 % der Datenmigrationen sprengen ihr Budget (Bloor Group, 2023). Aus unseren SAP-Commerce-Projekten mit Franke, ANWR und Distrelec sind die fünf häufigsten Fehler: On-Prem-Anpassungen 1:1 replizieren, die Datenmigration unterschätzen, technische Schulden ignorieren, Wasserfall-Lieferung wählen und zu spät starten. Agile Ansätze zeigen 42 % Erfolgsquote gegenüber 13 % bei Wasserfall (Standish Group, 2020). Früh starten, zuerst aufräumen, iterativ liefern.

Warum replizieren Unternehmen On-Prem-Anpassungen 1:1?

90 % der Unternehmen, die ihre E-Commerce-Plattform migriert haben, berichteten von Umsatz- und Ertragsverbesserungen (commercetools, 2024). Aber der teuerste Einzelfehler ist der Versuch, alles unverändert mitzunehmen.

Unternehmen bauen über Jahre Custom-Funktionalität auf ihrer On-Prem-Plattform auf. Kommt die Migration, ist der Instinkt: alles so übernehmen, wie es ist. Ich verstehe das. Sie haben das alles aus einem Grund gebaut. Aber der Punkt ist: Viele dieser Anpassungen waren Workarounds für On-Prem-Einschränkungen, die Commerce Cloud längst gelöst hat. Custom Caching Layer, manuelle Skalierungsskripte, eigene Deployment-Pipelines. Commerce Cloud beherrscht das alles nativ.

Wir haben Migrationen erlebt, bei denen 30 bis 40 % des Custom Codes auf der Zielplattform unnötig war. Jede Zeile dieses unnötigen Codes erhöht die Migrationszeit, den Testaufwand und die künftigen Wartungskosten.

Was Sie stattdessen tun sollten: Bevor Sie eine einzige Zeile Code migrieren, auditieren Sie jede Anpassung. Klassifizieren Sie jede: noch benötigt, durch Plattformfähigkeit ersetzbar oder obsolet. Wir führen ein strukturiertes Assessment durch, das typischerweise 25 bis 35 % der Anpassungen als entfernbar identifiziert. Das reduziert direkt Kosten und Zeitrahmen.

Wie bringt die Datenmigration Zeitpläne zum Entgleisen?

83 % der Datenmigrationsprojekte scheitern oder überschreiten Budget und Zeitplan (Bloor Group, 2023). Auf dem Papier sieht Datenmigration einfach aus: aus der Quelle exportieren, transformieren, ins Ziel importieren. In der Praxis ist es die Phase, die die meisten Zeitpläne zum Entgleisen bringt. Ich habe es öfter miterlebt, als ich zählen kann.

Die Probleme beginnen bei der Datenqualität. On-Prem-Systeme sammeln über Jahre inkonsistente Daten an. Doppelte Kundendatensätze. Verwaiste Produktreferenzen. Bestellungen mit fehlenden Attributen. Katalogstrukturen, die ohne Bereinigung gewuchert sind. Eine begutachtete Studie fand, dass 94 % der Geschäfts-Spreadsheets Fehler enthalten (Poon et al., Frontiers of Computer Science, 2024). Diese Unordnung überträgt sich direkt auf Systeme, die per Spreadsheet-Import gefüttert werden.

Dann das Volumen. Eine mittelgrosse B2B-Commerce-Plattform kann 50 Millionen Bestellpositionen, 2 Millionen Kundendatensätze und 500’000 Produktvarianten umfassen. Diese Daten sauber zu migrieren erfordert sorgfältiges ETL-Design, mehrere Testläufe und eine Delta-Migrationsstrategie für das Cutover-Fenster.

Ein Projekt, an dem wir gearbeitet haben, umfasste Daten aus über 15 Jahren Handelshistorie. Allein das Data Mapping dauerte drei Wochen. Dieses Investment bewahrte uns vor einem Datenqualitätsdesaster, das erst nach dem Go-live aufgetaucht wäre.

Was Sie stattdessen tun sollten: Starten Sie die Daten-Discovery in Woche eins. Profilieren Sie Ihre Daten auf Qualitätsprobleme, bevor Sie ein einziges Migrationsskript schreiben. Bauen Sie Delta-Migrationsfähigkeit von Anfang an ein, denn Sie werden sie brauchen. Und budgetieren Sie 20 bis 25 % Ihres gesamten Migrationsaufwands für die Datenarbeit. Wenn Ihnen jemand sagt, Datenmigration sei «nur ein Export/Import», hat er noch keine im grossen Massstab durchgeführt.

Was passiert, wenn Sie technische Schulden nicht zuerst bereinigen?

47 % der IT-Verantwortlichen nennen technische Schulden als Haupttreiber von Mehrausgaben für digitale Infrastruktur (IDC, 2024). Ein unaufgeräumtes System zu migrieren ergibt ein unaufgeräumtes Cloud-Deployment. Technische Schulden verschwinden nicht beim Plattformwechsel. Sie folgen Ihnen.

Typische technische Schulden, die wir in SAP-Commerce-On-Prem-Deployments finden:

Ungenutzte Extensions. Vor Jahren für ein Feature installiert, das später verworfen wurde. Werden noch geladen, verbrauchen noch Ressourcen, erzeugen noch Dependency-Konflikte.

Hardcodierte Konfigurationen. Umgebungsspezifische Werte im Code statt externalisiert. Funktioniert On-Prem, wo Sie die Infrastruktur kontrollieren. Bricht in der Cloud, wo Umgebungen dynamisch sind.

Veraltete Integrationen. Verbindungen zu Systemen, die ersetzt oder stillgelegt wurden. Die Integration läuft noch, erzeugt noch Logs, erhöht die Komplexität ohne jeden Grund.

Testdaten in der Produktion. Überbleibsel aus UAT-Zyklen, die nie bereinigt wurden. Verfälschen Analysen und erzeugen falsche Abhängigkeiten.

Eine ANWR-Projektphase erforderte zwei Wochen Bereinigung, bevor die eigentliche Migrationsarbeit beginnen konnte. Dieses Vorabinvestment verkürzte den Migrationszeitrahmen um einen Monat, weil das Team während des Builds keine Geisterabhängigkeiten debuggen musste. Zwei gut investierte Wochen.

Was Sie stattdessen tun sollten: Führen Sie 2 bis 3 Monate vor Migrationsbeginn ein Tech-Debt-Audit durch. Entfernen Sie ungenutzte Extensions, externalisieren Sie Konfigurationen, setzen Sie tote Integrationen ab und bereinigen Sie Testdaten. Behandeln Sie das als eigenständiges Deliverable mit eigenem Zeitplan und eigener Abnahme. Das Migrationsteam sollte eine saubere Codebasis übernehmen, kein Museum.

Warum scheitert Wasserfall-Lieferung bei Commerce-Migrationen?

Agile Projekte gelingen in 42 % der Fälle, verglichen mit 13 % bei Wasserfall (Standish Group CHAOS Report, 2020). Diese Lücke wird bei Commerce-Migrationen noch grösser, wo drei Dinge gegen die Big-Bang-Lieferung arbeiten.

Anforderungen verschieben sich während des Projekts. Geschäftsbedürfnisse entwickeln sich weiter. SAP veröffentlicht Plattform-Updates mitten in der Migration. Was Sie in Monat eins spezifiziert haben, kann in Monat fünf überholt sein.

Spätes Testen findet Probleme spät. Wenn Sie alles am Ende testen, summieren sich die Probleme. Ein Data-Mapping-Fehler, der in Monat acht entdeckt wird, erfordert Rework über den gesamten Build hinweg. Eine teure Entdeckung.

Big-Bang-Cutovers sind hochriskant. Jeden Markt, jeden Storefront und jede Integration an einem einzigen Wochenende umzuschalten erzeugt maximale Risikoexposition. Ein Fehler betrifft alles.

Die Franke-Migration gelang in 90 Tagen unter anderem, weil wir iterativ geliefert haben. Erst die Kernplattform, dann Storefronts, dann Integrationen. Jede Phase getestet und validiert, bevor die nächste begann. Saubere Ausführung.

Was Sie stattdessen tun sollten: Teilen Sie die Migration in Lieferzyklen von 2 bis 4 Wochen auf. Jeder Zyklus liefert ein funktionierendes, testbares Inkrement. Priorisieren Sie nach Geschäftswert: Migrieren Sie zuerst Ihren Storefront mit dem höchsten Traffic, stabilisieren Sie ihn, dann erweitern Sie. Nutzen Sie Feature Flags zur Steuerung des Rollouts.

Was kostet es wirklich, zu spät zu starten?

Das ist der Meta-Fehler. Und der häufigste.

Unternehmen kennen die EoMM-Deadline. Sie besprechen sie in Steering Committees. Sie tragen sie in Risikoregister ein. Und dann handeln sie nicht, bis es für einen komfortablen Zeitrahmen zu spät ist. Ich habe das immer und immer wieder gesehen.

Eine überstürzte Migration ist eine teure Migration. Das passiert, wenn Sie zu spät starten.

Keine Zeit für Bereinigung. Sie migrieren das Chaos so, wie es ist, und verbringen dann Monate damit, es in der Cloud zu korrigieren. Keine Zeit für saubere Planung. Premiumtarife für Talente, weil jeder Implementierungspartner ausgebucht ist. Komprimiertes Testing, bei dem Abkürzungen genommen werden und Probleme, die im QA hätten gefunden werden müssen, die Produktion erreichen. Kein Fallback-Plan, wenn beim Cutover etwas schiefgeht.

Wir sehen, dass Unternehmen, die 12 Monate vor EoMM starten, ihre Migration für 30 bis 40 % weniger abschliessen als jene, die mit 4 Monaten Vorlauf beginnen. Die Arbeit ist dieselbe. Der Kostenunterschied entsteht ausschliesslich durch Tempo, Planung und die Verfügbarkeit der richtigen Leute.

Was Sie stattdessen tun sollten: Starten Sie jetzt. Nicht nächstes Quartal. Jetzt. Selbst wenn die Migration selbst nur 90 Tage dauert, wie bei Franke, brauchen Sie Zeit für Assessment, Bereinigung, Partnerauswahl und Team-Alignment. Eine 90-Tage-Migration erfordert eine Vorbereitungsphase von 30 bis 60 Tagen. Planen Sie das in Ihren Zeitrahmen ein.

Welches Muster verbindet alle fünf Fehler?

Jeder Fehler auf dieser Liste hat eine gemeinsame Ursache: die Migration als technische Übung zu behandeln statt als Business-Transformation. 90 % der Unternehmen, die ihre Plattform migriert haben, berichteten von Umsatzverbesserungen (commercetools, 2024). Aber nur, wenn sie den Umzug strategisch angegangen sind.

Die Unternehmen, die reibungslos migrieren, sind die, die auditieren, bevor sie bauen, aufräumen, bevor sie umziehen, in Inkrementen liefern und früh genug starten, um Optionen zu haben.

Wir haben SAP-Commerce-Migrationen für ANWR, Franke, Distrelec und andere durchgeführt. Jeweils mit unterschiedlichen Rahmenbedingungen, Zeitplänen und Architekturen. Der gemeinsame Nenner der erfolgreichen Projekte ist Disziplin in der Vorbereitung. Prima vista klingt das banal. Aber die 83-%-Scheiterquote sagt Ihnen, dass es das nicht ist.

Einen vollständigen Überblick über unsere SAP-Commerce-Cloud-Leistungen, von der Migrationsplanung bis zur Composable-Storefront-Umsetzung, finden Sie auf unserer SAP Commerce Cloud Lösungsseite.

Sie planen eine SAP-Commerce-Migration? Wir führen strukturierte Migrations-Assessments durch, die entfernbare Anpassungen identifizieren, die Datenqualität profilieren und realistische Zeitpläne schätzen. Kontaktieren Sie uns.

Häufig gestellte Fragen

Wie lange dauert eine typische Migration auf SAP Commerce Cloud?

Das hängt von der Komplexität ab. Unsere schnellste (Franke) war in 90 Tagen abgeschlossen. Die meisten mittelgrossen B2B-Plattformen brauchen 4 bis 6 Monate inklusive Vorbereitung. Die grösste Variable ist nicht die Plattformgrösse. Es ist die Menge an technischen Schulden und Custom Code. Unternehmen, die zuerst eine Bereinigungsphase durchlaufen, verkürzen den Build-Zeitplan typischerweise um 20 bis 30 %.

Was ist der Unterschied zwischen SAP Commerce On-Prem und SAP Commerce Cloud?

SAP Commerce Cloud ist die verwaltete, cloud-gehostete Version von SAP Commerce. Sie übernimmt Infrastruktur, Skalierung, Deployments und Sicherheits-Patches automatisch. On-Prem gibt Ihnen volle Kontrolle, verlangt aber, dass Sie das alles selbst verwalten. Mit SAPs nahendem End of Mainstream Maintenance (EoMM) müssen On-Prem-Kunden ihren Wechsel auf Commerce Cloud oder eine Alternativplattform planen.

Was kostet eine SAP-Commerce-Migration?

Die Kosten variieren stark je nach Customizing-Volumen, Datenkomplexität und Anzahl der Integrationen. Ein nützlicher Richtwert: Budgetieren Sie 20 bis 25 % des Gesamtaufwands allein für die Datenmigration. Unternehmen, die früh starten (12+ Monate vor der Deadline), geben typischerweise 30 bis 40 % weniger aus als jene, die hetzen. Das Migrations-Assessment ist der beste erste Schritt. Es liefert eine realistische Kostenschätzung auf Basis Ihrer tatsächlichen Codebasis.

Können wir SAP Commerce in Phasen migrieren statt auf einen Schlag?

Ja, und wir empfehlen es nachdrücklich. Einen Storefront oder Markt nach dem anderen zu migrieren reduziert das Risiko und findet Probleme früher. Agile Ansätze haben eine Erfolgsquote von 42 % gegenüber 13 % bei Wasserfall (Standish Group, 2020). Feature Flags lassen Sie den Rollout ohne Big-Bang-Cutover steuern.

Was sollen wir während der Migration mit Anpassungen tun?

Gehen Sie nicht davon aus, dass jede Anpassung mitkommen muss. Nach unserer Erfahrung sind 25 bis 35 % der On-Prem-Anpassungen auf SAP Commerce Cloud unnötig, weil die Plattform sie nativ abdeckt. Bevor Sie Code migrieren, führen Sie ein strukturiertes Assessment durch: Klassifizieren Sie jede Anpassung als noch benötigt, durch Plattformfähigkeit ersetzbar oder obsolet. Dieser eine Schritt hat den grössten Effekt auf Kosten und Zeitplan der Migration.