Wie läuft die Datenmigration beim SAP-Hybris-Ausstieg ab?

Die kurze Antwort

Beim SAP-Hybris-Ausstieg werden vier Datenwelten neu verortet: Produktkatalog, Kundenkonten, Bestellhistorie und die Anbindung an SAP ERP oder S/4HANA. Keine SAP-Datenmigration gelingt als reiner Datenexport. Sie braucht ein Konzept, das vorher festlegt, was eins zu eins übernommen wird, was bereinigt wird und was archiviert statt migriert wird. Genau dieser Teil, nicht die Plattformwahl selbst, entscheidet in der Praxis über Timeline und Budget des gesamten Ausstiegs.

Was bedeutet Datenmigration im Kontext des SAP-Hybris-Ausstiegs?

Datenmigration ist allgemein die Übertragung von Daten von einem System in ein anderes, meist im Zuge eines Plattform- oder Infrastrukturwechsels. Im Hybris-Kontext ist die Frage enger: Wie kommen die Datenmodelle einer auslaufenden SAP-Commerce-Plattform in ein neues Shopsystem, ohne dass Produktdaten, Kundenbeziehungen oder die Anbindung an SAP als führendes ERP-System dabei brechen.

Der Anlass ist konkret terminiert. SAP Commerce (Hybris) On-Premise erreicht mit Version 2205 am 31. Juli 2026 das Ende der regulären Wartung, danach gibt es keine Sicherheitsupdates, keine Compliance-Patches und keine funktionalen Fixes mehr, nur noch eine kostenpflichtige, SLA-freie Individualwartung. Dieses Datum bestätigen mehrere unabhängige SAP-Fachquellen übereinstimmend, etwa arineo und mimacom. Wer diese Frist verstreichen lässt, betreibt ein System ohne regulären Herstellersupport weiter, mit allen Sicherheits- und Compliance-Risiken, die das mit sich bringt. Was das für eure EOL-Entscheidung konkret bedeutet, ordnet der Beitrag SAP Hybris End of Life 2026 ein; welches System danach infrage kommt, behandelt der Alternativen-Vergleich für Enterprise-B2B. Dieser Artikel setzt an dem Punkt an, an dem diese Entscheidung bereits gefallen ist.

Das ist eine bewusste Abgrenzung, keine Verkürzung. Wer noch zwischen Plattformen abwägt, braucht andere Informationen als jemand, der die Entscheidung bereits getroffen hat und jetzt operativ plant. Die Vermischung beider Fragen ist einer der Gründe, warum generische Datenmigrations-Ratgeber im Netz selten konkret weiterhelfen: Sie versuchen, Plattformwahl und Umsetzung in einem Artikel zu beantworten, und bleiben deshalb bei beidem oberflächlich.

Welche Daten müssen beim SAP-Hybris-Ausstieg migriert werden?

Fünf Datenobjekte entscheiden über Aufwand und Risiko der Migration, und nicht jedes davon sollte automatisch eins zu eins übernommen werden.

Ein reales Beispiel für diese Objektliste liefert der Fahrradkomponentenhersteller MAGURA (Gustav Magenwirth GmbH & Co. KG, rund 680 Mitarbeitende). Bei der Migration von Website, Portal und Shop auf eine neue Plattform hat MAGURA explizit Bestellhistorie und ERP-Historie übernommen und die ERP-Anbindung über SAP Cloud Platform Integration realisiert, dokumentiert im Interview mit Michael Freudenberg, Leiter Digitalisierung und IT bei MAGURA, veröffentlicht auf der DSAG-Plattform impulsant.dsag.de.

Welche Migrationsstrategien gibt es, und welche wird tatsächlich am häufigsten genutzt?

