PlentyONE Odoo Datenmigration: Welche Daten müssen übernommen werden?
Muss wirklich alles mit? Nein. Die Frage bei einer ERP-Migration lautet nicht „Wie migrieren wir alles?“, sondern: Was gehört ins neue Live-System, was ins Archiv, und was war schon im Altsystem eine Altlast?
Diese Entscheidung fällt vor Projektbeginn, nicht während der Extraktion. Sie bestimmt direkt, wie viel Volumen über das begrenzte PlentyONE-Kontingent laufen muss und ob Sie bestehende Datenqualitätsprobleme unverändert ins neue System kopieren.
Diese Seite klärt den Umfang. Wie die ausgewählten Daten anschließend technisch korrekt auf das Odoo-Datenmodell abgebildet werden, behandelt Datenmapping bei der ERP-Migration.
Migrations-Scope definieren
Eine saubere Scope-Definition unterscheidet drei Datenkategorien:
- Stammdaten: Artikel, Kategorien, Kunden, Konditionen – aktuell und dauerhaft im Live-Betrieb benötigt.
- Bewegungsdaten: laufende Bestände, offene Bestellungen, aktuelle Preise – ebenfalls zwingend im Live-System.
- Historische Daten: abgeschlossene Bestellungen, archivierte Belege, ausgelaufene Artikel – benötigt für Auditfähigkeit und Kundenservice, aber nicht zwingend im selben operativen Datenbestand wie Stammdaten.
Diese drei Kategorien unterscheiden sich nicht nur inhaltlich, sondern auch in ihrer technischen Behandlung: Stammdaten werden typischerweise vollständig und mit hoher Priorität importiert, da sie den täglichen Betrieb unmittelbar tragen. Bewegungsdaten erfordern eine sorgfältige Delta-Logik, da sie sich bis unmittelbar vor dem Go-Live ändern können. Historische Daten lassen sich dagegen meist mit geringerem Zeitdruck migrieren, benötigen aber besondere Sorgfalt bei unveränderten Preisen und Steuersätzen, damit vergangene Rechnungsbeträge nicht nachträglich verfälscht werden.
Diese Unterscheidung ist keine akademische Übung: Sie bestimmt direkt, wie viel Datenvolumen tatsächlich über die begrenzten API-Kontingente von PlentyONE extrahiert werden muss (siehe PlentyONE API Limits umgehen) und wie lange die Migrationsphase dauert.
Ein praktisches Vorgehen zur Scope-Definition beginnt mit einer einfachen Kategorisierung aller relevanten Datenklassen in eine von drei Gruppen: „zwingend im Live-System“, „archivierungsfähig, aber abrufbar“ und „nicht mehr geschäftsrelevant“. Diese Einordnung sollte gemeinsam mit den fachlich Verantwortlichen erfolgen, nicht allein von der technischen Projektleitung – nur die Fachabteilungen kennen die tatsächliche geschäftliche Relevanz einzelner historischer Datenbestände.
Must-Have vs. Archiv
Für den laufenden Betrieb typischerweise zwingend erforderlich:
- Kategorien und Hersteller
- Attribute und Varianten
- Produktbilder
- Kunden und Adressen
- Steuerinformationen
- aktuelle Preise
- aktueller Lagerbestand
- relevante historische Bestellungen (für Retouren, Kundenservice, Auditfähigkeit)
Nicht jedes Projekt muss zwingend alle dieser Kategorien in vollem Umfang übernehmen – ausgelaufene Marktplatz-Sonderartikel oder sehr alte, geschäftlich irrelevante Bestellhistorie lassen sich je nach gesetzlichen Aufbewahrungspflichten teils separat archivieren, statt sie vollständig in das neue Live-System zu übernehmen.
Eine differenziertere Betrachtung der einzelnen Kategorien:
Kategorien und Hersteller bilden das Rückgrat der Navigationsstruktur und sollten grundsätzlich vollständig und in korrekter Hierarchie übernommen werden – ein unvollständiger Kategoriebaum wirkt sich unmittelbar auf Navigation und SEO-Struktur im Frontend aus.
Attribute und Varianten sind besonders fehleranfällig, weil sie Beziehungen zwischen Eltern- und Kindobjekten abbilden. Fehlt bei der Migration die korrekte Zuordnung, entstehen Varianten „ohne Elternprodukt“ – ein klassischer Importfehler, der den betroffenen Datensatz blockiert, statt ihn fehlerhaft durchzulassen.
Produktbilder werden aus Performancegründen typischerweise getrennt und asynchron zum eigentlichen Stammdatenimport übertragen, um die Dauer der Kernmigration nicht unnötig zu verlängern.
Kunden und Adressen benötigen besondere Sorgfalt bei der Zusammenführung von Rechnungs- und Lieferadressen, insbesondere wenn ein Kunde über mehrere Bestellungen hinweg unterschiedliche Adressen verwendet hat.
Steuerinformationen entscheiden direkt über die Rechtssicherheit künftiger Rechnungen – hier gilt eine niedrige Fehlertoleranz, da eine falsche Fiskalposition zu fehlerhafter Steuerberechnung führt.
Shopware- und ERP-Daten richtig abgrenzen
Für Händler mit bestehendem Shopware-6-Frontend stellt sich zusätzlich die Frage, welches System für welche Entität führend ist. Artikel-, Kategorie- und Kundendaten liegen bei bestehendem Shopbetrieb häufig bereits vollständig und aktuell im Shopsystem vor; Lagerbestände, Einkaufspreise und Buchhaltung bleiben reine ERP-Domäne. Die konkrete Zuordnung nach Entität und Setup (Einkanal vs. Multichannel) behandeln wir vertieft in Shopware als Datenquelle nutzen.
Diese Abgrenzung hat unmittelbare Auswirkung auf den Scope: Datenklassen, die bereits im Shopsystem vollständig vorliegen, müssen nicht zusätzlich über die begrenzten PlentyONE-API-Kontingente extrahiert werden. Wie diese Entlastung konkret funktioniert und wo ihre Grenzen liegen, zeigt PlentyONE API Limits umgehen.
Historische Daten und Auditfähigkeit
Ein wesentlicher Vorteil einer vollständigen Übernahme relevanter historischer Bestellungen: Odoo verwaltet Geschäftspartner, Bestellungen, Rechnungen und Zahlungshistorien in einem zentralen, revisionssicheren Modell. Das erleichtert spätere Betriebsprüfungen erheblich, da Steuerberater und Wirtschaftsprüfer auf eine lückenlose Historie im neuen System zugreifen können, statt manuell zwischen Alt- und Neusystem abzugleichen.
Odoo verfolgt dabei einen hochintegrierten Ansatz: Unternehmen und Ansprechpartner werden in einem gemeinsamen Parent-Child-Modell verwaltet. Beim Import wird zunächst das übergeordnete Unternehmen angelegt, danach werden die zugehörigen Ansprechpartner verknüpft. Die bisherige Kundennummer aus PlentyONE bleibt dabei als eindeutige Referenz erhalten – ein wichtiger Anknüpfungspunkt für den Kundenservice, der sich weiterhin auf gewohnte Kundennummern beziehen kann. Anhand von Umsatzsteuer-ID und Herkunftsland weist das System automatisch die passende Fiskalposition zu, etwa Inland, EU oder Drittland – eine Voraussetzung dafür, dass spätere Rechnungen rechtssicher erzeugt werden. Auch individuelle Zahlungsziele und B2B-Kreditlimits werden exakt übernommen.
Die Importreihenfolge folgt dabei einer festen Logik, die Datenbank-Inkonsistenzen verhindert: Produkte → Kunden → Bestellungen → Positionen → Lieferungen → Rechnungen.
Wichtig für die technische Umsetzung: Historische Preise und Steuersätze werden unverändert übernommen, eine automatische Neuberechnung durch das ERP-System wird für diese Altdaten gezielt unterdrückt – andernfalls würden sich rückwirkend Rechnungsbeträge verändern. Bereits ausgelieferte Bestellungen dürfen zudem keine neuen Lagerbewegungen im neuen System erzeugen; gelieferte und abgerechnete Mengen werden exakt mit den historischen Werten synchronisiert, sodass der Altauftrag sofort als abgeschlossen gilt. Noch offene Aufträge werden dagegen nach dem Go-Live unterbrechungsfrei im neuen ERP-System weitergeführt.
Datenqualität vor Datenmenge
Historisch gewachsene Systeme enthalten fast immer Altlasten, die vor der Migration bereinigt werden sollten, statt sie unverändert zu übernehmen:
- Dubletten: mehrfach angelegte Artikelnummern oder Kundendatensätze
- Verwaiste Relationen: Produkte, die auf bereits gelöschte Kategorien verweisen
- Inkonsistente Varianten: Varianten ohne zugehöriges Elternprodukt
- Historische Fehler: negative Lagerbestände, fehlende Pflichtfelder
Diese Probleme lassen sich in einem sauberen ETL-Prozess über systematische Validierungsschritte erkennen, bevor sie in das neue System gelangen – deutlich günstiger, als sie nachträglich in einem bereits produktiven Odoo-System zu korrigieren. Eine einfache, aber wirksame Praxis: Vor jedem Testlauf werden Dubletten-Prüfungen direkt auf Datenbankebene ausgeführt, etwa auf doppelte Artikelnummern oder E-Mail-Adressen. Jeder Treffer wird dokumentiert und vor dem nächsten Lauf entweder bereinigt oder bewusst als Ausnahme freigegeben – niemals stillschweigend übernommen.
Clean-Slate-Strategie
In manchen Fällen ist es fachlich sinnvoller, nicht jede historische Altlast mitzunehmen, sondern gezielt einen sauberen Neustart für bestimmte Datenklassen zu wählen – etwa bei stark fragmentierten oder über Jahre inkonsistent gepflegten Kategoriebäumen. Das ist jedoch keine pauschale Empfehlung, „einfach alles zu löschen“: Die Entscheidung sollte fachlich pro Datenklasse getroffen werden, mit klarer Begründung, warum eine Neuanlage der Migration einer fehlerhaften Historie vorzuziehen ist.
Ein bewährtes Vorgehen: Für jede in Betracht gezogene Clean-Slate-Entscheidung wird schriftlich dokumentiert, welches konkrete Datenqualitätsproblem sie löst, welche Alternative (etwa eine aufwendigere Bereinigung der Altdaten) verworfen wurde und wer diese Entscheidung fachlich verantwortet. Diese Dokumentation verhindert, dass Monate später unklar ist, warum bestimmte historische Daten im neuen System fehlen.
Die Scope-Definition steht am Anfang des Projekts. Was danach folgt – Mapping, Testlauf, Cut-over und Monitoring –, zeigt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zum Migrationsumfang
Müssen wirklich alle historischen Bestellungen migriert werden?
Nicht zwingend alle, aber alle mit fortdauernder Relevanz für Kundenservice, Retouren oder gesetzliche Aufbewahrungspflichten. Reine Archivdaten ohne diese Relevanz lassen sich häufig separat aufbewahren, statt sie vollständig in das neue Live-System zu überführen.
Wie entscheiden wir, ob eine Datenklasse für eine Clean-Slate-Strategie geeignet ist?
Immer dann, wenn die bestehende Datenqualität so schlecht ist, dass eine Bereinigung der Altdaten aufwendiger wäre als eine kontrollierte Neuanlage – und wenn keine gesetzlichen oder fachlichen Gründe für eine lückenlose historische Übernahme bestehen.
Wer sollte die Scope-Entscheidung treffen – IT oder Fachabteilung?
Beide gemeinsam. Die IT kennt den technischen Aufwand pro Datenklasse, die Fachabteilung (Vertrieb, Buchhaltung, Kundenservice) kennt die tatsächliche geschäftliche Relevanz der jeweiligen Daten. Eine einseitig getroffene Entscheidung führt regelmäßig zu Fehleinschätzungen in die eine oder andere Richtung.
Migrations-Scope definieren lassen
Welche Ihrer Daten tatsächlich must-have sind und welche sich sinnvoll archivieren lassen, zeigt eine strukturierte Bestandsaufnahme Ihrer konkreten Systeme. Genau das ist Teil unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie Ihren Migrations-Scope technisch definieren – kostenfrei und unverbindlich.
„Wir befürchten, dass eine vollständige Migration unnötig lange dauert.“ Deshalb steht die Scope-Definition am Anfang, nicht am Ende. Jede Datenklasse, die nachweislich nicht ins Live-System gehört, verkürzt die Extraktion und entlastet das API-Kontingent.
✔ kostenlos ✔ unverbindlich ✔ konkrete Scope-Checkliste ✔ 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.
