5 Fehler, die Unternehmen bei der SAP Commerce Migration machen

Wir haben SAP Commerce-Plattformen für Unternehmen wie Franke, ANWR und Distrelec migriert. Jedes Projekt hat uns etwas gelehrt. Aber die wertvollsten Lektionen kamen von den Fehlern, die wir unseren Kunden ersparen — oder bei deren Behebung wir helfen konnten.

Hier sind die fünf häufigsten Fehler, die Unternehmen bei der Migration von SAP Commerce On-Prem machen. Jeder einzelne ist vermeidbar, wenn Sie wissen, worauf Sie achten müssen.

Fehler 1: On-Prem-Anpassungen 1:1 in die Cloud übertragen

Das ist der teuerste Einzelfehler. Unternehmen investieren über Jahre hinweg in Custom-Funktionalität auf ihrer On-Prem-Plattform. Wenn die Migration ansteht, ist der Reflex, alles so wie es ist auf SAP Commerce Cloud zu übertragen.

Das Problem? Viele dieser Anpassungen waren Workarounds für On-Prem-Einschränkungen, die Commerce Cloud bereits gelöst hat. Custom Caching Layer, manuelle Skalierungsskripte, eigene Deployment-Pipelines — Commerce Cloud bietet all das nativ.

Wir haben Migrationen erlebt, bei denen 30-40 % des Custom Codes auf der Zielplattform unnötig war. Jede unnötige Zeile Code 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 Plattform-Funktionalität ersetzbar oder obsolet. Wir führen ein strukturiertes Assessment durch, das typischerweise 25-35 % der Anpassungen als entfernbar identifiziert. Das reduziert direkt Migrationskosten und -zeitrahmen.

Fehler 2: Die Komplexität der Datenmigration unterschätzen

Datenmigration sieht auf dem Papier einfach aus: Export aus dem Quellsystem, Transformation, Import ins Zielsystem. In der Praxis ist es die Phase, die die meisten Zeitpläne zum Entgleisen bringt.

Die Probleme beginnen bei der Datenqualität. On-Prem-Systeme sammeln über Jahre hinweg inkonsistente Daten an — doppelte Kundendatensätze, verwaiste Produktreferenzen, Bestellungen mit fehlenden Attributen, Katalogstrukturen, die ohne Bereinigung gewachsen sind.

Dann ist da 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 Distrelec-nahes Projekt umfasste Daten aus über 15 Jahren Handelshistorie. Allein das Data Mapping dauerte drei Wochen — und dieses Investment bewahrte uns vor einem katastrophalen Datenqualitätsproblem, das nach 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 — Sie werden sie brauchen. Und planen Sie 20-25 % des gesamten Migrationsaufwands für Datenarbeit ein. Wenn Ihnen jemand sagt, Datenmigration sei «nur ein Export/Import», hat er noch keine im grossen Massstab durchgeführt.

Fehler 3: Tech Debt vor der Migration nicht bereinigen

Ein unaufgeräumtes System zu migrieren ergibt ein unaufgeräumtes Cloud-Deployment. Tech Debt verschwindet nicht beim Plattformwechsel — sie folgt Ihnen.

Häufige Tech Debt, die wir in SAP Commerce On-Prem-Deployments sehen:

• Ungenutzte Extensions: Vor Jahren für ein Feature installiert, das später verworfen wurde. Wird noch geladen, verbraucht noch Ressourcen, erzeugt noch Dependency-Konflikte.
• Hardcodierte Konfigurationen: Umgebungsspezifische Werte direkt 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 noch die Komplexität.
• Testdaten in 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 kürzte den Migrationszeitrahmen um einen Monat, weil das Team während des Builds keine Geisterabhängigkeiten debuggen musste.

Was Sie stattdessen tun sollten: Führen Sie ein Tech-Debt-Audit 2-3 Monate vor Migrationsbeginn 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 Abnahme. Das Migrationsteam sollte eine saubere Codebasis übernehmen, kein Museum.

Fehler 4: Wasserfall statt iterativer Delivery wählen

Der klassische Plan: 3 Monate für Anforderungen, 4 Monate für Build, 2 Monate für Testing, dann ein Big-Bang-Go-Live. Wir haben das gesehen. Bei grösseren Projekten scheitert es.

Wasserfall versagt bei Commerce-Migrationen aus drei Gründen:

1. Anforderungen ändern sich während des Projekts. Geschäftsbedürfnisse entwickeln sich. SAP veröffentlicht Plattform-Updates während der Migration. Was Sie in Monat eins spezifiziert haben, kann in Monat fünf überholt sein.
2. Spätes Testing findet späte Probleme. Wenn Sie alles am Ende testen, summieren sich Probleme. Ein Data-Mapping-Fehler, der in Monat acht entdeckt wird, erfordert Rework über den gesamten Build hinweg.
3. 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 vorgegangen sind. Erst die Kernplattform, dann Storefronts, dann Integrationen — jede Phase getestet und validiert, bevor die nächste begann.

Was Sie stattdessen tun sollten: Teilen Sie die Migration in 2-4-wöchige Delivery-Zyklen auf. Jeder Zyklus liefert ein funktionsfähiges, 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. Dieser Ansatz findet Probleme früher, verteilt Risiko und gibt Stakeholdern ab Woche zwei sichtbare Fortschritte.

Fehler 5: Zu lange warten und unter Zeitdruck migrieren

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.

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

• Keine Zeit für Bereinigung. Sie migrieren den Ist-Zustand und verbringen dann Monate mit der Korrektur in der Cloud.
• Premiumtarife für Talente. Jeder Implementierungspartner ist ausgebucht. Sie zahlen Aufpreise für Verfügbarkeit.
• Komprimiertes Testing. Es werden Abkürzungen genommen. Probleme, die im QA hätten gefunden werden müssen, erreichen die Produktion.
• Kein Fallback-Plan. Wenn beim überstürzten Cutover etwas schiefgeht, gibt es keinen Puffer für die Wiederherstellung.

Wir beobachten, dass Unternehmen, die 12 Monate vor EoMM starten, ihre Migration für 30-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 30-60-tägige Vorbereitungsphase. Planen Sie das in Ihren Zeitrahmen ein.

Das Muster hinter allen fünf Fehlern

Jeder Fehler auf dieser Liste hat eine gemeinsame Ursache: Die Migration als rein technische Übung zu behandeln statt als Business-Transformation. Die Unternehmen, die reibungslos migrieren, sind die, die:

• Auditieren, bevor sie bauen
• Aufräumen, bevor sie umziehen
• In Inkrementen liefern statt als Big Bang
• 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 erfolgreicher Projekte ist Disziplin in der Vorbereitung.

Bereit, diese Fehler zu vermeiden?

Wenn Sie eine SAP Commerce-Migration planen, beginnen Sie mit einem Migrations-Assessment. Wir auditieren Ihre Anpassungen, profilieren Ihre Daten, schätzen Ihren Zeitrahmen und identifizieren die Fallstricke, die spezifisch für Ihr Setup sind.

Kontaktieren Sie uns — lassen Sie uns sicherstellen, dass Ihre Migration auf der richtigen Seite dieser fünf Lektionen landet.