Reiner Big Bang ist in der Praxis die Ausnahme, nicht die Regel. Nach dem ERP Report 2025/2026 von Panorama Consulting Group, einer Befragung von 170 Unternehmen, wählten 15,9 % einen reinen Big-Bang-Ansatz, während 37,6 % einen hybriden Ansatz kombinierten und weitere 30,0 % modulweise phasenweise vorgingen. Für einen Hybris-Ausstieg unter EOL-Druck ist das relevant, weil die Fristlage oft nach Big Bang aussieht, die Datenrealität aber meist einen gemischten Ansatz erzwingt.

Aus der Migrationspraxis zwischen SAP-Systemen lässt sich eine ergänzende, eher aufwandsbasierte Einteilung übertragen. Johanna Grade, Software-Architektin bei der SAP-Partneragentur diva-e, unterscheidet in einem Praxis-Webinar zur SAP-Commerce-Cloud-Migration drei Typen: eine feature-für-feature-Optimierung des Bestehenden, ein kompletter Neuaufbau bei hoher technischer Schuld, oder im Ausnahmefall die unveränderte Übernahme bei akutem Zeitdruck und sehr modernem Code (diva-e-Webinar, 2026, sinngemäß). Diese Typologie stammt aus dem Verbleib-im-SAP-Ökosystem, dem Wechsel von On-Premise-Hybris zu SAP Commerce Cloud, das Prinzip überträgt sich aber unabhängig vom Zielsystem: Die unveränderte Übernahme bringt laut dieser Einordnung keinerlei Vorteil aus dem Systemwechsel selbst, sondern verschiebt den Aufwand nur in die Zukunft.

Wie sieht das Vorgehen Schritt für Schritt aus?

Sieben Phasen ziehen sich durch belastbare SAP-Migrationsprojekte: Bestandsaufnahme und Datenaudit, Konzept und Feldmapping, Datenbereinigung, Testmigration, Validierung, produktive Migration, Stilllegung des Altsystems. Der typische Stolperstein liegt selten in der Technik, sondern darin, dass eine dieser Phasen übersprungen oder zu knapp bemessen wird.

Wie das in der Praxis aussieht, beschreibt Johanna Grade von diva-e am Beispiel eines Umstiegs von On-Premise-Hybris auf SAP Commerce Cloud, ein Muster, das sich auf jeden Hybris-Ausstieg übertragen lässt: Das Vorgehen beginnt mit zwei Stakeholder-Workshops. Im ersten werden Anforderungen aller Beteiligten, Business wie Technik, zusammengetragen und dokumentiert, im zweiten wird geprüft, welche Verbesserungen die neue Plattform zusätzlich ermöglicht. Am Ende beider Workshops steht ein priorisiertes Backlog, aus dem die eigentliche Migration nahtlos startet, statt erst während der Umsetzung zu klären, was eigentlich gebraucht wird (diva-e-Webinar, 2026, sinngemäß). Wiederkehrende Hürden in diesem Ablauf sind laut ihrer Erfahrung Systeme, die aus Sicherheitsgründen nicht von außen erreichbar sein dürfen und daher eine alternative Anbindung brauchen, sowie Legacy-Funktionen wie individuelle Variantenkonfigurationen, die im Zielsystem selten unverändert weiterlaufen.

Wie entwickelt man ein Datenmigrationskonzept für den Systemwechsel?

Ein Migrationskonzept ist ein Entscheidungsdokument, kein technisches Skript. Es hält vier Dinge verbindlich fest, bevor die erste Zeile Migrationscode geschrieben wird: eine Feldmapping-Tabelle, die jedes Quellfeld einem Zielfeld zuordnet, klare Verantwortlichkeiten für den Fall, dass sich Datenquellen widersprechen, Abnahmekriterien, an denen sich eine erfolgreiche Migration objektiv messen lässt, und einen Rollback-Plan für den Fall, dass die Testmigration scheitert.

