Shopware als Datenquelle nutzen: Datenkonsolidierung bei der ERP-Migration
Ein Teil der Daten, die Sie aus PlentyONE ziehen wollen, liegt bereits woanders: im eigenen Shop. Artikel, Kategorien, Kunden, bei Einkanal-Betrieb auch die Bestellhistorie.
Das ist keine akademische Feststellung, sondern der wirksamste Hebel gegen das API-Kontingent. Jeder Datensatz, den Sie aus dem selbst gehosteten Shopsystem beziehen, belastet das PlentyONE-Budget nicht. Und dieses Budget ist in der Migrationsphase die knappste Ressource.
Wo diese Strategie greift und wo nicht, zeigt dieser Beitrag. Die Kontingentfrage selbst, die sie überhaupt erst motiviert, behandelt PlentyONE API Limits umgehen.
Warum ein ERP nicht immer alleinige Datenquelle sein muss
In gewachsenen E-Commerce-Systemlandschaften sind Daten selten sauber in einem einzigen System konzentriert. Artikeltexte, SEO-Daten, Bildmaterial oder Kategoriestrukturen werden häufig direkt im Shopsystem gepflegt, weil sie dort unmittelbar wirksam werden – nicht zwangsläufig im ERP. Eine Migration, die stur nur eine Quelle vorsieht, migriert in solchen Fällen entweder veraltete Daten oder erzeugt unnötigen zusätzlichen Aufwand, um Daten im ERP nachzupflegen, die im Shopsystem längst korrekt vorliegen.
Ein typisches Beispiel aus der Praxis: SEO-optimierte Produktbeschreibungen, die über Jahre im Shopsystem redaktionell verfeinert wurden, existieren im ERP oft nur als kurze, funktionale Artikelbezeichnung. Würde die Migration ausschließlich die ERP-Daten übernehmen, ginge diese redaktionelle Arbeit verloren – ein Qualitätsverlust, der sich erst nach dem Go-Live in sinkenden Conversion-Rates oder SEO-Rankings bemerkbar macht.
Die praktikablere Herangehensweise: Die Datenquelle wird pro Entität und teils sogar pro Feld bestimmt – nicht pauschal für das gesamte Projekt.
Shopware 6 als Quelle für Commerce-relevante Daten
Für ein Einkanal-Setup mit bestehendem Shopware-Betrieb liegen typischerweise folgende Daten im Shopsystem vollständig vor:
- Artikel, Kategorien und Varianten
- Kunden und Adressen
- SEO-relevante Metadaten und Medien
Bei Multichannel-Betrieb – dem PlentyONE-Regelfall – gilt das nur eingeschränkt: Marktplatz-exklusive, inaktive oder ausgelaufene Artikel sowie reine Marktplatz-Käufer ohne Shop-Bestellung erscheinen im Shop-Katalog gar nicht erst. Für diese Fälle bleibt PlentyONE weiterhin die einzige verfügbare Quelle. Die Bestellhistorie selbst bleibt im Multichannel-Fall ebenfalls PlentyONE-geführt, da das Shopsystem nur Aufträge des eigenen Sales Channels kennt.
Bestimmte Datenklassen liegen unabhängig vom Setup ausschließlich im ERP: Lagerbestände und Wareneingänge, Einkaufspreise und Lieferantendaten sowie Buchhaltungsbelege sind reine ERP-Domänen ohne direkten Shop-Bezug.
Datenklassen im Setup-Vergleich
| Datentyp | Einkanal-Setup | Multichannel-Setup |
|---|---|---|
| Artikel, Kategorien, Varianten | Shopsystem | Shopsystem, ergänzt aus PlentyONE |
| Kunden & Adressen | Shopsystem | Shopsystem, ergänzt aus PlentyONE |
| Bestellhistorie | Shopsystem | PlentyONE (führend) |
| Lagerbestände & Wareneingänge | PlentyONE | PlentyONE |
| Einkaufspreise & Lieferantendaten | PlentyONE | PlentyONE |
| Buchhaltungsbelege | PlentyONE | PlentyONE |
Als Faustregel gilt: Alles, was originär transaktions- oder artikelbezogen ist und im Shop-Kontext vollständig gepflegt wird, wird aus dem Shopsystem bezogen. Alles, was ausschließlich ERP-seitige Geschäftslogik betrifft – oder im Shop nur teilweise vorliegt –, bleibt bei PlentyONE.
Ein Hinweis zur Übertragbarkeit dieser Methodik auf andere Plattformen: Magento ist ebenfalls selbst gehostet und damit grundsätzlich gleichwertig als sekundäre Datenquelle geeignet, erfordert aber durch seine EAV-Datenstruktur (Entity-Attribute-Value) einen höheren Aufwand im Transform-Schritt, da Attributwerte dort nicht flach, sondern relational über mehrere Tabellen verteilt vorliegen. Shopify dagegen bringt als SaaS-Plattform eigene API-Rate-Limits mit – der Entlastungseffekt bleibt bestehen, fällt aber geringer aus, weil auch das sekundäre System selbst gedrosselt ist. Für dieses Cluster bleibt Shopware 6 der beschriebene Referenzfall, weil das schlanke API-Modell die technische Umsetzung am direktesten macht.
Golden Record richtig verstehen
„Shopware ist der Golden Record“ wäre eine gefährliche Vereinfachung. Golden Record bedeutet in diesem Kontext nicht, dass ein System pauschal für alle Daten führend ist, sondern dass für jede Entität und jedes Feld einzeln entschieden wird, welches System die verlässlichere, aktuellere Quelle darstellt. Bei Artikeltexten und SEO-Daten ist das häufig das Shopsystem; bei Lagerbeständen und Einkaufspreisen fast immer das ERP.
Diese Entscheidung sollte dokumentiert und nicht implizit im Code verteilt werden – nur so bleibt nachvollziehbar, warum ein bestimmtes Feld aus welcher Quelle stammt, wenn Monate später Rückfragen zur Datenherkunft auftauchen. Ein einfaches, aber wirksames Vorgehen: eine tabellarische Entity-Ownership-Matrix, die für jede relevante Entität (Artikel, Kategorie, Kunde, Bestellung, Preis, Bestand) das führende System sowie etwaige Ausnahmen dokumentiert. Diese Matrix wird zum zentralen Referenzdokument für alle am ETL-Prozess Beteiligten – von der Entwicklung bis zur fachlichen Abnahme.
Welche Datenquelle ist für welche Entität führend?
Die folgende Faustregel hat sich in der Praxis bewährt: Alles, was originär transaktions- oder artikelbezogen ist und im Shop-Kontext vollständig gepflegt wird, kommt aus dem Shopsystem. Alles, was ausschließlich ERP-seitige Geschäftslogik betrifft – oder im Shop nur teilweise vorliegt –, bleibt beim ERP.
Wichtige Einschränkung zur Plattformwahl: Ausschlaggebend für die Eignung als sekundäre Datenquelle ist nicht das konkrete Produkt, sondern ob das Shopsystem selbst gehostet wird und damit keinen herstellerseitig auferlegten API-Limits unterliegt. Bei selbst gehosteten Systemen begrenzt allein die eigene Infrastruktur das Anfragevolumen. Bei SaaS-Plattformen bleibt der Entlastungseffekt zwar bestehen, fällt aber geringer aus, weil das sekundäre System seinerseits gedrosselt sein kann.
Diese Substituierbarkeit ist bewusst so konzipiert: Die Methodik ist nicht an Shopware als konkretes Produkt gebunden, sondern an die Eigenschaft „selbst gehostet, ohne herstellerseitige API-Limits“. Ein Wechsel der sekundären Datenquelle wäre grundsätzlich auch im laufenden Migrationsprozess mit vertretbarem Anpassungsaufwand möglich, sofern das alternative System dieselbe Eigenschaft erfüllt. Da Shopware 6 in diesem Cluster den Referenzfall bildet, konzentrieren sich die weiteren Ausführungen konsequent darauf.
ETL-Merging vor dem Odoo-Import
Der technische Ablauf folgt einem klaren, reproduzierbaren Muster:
Extract → Normalize → Merge → Validate → Load
Daten aus PlentyONE und dem Shopsystem werden getrennt extrahiert, in ein gemeinsames Zwischenformat normalisiert, entlang der zuvor festgelegten Entity-Ownership-Regeln zusammengeführt, validiert und erst danach über die Odoo-API importiert. Entscheidend ist dabei die Nachvollziehbarkeit der Datenprovenienz: Für jeden importierten Datensatz sollte erkennbar bleiben, aus welchem Quellsystem welches Feld stammt – nicht zuletzt, um spätere Datenkonflikte gezielt zurückverfolgen zu können.
Für den eigentlichen Import in Odoo kommt bewusst nicht eine Folge einzelner Einzelaufrufe zum Einsatz, sondern die batchfähige load()-Methode über die JSON-2 API. Sie verarbeitet mehrere Datensätze pro Aufruf und referenziert sie über externe IDs – dieselbe Idempotenz-Logik, die auch bei der reinen ERP-Migration zum Einsatz kommt. Dadurch lässt sich der Merge-Prozess in einer geeigneten Testumgebung wiederholt ausführen, ohne im Zielsystem Dubletten zu erzeugen, was bei einer Datenquelle aus zwei unterschiedlichen Systemen besonders wertvoll ist.
Datenbereinigung vor Odoo
Bevor zusammengeführte Daten importiert werden, müssen typische Qualitätsprobleme identifiziert werden:
- Konflikte zwischen Quellen: unterschiedliche Werte für dasselbe Feld in PlentyONE und Shopsystem
- Priorisierung: klare, dokumentierte Entscheidung, welche Quelle im Konfliktfall gewinnt
- Dubletten: identische Artikel oder Kunden, die in beiden Systemen unabhängig voneinander angelegt wurden
Diese Bereinigung gehört strukturell vor den Import, nicht in eine nachträgliche Korrekturschleife in Odoo – jede nachträgliche Korrektur in einem bereits produktiven ERP-System ist deutlich aufwendiger als eine Bereinigung im Vorfeld.
Wie diese Datenkonsolidierung in den Gesamtablauf einer ERP-Migration eingebettet ist, beschreibt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zu Shopware als Datenquelle
Bedeutet „Shopware als Datenquelle“, dass Shopware künftig das führende System wird?
Nein. Diese Rolle ist ausschließlich auf die Migrationsphase begrenzt und betrifft nur bestimmte Datenklassen. PlentyONE bleibt bis zum finalen Cutover durchgehend Master-System; nach der Migration übernimmt Odoo diese Rolle für ERP-Daten, während Shopware Frontend-Daten führt.
Können auch andere Shopsysteme als Shopware diese Rolle übernehmen?
Grundsätzlich ja, sofern das System selbst gehostet wird und keinen einschränkenden API-Limits eines Drittanbieters unterliegt. Die beschriebene Methodik ist an diese Eigenschaft gebunden, nicht an ein bestimmtes Produkt.
Wie stellen wir sicher, dass keine Daten doppelt oder widersprüchlich migriert werden?
Durch eine dokumentierte Entity-Ownership-Regel, die für jede Datenklasse eindeutig festlegt, welches System im Konfliktfall die führende Quelle ist – kombiniert mit einer systematischen Validierung vor dem eigentlichen Import in Odoo.
Architektur-Audit für verteilte Datenquellen
Welche Ihrer Daten tatsächlich bereits vollständig im Shopsystem vorliegen und wo PlentyONE zwingend die einzige Quelle bleibt, lässt sich nur anhand einer konkreten Systemanalyse bestimmen. Genau das leisten wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie Ihre Datenquellen-Architektur technisch bewerten – kostenfrei und unverbindlich.
Jetzt Datenarchitektur-Analyse anfordern
„Wir wissen nicht, wie viele unserer Daten überhaupt doppelt gepflegt werden.“ Diese Übersicht liefert das Audit als erste, klare Bestandsaufnahme – bevor überhaupt über ein Migrationsprojekt entschieden wird.
„Unsere Shopware-Daten sind über Jahre unterschiedlich gepflegt worden – ist das ein Problem?“ Das ist einer der häufigsten Ausgangspunkte. Die Entity-Ownership-Matrix und die anschließende Datenbereinigung sind genau dafür gedacht, solche historisch gewachsenen Unterschiede vor dem Import sichtbar zu machen und aufzulösen.
✔ kostenlos ✔ unverbindlich ✔ entitätsgenaue Datenanalyse ✔ Antwort innerhalb von 24 Stunden
Lukas Ehrenberg
Lukas Ehrenberg ist die operative Speerspitze der HQ GmbH, wenn es um komplexe und großvolumige E-Commerce-Infrastrukturen geht. In zahlreichen Projekten verantwortet er die technische Umsetzung von tiefgreifenden ERP-Migrationen – insbesondere den Wechsel von Legacy-Systemen wie PlentyONE hin zu modularen Plattformen wie Odoo. Gepaart mit seiner tiefen Shopware-Expertise baut er skalierbare Enterprise-Infrastrukturen auf. Seine enorme praktische Erfahrung macht ihn zum primären Ansprechpartner für Marken, die ein risikofreies, datensicheres und ausfallfreies Replatforming anstreben.
Als technischer Betreuer eines hochverfügbaren Enterprise-Shopware-Clusters mit über 14 Servern beherrscht er Lastverteilung und Systemstabilität im Hochfrequenzbereich. Seine besondere technische Expertise liegt in der architektonischen Neuausrichtung von E-Commerce-Ökosystemen: Er kombiniert fundiertes Wissen über die sichere Datenextraktion aus restriktiven Systemen (wie der PlentyONE REST-API unter strikter Optimierung von Rate-Limits) mit der performanten, asynchronen Anbindung an moderne ERP-Lösungen wie Odoo. Damit garantiert er nahtlose Systemübergänge selbst bei höchsten Transaktionsvolumina.
