5 Fehler, die Unternehmen bei der SAP Commerce Migration machen

Wir haben SAP Commerce-Plattformen für Franke, ANWR und Distrelec migriert. Jedes Projekt hatte seine Eigenheiten. Aber die wertvollsten Lektionen? Die kamen nicht von den Dingen, die liefen. Sondern von den Fehlern, die wir unseren Kunden entweder ersparen konnten oder im Rettungsmodus beheben mussten.

Fünf Fehler sehen wir immer wieder. Alle vermeidbar, wenn Sie wissen, wo die Fallen liegen.

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

Der teuerste Einzelfehler, prima vista. Unternehmen haben über Jahre Custom-Funktionalität aufgebaut. Wenn die Migration kommt, ist der Reflex klar: alles so wie es ist auf SAP Commerce Cloud heben. Eins zu eins.

Das Problem: 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. Das alles gibt es nativ in der Cloud.

Konkret: Wir haben Migrationen erlebt, bei denen 30-40 % des Custom Codes auf der Zielplattform schlicht unnötig war. Jede unnötige Zeile erhöht die Migrationszeit, den Testaufwand und die künftigen Wartungskosten. Wer alles mitnimmt, zieht mit dem Gerümpel um.

Was Sie stattdessen tun sollten: Bevor Sie eine einzige Zeile Code migrieren, auditieren Sie jede Anpassung. Klassifizieren Sie: 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, Transformation, Import. Drei Schritte. 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 inkonsistente Daten an. Doppelte Kundendatensätze, verwaiste Produktreferenzen, Bestellungen mit fehlenden Attributen, Katalogstrukturen, die ohne Bereinigung gewuchert sind. Also ehrlich: Nach zehn Jahren sieht jede Datenbank aus wie ein Dachboden, den niemand aufräumen wollte.

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 im Distrelec-Umfeld umfasste Daten aus über 15 Jahren Handelshistorie. Allein das Data Mapping dauerte drei Wochen. 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. 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 wie ein Schatten. Nota bene: Sie wird in der Cloud sogar sichtbarer, weil die Plattform transparenter ist.

Was wir in SAP Commerce On-Prem-Deployments regelmässig 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 längst 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. Das Team musste während des Builds keine Geisterabhängigkeiten debuggen. Zwei Wochen investiert, vier Wochen gespart. Die Rechnung geht auf.

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 Anforderungen, 4 Monate Build, 2 Monate Testing, dann ein Big-Bang-Go-Live. Wir haben das gesehen. Bei grösseren Projekten scheitert es. Zuverlässig.

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. Wer den Brunnen erst gräbt, wenn das Haus brennt, hat ein Problem.
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

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? Nichts. Bis es für einen komfortablen Zeitrahmen zu spät ist.

Eine überstürzte Migration ist eine teure Migration. Das passiert konkret, 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.

Die Zahlen sprechen für sich: Unternehmen, die 12 Monate vor EoMM starten, schliessen ihre Migration für 30-40 % weniger ab 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, 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. De facto trennt genau diese Haltung die Projekte, die glatt laufen, von denen, die entgleisen. 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.

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

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 und lassen Sie uns sicherstellen, dass Ihre Migration auf der richtigen Seite dieser fünf Lektionen landet.