Die Feldmapping-Tabelle ist dabei mehr als eine technische Fleißarbeit. Sie zwingt zu Entscheidungen, die sonst erst beim Testen auffallen würden: Ein Hybris-Pflichtfeld hat im Zielsystem oft kein direktes Gegenstück, ein Freitextfeld auf der einen Seite entspricht einer strukturierten Auswahlliste auf der anderen. Wer diese Lücken im Konzept dokumentiert, statt sie dem Entwicklungsteam während der Umsetzung zu überlassen, verhindert, dass fachliche Fragen als technische Notlösungen beantwortet werden.

Verantwortlichkeiten sind der zweite kritische Punkt. Bei widersprüchlichen Datenquellen, etwa wenn eine Kundenadresse in SAP anders lautet als im Hybris-Shop, muss vorab feststehen, wer entscheidet und nach welcher Regel, nicht erst im Konfliktfall. Der Unterschied zum technischen Migrationsskript ist bewusst: Das Skript setzt um, was das Konzept entschieden hat. Wird diese Reihenfolge vertauscht, entstehen genau die Konflikte, die weiter unten als häufigster Fehler auftauchen.

Wie bindet man das neue Shopsystem an SAP ERP oder S/4HANA an?

SAP bleibt für Artikelstamm, Preise und Verfügbarkeit in aller Regel das führende System. Der Shop konsumiert diese Daten über eine definierte Schnittstelle, statt sie dauerhaft im Shopsystem zu duplizieren. Duplizierte Datenhaltung ist der häufigste Grund, warum Preise oder Bestände zwischen SAP und Shop nach einiger Zeit auseinanderlaufen.

MAGURA hat diese Anbindung über SAP Cloud Platform Integration umgesetzt und dabei zusätzlich eine Self-Service-Verwaltung mit Single Sign-on für Kunden realisiert. Das Prinzip lässt sich unabhängig vom gewählten Zielsystem übertragen: Die ERP-Anbindung ist eine Architekturentscheidung, keine Migrationsdetail-Frage, die sich nachträglich korrigieren lässt.

Wird diese Entscheidung übersprungen und stattdessen erst einmal ein vollständiger Datenexport aus SAP in das neue Shopsystem geschrieben, entsteht genau die doppelte Datenhaltung, die später zum Synchronisationsproblem wird. Jede spätere Preisänderung, jede Bestandsaktualisierung muss dann in zwei Systemen parallel gepflegt oder über eine nachträglich gebaute Synchronisation abgeglichen werden, ein Aufwand, der sich mit einer von Anfang an sauber definierten Schnittstelle vermeiden lässt.

Was macht man mit der Bestellhistorie?

Migrieren oder archivieren ist eine eigene Entscheidung, kein automatischer Teil der großen Migration. Das Kriterium ist einfach: Wird die Historie im neuen System aktiv gebraucht, etwa für Kundenservice, Reklamationen oder Wiederkauf-Funktionen, oder reicht ein read-only-Archiv oder Export.

Wer Bestellhistorie reflexhaft komplett live migriert, migriert oft Datenvolumen, das nie wieder abgerufen wird, und treibt damit unnötig Aufwand und Kosten der gesamten Migration nach oben. Ein Archiv oder ein reiner Export deckt in vielen Fällen denselben Bedarf ab wie eine vollständige Live-Migration, mit deutlich geringerem Aufwand an Feldmapping und Testaufwand, weil Archivdaten nicht denselben Validierungsanforderungen unterliegen wie aktiv genutzte Datensätze im Produktivsystem.

MAGURA hat sich für die aktive Integration entschieden und Bestellhistorie sowie ERP-Historie explizit Teil der neuen Self-Service-Verwaltung mit Single Sign-on gemacht. Das ist eine bewusste, begründete Entscheidung, kein Standardfall. Die Faustregel bleibt: Erst die Nutzungsfrage beantworten, dann die technische Migrationsentscheidung treffen, nicht umgekehrt.

Häufige Fehler bei der SAP-Datenmigration

Diese Fehler tauchen in SAP-Transformationsprojekten immer wieder auf, unabhängig vom Zielsystem:

• Test- und Datenmigrationsphasen werden im Projektplan systematisch unterschätzt. Laut einer Studie von Horváth & Partners unter 200 Unternehmen in sechs Ländern (u. a. DACH) dauern SAP-S/4HANA-Transformationen im Schnitt 30 % länger als geplant, mehr als 60 % überschreiten das Budget, und unterschätzte Test- und Datenmigrationsphasen werden als eine von drei explizit genannten Hauptursachen angeführt, neben Scope-Erweiterung und schwachem Projektmanagement, nicht technische Probleme.
• Das Datenmigrationskonzept entsteht erst während der Migration statt davor.
• Feldmapping wird technisch statt fachlich entschieden.
• Datenbereinigung wird übersprungen, Datenmüll wird eins zu eins mitgenommen.
• Bestellhistorie wird reflexhaft komplett migriert, obwohl ein Archiv gereicht hätte.
• Kein Rollback-Plan für den Fall einer gescheiterten Testmigration.
• Migrationstools werden als vollständige Lösung missverstanden. Thomas Henzler, DSAG-Fachvorstand, warnt für SAP-CX-Systemwechsel allgemein davor, unterschiedliche Technologiegenerationen für lift-and-shift-fähig zu halten, und stellt klar, dass verfügbare Migrationstools nur einen Bruchteil des tatsächlichen Aufwands abfangen.

Was gehört auf eine Datenmigrations-Checkliste beim Shopsystem-Wechsel?

Eine belastbare Checkliste folgt dem Phasenmodell von oben, nicht einer beliebigen Reihenfolge:

1. Datenaudit: Welche Datenobjekte existieren tatsächlich, in welchem Volumen?
2. Verantwortlichkeiten klären: Wer entscheidet bei widersprüchlichen Datenquellen?
3. Feldmapping dokumentieren, Quellfeld zu Zielfeld, keine impliziten Annahmen.
4. Bereinigungsregeln festlegen: Was gilt als Dublette, was als veraltet?
5. Entscheidung Bestellhistorie treffen: migrieren oder archivieren.
6. ERP-Anbindung als Architektur festlegen, nicht als nachträgliches Detail.
7. Testmigration mit einer repräsentativen Teilmenge durchführen.
8. Validierungskriterien vorab definieren, nicht erst nach der Testmigration.
9. Rollback-Plan für die produktive Migration bereithalten.
10. Freigabe-Meilenstein mit allen Stakeholdern, nicht nur mit der IT.
11. Produktive Migration in der zuvor festgelegten Strategie durchführen.
12. Nachkontrolle: stichprobenartiger Abgleich zwischen Alt- und Neusystem nach Go-live.

Wie stellt man Datenqualität vor der Migration sicher?

Bereinigung gehört vor das Mapping, nicht danach. Wer zuerst mappt und danach bereinigt, überträgt Fehler strukturiert statt sie zu beheben. Typische Kandidaten für eine bewusste Nicht-Migration sind doppelte Kundenkonten, seit Jahren inaktive Kundenkonten und Artikel, die im aktuellen Sortiment gar nicht mehr geführt werden.

In der Praxis lohnt sich dafür ein eigener Datenaudit-Schritt vor dem eigentlichen Konzept, nicht als dessen Nebenprodukt. Ein Hybris-System, das über Jahre gewachsen ist, sammelt fast zwangsläufig Karteileichen: Testkonten aus der Einführungsphase, Artikel, die nur noch aus historischen Gründen im Katalog stehen, oder Kundendaten, die durch mehrfache Importe dupliziert wurden. Jede dieser Kategorien braucht eine eigene, dokumentierte Entscheidungsregel, keine Einzelfallprüfung während der Migration.

