5 Fehler, die Unternehmen bei der Migration weg von SAP Commerce On-Premise machen

Wir haben SAP Commerce Projekte für Franke, ANWR und Distrelec umgesetzt, jedes mit eigenen Rahmenbedingungen, Zeitplänen und Architekturen. Die wertvollsten Lektionen kamen nicht aus dem, was gut lief. Sie kamen aus den Fehlern, die wir Kunden erspart haben, oder aus denen wir ihnen wieder herausgeholfen haben.

Seit die Mainstream Maintenance für SAP Commerce On-Premise am 31. Juli 2026 geendet hat (SAP Help Portal), planen viele Unternehmen den Wechsel unter Zeitdruck. Genau dann passieren diese fünf Fehler. Für den Überblick über die Optionen (weiterbetreiben, überbrücken, migrieren oder SAP verlassen) beginnen Sie am besten mit unserem Leitfaden zu SAP Commerce On-Premise nach dem Ende der Mainstream Maintenance. In diesem Beitrag geht es darum, die Migration gut zu machen.

Kurzfassung: Die fünf Fehler, die SAP Commerce Migrationen langsam und teuer machen, sind: On-Premise-Anpassungen 1:1 kopieren, die Datenmigration unterschätzen, technische Schulden mitnehmen statt abbauen, alles in einem Big Bang liefern und die kundenspezifische Wartung für einen Plan halten. Jeder davon lässt sich in der Vorbereitung vermeiden: Anpassungen prüfen, Daten in Woche eins analysieren, zuerst aufräumen, in Inkrementen liefern und ein Datum festlegen.

Fehler 1: On-Premise-Anpassungen 1:1 übernehmen

Der teuerste Einzelfehler ist der Versuch, alles unverändert mitzunehmen.

Unternehmen bauen über Jahre eigene Funktionen auf ihrer On-Premise-Plattform auf, und wenn die Migration ansteht, ist der Reflex, alles zu übernehmen. Das ist verständlich: Jede Anpassung wurde aus einem Grund gebaut. Viele davon waren aber Workarounds für On-Premise-Grenzen, die SAP Commerce Cloud längst gelöst hat. Eigene Caching-Schichten, manuelle Skalierungsskripte und selbst gebaute Deployment-Pipelines übernimmt die Plattform.

Jede Codezeile, die Sie ohne Not mitnehmen, verlängert die Migration, vergrössert den Testaufwand und erhöht die künftigen Wartungskosten, und sie macht jedes spätere Upgrade schwerer (derselbe Effekt, den wir in den sieben SAP Commerce Cloud Fehlern, die Projekte entgleisen lassen, beschreiben).

Was Sie stattdessen tun sollten: Prüfen Sie jede Anpassung, bevor Sie eine einzige Codezeile migrieren, und ordnen Sie sie ein: weiterhin nötig, durch eine Standardfunktion ersetzbar oder obsolet. Nur die erste Gruppe zieht um. In unseren Assessments ist diese Liste fast immer kürzer, als der Kunde erwartet hat, und jeder gestrichene Punkt verkürzt das Projekt.

Fehler 2: Die Datenmigration unterschätzen

Auf dem Papier sieht die Datenmigration einfach aus: exportieren, transformieren, importieren. In der Praxis ist sie die Phase, die am häufigsten Zeitpläne sprengt.

Die Probleme beginnen bei der Datenqualität. On-Premise-Systeme sammeln über Jahre inkonsistente Daten an: doppelte Kundendatensätze, verwaiste Produktreferenzen, Aufträge mit fehlenden Attributen und Katalogstrukturen, die ohne Bereinigung gewachsen sind. Dazu kommt das Volumen. Eine mittelgrosse B2B-Plattform kann viele Millionen Auftragspositionen enthalten, und diese sauber zu übertragen erfordert ein durchdachtes ETL-Design, mehrere Testläufe und eine Delta-Strategie für das Umstellungsfenster.

Bei lange laufenden Plattformen mit vielen Jahren Handelshistorie kann allein das Daten-Mapping Wochen dauern. Diese Zeit ist nicht verloren: Sie verhindert, dass ein Datenqualitätsproblem erst nach dem Go-live sichtbar wird.

Was Sie stattdessen tun sollten: Beginnen Sie die Datenanalyse in Woche eins. Prüfen Sie die Datenqualität, bevor Sie ein Migrationsskript schreiben, und bauen Sie die Delta-Migration von Anfang an ein, denn Sie werden sie brauchen. Planen Sie die Datenarbeit als eigenen Workstream mit eigenem Budget und eigener Verantwortung. Wer behauptet, Datenmigration sei “nur Export und Import”, hat noch keine im grossen Massstab gemacht.

Fehler 3: Technische Schulden migrieren statt abbauen

Ein unaufgeräumtes System ergibt ein unaufgeräumtes Cloud-Deployment. Technische Schulden verschwinden beim Plattformwechsel nicht; sie ziehen mit.

Die technischen Schulden, die wir in SAP Commerce On-Premise-Installationen am häufigsten finden:

• Ungenutzte Extensions. Vor Jahren für eine später aufgegebene Funktion installiert, immer noch geladen, immer noch Quelle von Abhängigkeitskonflikten.
• Fest codierte Konfiguration. Umgebungsspezifische Werte im Code statt ausgelagert. Das funktioniert On-Premise, wo Sie die Infrastruktur kontrollieren, und bricht in der Cloud, wo Umgebungen für Sie bereitgestellt werden.
• Veraltete Integrationen. Verbindungen zu Systemen, die ersetzt oder abgeschaltet wurden, die aber weiterlaufen und Komplexität erzeugen.
• Testdaten in der Produktion. Überbleibsel alter Abnahmetests, die Auswertungen verfälschen und falsche Abhängigkeiten erzeugen.

Zeit, die vor dem Build ins Aufräumen fliesst, zahlt sich während des Builds aus, weil das Team keinen Geisterabhängigkeiten nachjagt.

Was Sie stattdessen tun sollten: Führen Sie vor dem Migrationsstart ein Audit der technischen Schulden durch. Entfernen Sie ungenutzte Extensions, lagern Sie Konfiguration aus, legen Sie tote Integrationen still und löschen Sie Testdaten. Behandeln Sie das als eigenständiges Ergebnis mit eigener Abnahme. Das Migrationsteam sollte eine saubere Codebasis übernehmen, kein Museum.

Fehler 4: Alles in einem Big Bang liefern

Grosse Technologieprogramme haben eine schwache Bilanz: Laut BCG wird bei mehr als zwei Dritteln der grossen Tech-Programme nicht erwartet, dass sie termingerecht, im Budget und im geplanten Umfang abgeschlossen werden (BCG, 2024). Bei Commerce-Migrationen sprechen drei Dinge gegen eine einzige Big-Bang-Lieferung:

• Anforderungen verschieben sich während des Projekts. Das Geschäft bewegt sich weiter, und SAP liefert mitten in der Migration Plattform-Updates. Was Sie im ersten Monat spezifiziert haben, kann im fünften überholt sein.
• Spätes Testen findet späte Probleme. Ein Mapping-Fehler, der im letzten Monat auffällt, bedeutet Nacharbeit im gesamten Build.
• Big-Bang-Umstellungen bündeln das Risiko. Wer alle Märkte, Storefronts und Integrationen an einem Wochenende umstellt, riskiert, dass ein einziger Fehler alles trifft.

Der Commerce-Launch bei Franke in 90 Tagen gelang, weil er in parallelen, getesteten Inkrementen geliefert wurde statt in einer finalen Umschaltung; das 90-Tage-Playbook beschreibt das Vorgehen.

Was Sie stattdessen tun sollten: Teilen Sie die Migration in Lieferzyklen von zwei bis vier Wochen, von denen jeder ein lauffähiges, testbares Inkrement liefert. Priorisieren Sie nach Geschäftswert: zuerst die Storefront mit dem meisten Traffic, stabilisieren, dann ausweiten. Testen Sie die ERP-Integration ab Projektmitte unter realistischer Last, nicht erst in der letzten Woche. Steuern Sie den Rollout mit Feature Flags.

Fehler 5: Die kundenspezifische Wartung für einen Plan halten

Vor dem 31. Juli 2026 hiess dieser Fehler “zu spät anfangen”. Heute hat er eine neue Form: Weil die Plattform weiterläuft und SAP bekannte Probleme im Rahmen der kundenspezifischen Wartung weiterhin löst, ist die Versuchung gross, diese Phase als bequemes Wartezimmer zu betrachten.

Das ist sie nicht. Die kundenspezifische Wartung bringt keine neuen Support Packages, keine gesetzlichen Änderungen und keine Bibliotheks-Updates, und die Lösung neuer Probleme kann kostenpflichtig sein (SAP Support). Gleichzeitig ist eine überhastete Migration eine teure Migration: keine Zeit zum Aufräumen, verdichtete Tests, kein Fallback-Plan für die Umstellung und höhere Sätze, weil erfahrene SAP Commerce Teams bereits von denen gebucht sind, die früher gestartet sind.