Der Aufwand dafür lohnt sich doppelt: Wer Datenmüll vor der Migration identifiziert, spart nicht nur Migrationsaufwand und reduziert das Datenvolumen, das getestet und validiert werden muss, sondern verhindert auch, dass sich dieselben Altlasten im neuen System erneut festsetzen und dort ein zweites Mal Aufwand verursachen.

Was kostet eine SAP-Datenmigration beim Shopsystem-Wechsel, und wie lange dauert sie?

Es gibt keine einzige öffentlich zitierfähige Studie, die Kosten oder Dauer speziell für einen SAP-Hybris-Ausstieg beziffert. Das ist selbst eine Aussage, keine Ausrede. Was es gibt, ist die SAP-Transformationsforschung im Großen, und die zeigt seit Jahren dasselbe Muster: Laut Horváth & Partners (200 befragte Führungskräfte in sechs Ländern, u. a. DACH) dauern SAP-S/4HANA-Transformationen im Schnitt 30 % länger als geplant, nur rund einer von zehn Betrieben hält den Zeitplan ein, und über 60 % überschreiten das Budget, bei 40 % davon deutlich. Als eine von drei explizit genannten Ursachen führen die Befragten unterschätzte Test- und Datenmigrationsphasen an, neben Scope-Erweiterung und schwachem Projektmanagement. Der ERP Report 2025/2026 von Panorama Consulting Group bestätigt das Muster aus einer anderen Stichprobe: Datenprobleme sind bei 29,4 % der Projekte mit Budgetüberschreitung und bei 36,8 % der Projekte mit Terminüberschreitung die genannte Ursache.

Es gibt keinen Grund zur Annahme, dass ein Hybris-Ausstieg davon eine Ausnahme ist. Eine exakte Kosten- oder Dauerspanne speziell für SAP-Hybris-Datenmigrationen existiert schlicht nicht als öffentlich zitierfähige Zahl, das haben wir bei der Recherche zu diesem Artikel systematisch geprüft, nicht nur vermutet. Was die tatsächliche Spanne im Einzelfall bestimmt, sind stattdessen vier Faktoren: das Datenvolumen, die Anzahl an Sonderfällen und Custom-Feldern, ob die Bestellhistorie migriert oder archiviert wird, und wie viele Systeme an der ERP-Anbindung hängen.

Welches Shopsystem eignet sich nach dem SAP-Hybris-Ausstieg am besten für die Datenübernahme?

Es gibt hier bewusst keine pauschale Systemempfehlung, das würde die Neutralität dieses Artikels aufgeben, ohne dass sie durch die konkrete Anforderungslage eines Unternehmens gedeckt wäre. Für die Datenmigration selbst zählen andere Kriterien als für die grundsätzliche Plattformwahl: offene APIs statt geschlossener Schnittstellen, Unterstützung für Custom-Felder ohne Workarounds, und belastbares Import-Tooling für große Datenmengen. Ein System, das auf dem Papier alle Business-Anforderungen erfüllt, aber nur einen rudimentären CSV-Import bietet, macht die Datenmigration selbst unnötig teuer, unabhängig davon, wie gut es sich sonst schlägt.

Wer bereits weiß, dass die Wahl auf Shopware fällt, findet die konkrete Kostenrechnung im Beitrag Shopware Kosten 2026. Wer zwischen einem SAP-nahen Verbleib und einem Wechsel zu Shopify abwägt, findet die ehrliche Einordnung im Beitrag Von Shopware zu Shopify wechseln. Beide Artikel setzen die Systementscheidung voraus, die dieser Beitrag bewusst offenlässt, weil sie von den individuellen B2B-Anforderungen abhängt, nicht von der Datenmigration allein.

Fazit

Die Datenmigration ist kein technisches Nebenprojekt zum Systemwechsel. Sie ist der Teil des SAP-Hybris-Ausstiegs, an dem Timeline und Budget real entschieden werden, das zeigt die SAP-Transformationsforschung branchenweit, und nichts spricht dafür, dass Hybris-Ausstiege davon ausgenommen sind. Wer das Migrationskonzept vor der Migration schreibt, Bestellhistorie bewusst statt reflexhaft behandelt und die ERP-Anbindung als Architektur statt als Detail plant, vermeidet die Fehler, die in der Praxis am teuersten werden.

Die Reihenfolge macht dabei den Unterschied: Erst die Datenobjekte inventarisieren, dann das Konzept schreiben, dann bereinigen, dann testen, und erst danach produktiv migrieren. Jede Abkürzung in dieser Reihenfolge taucht später wieder auf, meist teurer als beim ersten Mal, weil sie dann nicht mehr im Konzept, sondern live im Produktivsystem korrigiert werden muss.

Wenn du gerade vor genau dieser Frage stehst: Schreib uns unten kurz, wo ihr steht, wir prüfen dein Datenmigrationskonzept für den SAP-Hybris-Ausstieg mit dir durch, unabhängig davon, für welches Zielsystem du dich entscheidest.

FAQ

Was versteht man unter Datenmigration?

Die Übertragung von Daten aus einem System in ein anderes, meist im Zuge eines Plattformwechsels. Beim SAP-Hybris-Ausstieg heißt das konkret: Produktkatalog, Kundenkonten, Bestellhistorie und ERP-Anbindung müssen in ein neues Shopsystem überführt werden, ohne dass die Geschäftslogik dahinter bricht.

Welche Datenarten migriert man bei einem SAP-Hybris-Ausstieg?

Fünf Kernobjekte: Produktkatalog und Kategorien, Kundenkonten samt B2B-Hierarchien, Preise und Konditionen, Bestellhistorie und ERP-Stammdaten. Nicht jedes davon sollte eins zu eins übernommen werden, Preise etwa bleiben meist ERP-seitig führend statt im Shop dupliziert zu werden.

Muss die komplette Bestellhistorie migriert werden?

Nein. Das ist eine eigene Entscheidung, kein automatischer Teil der Migration. Entscheidend ist, ob die Historie im neuen System aktiv gebraucht wird, etwa für Kundenservice oder Wiederkauf-Funktionen, oder ob ein read-only-Archiv ausreicht.

Was ist der Unterschied zwischen Big-Bang- und schrittweiser Migration?

Big Bang migriert alle Daten auf einen Stichtag, schrittweise Migration verteilt sie auf mehrere Phasen nach Modul, Standort oder Geschäftseinheit. Laut dem ERP Report 2025/2026 von Panorama Consulting Group ist reiner Big Bang mit 15,9 % tatsächlich die seltenste Variante, ein hybrider Ansatz mit 37,6 % die häufigste.

Was kostet eine SAP-Datenmigration typischerweise?

Es gibt keine öffentlich zitierfähige Studie, die das speziell für SAP-Hybris beziffert. Als Richtwert aus verwandter SAP-Transformationsforschung gilt: Über 60 % der SAP-Transformationsprojekte überschreiten laut Horváth & Partners das Budget; unterschätzte Datenmigrationsphasen sind eine von mehreren explizit genannten Ursachen dafür. Die konkrete Spanne hängt stark von Datenvolumen und Sonderfällen ab.

Wie lange dauert eine SAP-Datenmigration beim Shopwechsel?

Ebenfalls ohne belastbare Hybris-spezifische Zahl. Zur Einordnung: SAP-S/4HANA-Transformationen dauern laut Horváth & Partners im Schnitt 30 % länger als ursprünglich geplant, nur rund jedes zehnte Projekt hält den Zeitplan ein.

Was sind die häufigsten Fehler bei einer SAP-Datenmigration?

Das Migrationskonzept entsteht erst während der Migration statt davor, Datenbereinigung wird übersprungen, und Migrationstools werden fälschlich als vollständige Lösung statt als Unterstützung verstanden, die laut DSAG-Fachvorstand Thomas Henzler nur einen Bruchteil des Aufwands abfängt.