Was Sie stattdessen tun sollten: Legen Sie ein Zieldatum fest und planen Sie rückwärts. Auch eine schnelle Migration braucht eine Vorbereitungsphase für Assessment, Bereinigung und Partnerwahl, bevor der Build beginnt. Wenn Sie noch einen Implementierungspartner suchen, zeigt unsere Übersicht der SAP Commerce Cloud Partner in der Schweiz, worauf Sie achten sollten. Den Rest deckt die schrittweise Checkliste für die SAP Hybris Migration ab.

Was alle fünf Fehler verbindet

Jeder Fehler auf dieser Liste hat dieselbe Ursache: Die Migration wird als technischer Kopierauftrag behandelt statt als Gelegenheit zur Vereinfachung. Unternehmen, die reibungslos migrieren, prüfen, bevor sie bauen, räumen auf, bevor sie umziehen, liefern in Inkrementen und legen früh genug ein Datum fest, um noch Optionen zu haben.

Ein weiterer Punkt für Unternehmen mit SAP ERP: Die meisten Überraschungen einer Migration liegen an der Nahtstelle zwischen Commerce und ERP (Preise, Verfügbarkeit, Auftragsübergabe), nicht im Shop selbst. Wenn auch ein Wechsel zu S/4HANA auf Ihrer Roadmap steht, planen Sie beides zusammen; unser Leitfaden zu SAP Commerce Cloud mit S/4HANA Public Cloud im B2B zeigt, wie beides zusammenpasst.

Unser gesamtes Angebot zu SAP Commerce Cloud, von der Migrationsplanung bis zur Umsetzung mit Composable Storefront, finden Sie auf unserer SAP Commerce Cloud Lösungsseite.

---

Planen Sie eine SAP Commerce Migration? Wir führen strukturierte Migrations-Assessments durch, die entfernbare Anpassungen identifizieren, die Datenqualität analysieren und einen realistischen Zeitplan schätzen. Nehmen Sie Kontakt auf.

Häufig gestellte Fragen

Wie lange dauert eine typische Migration zu SAP Commerce Cloud?

Typische Migrationen dauern 6 bis 12 Monate, disziplinierte Fast-Track-Projekte 4 bis 6 Monate. Am schnellen Ende haben wir die SAP Commerce Cloud Plattform von Franke in 90 Tagen live gebracht. Die grösste Variable ist nicht die Grösse der Plattform, sondern wie viele technische Schulden und wie viel Eigencode Sie mitnehmen; deshalb zählt die Vorbereitungsphase am meisten.

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

SAP Commerce Cloud ist die von SAP betriebene Cloud-Version von SAP Commerce: SAP verantwortet Infrastruktur, Skalierung, Deployments und Plattform-Updates. SAP Commerce On-Premise (letztes Release 2205) hat am 31. Juli 2026 die Mainstream Maintenance verlassen und erhält nur noch kundenspezifische Wartung, also keine neuen Support Packages, gesetzlichen Änderungen oder Bibliotheks-Updates mehr.

Was kostet eine SAP Commerce Migration?

Das hängt vor allem von der Zahl der Anpassungen, Integrationen und Storefronts sowie vom Zustand Ihrer Daten ab; eine belastbare Zahl braucht deshalb ein Assessment Ihres Codes. Die grössten Einsparungen entstehen, wenn Sie nicht benötigte Anpassungen und Daten vor dem Migrationsstart entfernen, nicht beim Verhandeln der Tagessätze.

Können wir SAP Commerce schrittweise statt auf einmal migrieren?

Ja, und wir empfehlen es. Migrieren Sie zuerst die Kernplattform, dann eine Storefront oder einen Markt nach dem anderen, jeweils getestet, bevor der nächste Schritt beginnt. Mit Feature Flags steuern Sie den Rollout ohne Big-Bang-Umstellung am Wochenende.

Was sollten wir während der Migration mit unseren Anpassungen tun?

Gehen Sie nicht davon aus, dass jede Anpassung mitmuss. Ordnen Sie jede als weiterhin nötig, durch eine Standardfunktion ersetzbar oder obsolet ein. Viele On-Premise-Anpassungen wie eigenes Caching, Skalierungsskripte und Deployment-Pipelines deckt SAP Commerce Cloud von Haus aus ab.