PlentyONE Odoo Migration Fehler: Die kritischsten Fallstricke beim ERP-Wechsel
Die teuersten Migrationsfehler sind nicht die, die den Import abbrechen lassen. Es sind die, die stillschweigend durchlaufen: ein Datensatz, der verworfen wird, ohne dass es jemand protokolliert. Eine Variante, die am falschen Elternprodukt hängt. Ein Steuersatz, der auf allen Folgerechnungen falsch berechnet wird.
Diese Fehler werden häufig nicht als unmittelbar sichtbarer technischer Fehler erkannt. Sie tauchen in einer Kundenrückfrage drei Wochen nach dem Go-Live auf, oder bei der nächsten Betriebsprüfung. Dieser Beitrag zeigt, wo sie entstehen und wie man sie im Dry Run findet statt im Livebetrieb.
Die beschriebenen Fehlerbilder sind keine hypothetischen Randfälle, sondern wiederkehrende Muster – meist dort, wo Zeitdruck oder fehlende Systematik einzelne Prüfschritte überspringen lassen.
Silent Data Loss und unerkannte API-Fehler
Der gefährlichste Fehlertyp bei einer Migration ist nicht der laute, sondern der stille: ein Import, der scheinbar erfolgreich durchläuft, dabei aber einzelne Datensätze verwirft oder falsch verarbeitet, ohne dass dies auffällt. Feste Grundregeln verhindern das: keine stillen Fehler (Silent Errors), keine unterdrückten Exceptions, vollständiges Logging jedes Vorfalls und eine automatische Retry-Strategie mit Verschiebung nicht verarbeitbarer Nachrichten in eine Dead Letter Queue statt eines stillen Verwurfs.
Die Konsequenz für die Projektpraxis: Diese Fehler müssen im Dry Run entdeckt werden, nicht erst nach dem Go-Live. Ein Migrationsprozess ohne strukturiertes Logging und ohne automatisierte Validierungsberichte macht Silent Data Loss praktisch unsichtbar, bis ein Kunde oder ein Buchhalter eine Diskrepanz bemerkt.
Fehlerhaftes Datenmapping
Die häufigsten Mapping-Fehler entstehen nicht durch komplexe Sonderfälle, sondern durch einfache, aber folgenreiche Nachlässigkeiten:
- Doppelte SKUs: In vielen historisch gewachsenen Systemen kommen Artikelnummern versehentlich mehrfach vor. Die SKU dient als zentraler Business Key – Dubletten müssen vor dem Import identifiziert und bereinigt werden, da sie sonst die Variantenzuordnung im ERP zerstören.
- Fehlende Relationen: Verweisen Produkte auf bereits gelöschte Kategorien oder existieren Varianten ohne übergeordnetes Elternprodukt, bricht der Import dieses spezifischen Datensatzes ab. Ein sauberer ETL-Prozess protokolliert diesen Fehler zur manuellen Nachbearbeitung, ohne die Gesamtmigration zu stoppen.
- UUID-Konflikte: Das Shopware-Frontend arbeitet intern mit UUIDs. In der hier beschriebenen Referenzarchitektur dienen diese als Business Key und werden deshalb unverändert übernommen statt neu generiert – andernfalls brechen Kategoriebäume und Medienverknüpfungen. Ob eine UUID in Ihrem Setup diese Referenzfunktion übernimmt, gehört in die Mapping-Analyse.
- Falsche Fiskalpositionen: Eine fehlerhafte Zuordnung von Herkunftsland oder Umsatzsteuer-ID führt zu einer fehlerhaften Steuerberechnung in nachfolgenden Rechnungen – ein Fehler, der oft erst bei einer externen Prüfung auffällt.
- Vergessene Kundenpasswörter: Werden bestehende Zugangsdaten nicht korrekt im Shopware-Frontend belassen, zwingt das sämtliche Kunden zu einem Passwort-Reset – ein vermeidbarer, aber folgenreicher Reibungspunkt beim Go-Live.
Die Mapping-Logik über Business Keys und Surrogate Keys erklären wir in Datenmapping bei der ERP-Migration.
Shopware- und Checkout-Probleme
Eine synchrone Abhängigkeit zwischen Checkout und ERP-System ist eine der häufigsten Ursachen für Instabilität während einer Migration: Verzögert sich die ERP-Antwort, verzögert sich unmittelbar auch der Checkout. Bestellungen, Retouren, Stornos und Teillieferungen sind dabei besonders anfällige Fälle, da sie mehrstufige Statusänderungen erfordern, die bei einer instabilen Schnittstelle inkonsistent bleiben können.
Vor dem produktiven Go-Live sollte deshalb ein User Acceptance Test (UAT) gezielt diese Randfälle abdecken – nicht nur den Standardfall einer einfachen, vollständig bezahlten Bestellung.
API Timeout und Rate Limits
Temporäre HTTP-Fehler wie 429 (Rate Limit) oder 503 (Serverüberlastung) dürfen nicht zum Abbruch der Migration führen. Die JSON-2 API von Odoo selbst führt keine automatischen Retries aus – diese Verantwortung liegt vollständig beim aufrufenden Client. Eine belastbare Implementierung verwendet definierte Timeouts sowie Exponential Backoff mit Jitter; HTTP 429 sowie die Serverfehler 500, 502, 503 und 504 gelten dabei grundsätzlich als Kandidaten für einen automatischen Retry – vorausgesetzt, die wiederholte Operation ist nachweislich idempotent. Bei nicht-idempotenten Schreiboperationen muss vor einem Retry zusätzlich geprüft werden, ob der ursprüngliche Request das Zielsystem bereits erfolgreich verändert hat. Die konkreten PlentyONE-spezifischen Limits und ihre Steuerung behandeln wir in PlentyONE API Limits umgehen.
Fehlende QA
Ein Migrationsprojekt ohne strukturierte Testpyramide ist eines der größten vermeidbaren Risiken. Die empfohlene Abfolge durchläuft mehrere Stufen: Unit Tests → Integration Tests → API Tests → Load Tests → Smoke Tests → Go-Live Tests. Jede dieser Stufen deckt unterschiedliche Fehlerklassen ab – von einzelnen Funktionsfehlern über fehlerhafte Systemintegration bis zu Performance-Problemen unter realer Last. Wird eine dieser Stufen übersprungen, verschiebt sich die Fehlerentdeckung tendenziell in Richtung Livebetrieb – mit entsprechend höheren Kosten und Risiken.
Ein praktischer Indikator für unzureichende QA: Wenn ein Projektteam den Dry Run als „letzten Test vor dem Go-Live“ statt als integralen, mehrfach durchlaufenen Bestandteil der gesamten Entwicklungsphase versteht, fehlt in der Regel die notwendige Testtiefe. Ein Dry Run ist kein einmaliges Ereignis kurz vor dem Stichtag, sondern ein wiederholt durchlaufener Prozess über die gesamte Projektlaufzeit.
Architekturplanung
Ein Großteil vermeidbarer Migrationsfehler entsteht bereits vor der eigentlichen Datenmigration, in der Architekturplanung selbst:
- Falsche Systemverantwortlichkeiten: Wird nicht klar definiert, welches System für welche Daten führend ist, entsteht doppelte Stammdatenpflege mit widersprüchlichen Datenständen.
- Synchrone Schnittstellen: Eine blockierende ERP-Abhängigkeit im Checkout gefährdet die Verfügbarkeit des gesamten Shops. Die belastbare Alternative beschreiben wir in Odoo Shopware 6 Connector.
- Fehlende Idempotenz: Ohne stabile externe IDs und eine entsprechend konzipierte Import-Logik drohen bei jedem wiederholten Lauf – etwa nach einem Netzwerkfehler – Dubletten statt sauberer Aktualisierungen.
Performance-Fallstricke in der Zielinfrastruktur
Neben reinen Datenfehlern führt auch eine unzureichend dimensionierte Zielinfrastruktur regelmäßig zu Problemen, die fälschlich als Datenfehler interpretiert werden. Eine Standardinstallation von Odoo ist nicht automatisch für Kataloge mit mehreren hunderttausend Produkten vorkonfiguriert. Relevante, workloadabhängig zu validierende Stellschrauben:
- PostgreSQL-Parameter wie
max_connections,shared_buffersundwork_memmüssen an den verfügbaren Arbeitsspeicher der Server-Infrastruktur angepasst werden – Standardwerte sind für große Migrationsprojekte häufig zu konservativ. - Odoo-Worker-Anzahl: Als Ausgangspunkt gilt die Faustregel (Anzahl CPU-Kerne × 2) + 1, die tatsächlich passende Anzahl muss aber anhand von CPU-Auslastung, RAM, Request-Profil und Parallelität im konkreten Betrieb validiert werden. Longpolling-Worker sollten dabei separat betrieben werden.
- Reverse Proxy: Der Einsatz von NGINX oder HAProxy als Reverse Proxy vor der Odoo-Instanz ist üblich.
Ein System, das während der Migration durch fehlende Ressourcen an seine Grenzen stößt, erzeugt Symptome, die leicht mit echten Datenfehlern verwechselt werden – etwa Timeouts, die tatsächlich auf zu wenige Worker statt auf ein fehlerhaftes Mapping zurückgehen. Eine belastbare Fehleranalyse prüft deshalb immer beide Ebenen: die Datenqualität und die Infrastrukturdimensionierung.
Datenschutz als übersehenes Risiko
Ein Migrationsprojekt verarbeitet zwangsläufig hochsensible Unternehmens- und Kundendaten. Werden Testumgebungen mit unveränderten Produktivdaten befüllt, entsteht ein DSGVO-relevantes Risiko, das in der technischen Planung leicht übersehen wird. Personenbezogene Daten sollten deshalb vor dem Einsatz in Staging-Umgebungen pseudonymisiert werden, und temporäre CSV-Exporte oder SQL-Dumps sollten einem dokumentierten, fristgebundenen Löschkonzept nach Projektabschluss unterliegen.
Diese Fehlerbilder verteilen sich über den gesamten Migrationsablauf. Welche Phasen das im Einzelnen sind und wo jeweils geprüft wird, zeigt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zu Migrationsfehlern
Wie erkennen wir Silent Data Loss, wenn er per Definition unbemerkt bleibt?
Durch systematisches, automatisiertes Logging und Validierungsberichte nach jedem Testlauf – nicht durch punktuelle manuelle Kontrolle. Jeder Import sollte eine vollständige, auswertbare Zusammenfassung liefern: wie viele Datensätze verarbeitet, wie viele übersprungen und aus welchem Grund.
Reicht ein einzelner Dry Run vor dem Go-Live aus?
In der Regel nicht. Da sich Produktivdaten bis zum Cutover weiter verändern, sollte mindestens ein weiterer Testlauf kurz vor dem eigentlichen Go-Live erfolgen, um neu entstandene Datenqualitätsprobleme rechtzeitig zu erkennen.
Was, wenn während der Migration ein kritischer Fehler auftritt, den wir nicht sofort lösen können?
Genau für diesen Fall sollte vor dem Cutover ein dokumentierter Rollback-Plan vorliegen. Da PlentyONE bis zum finalen Cutover durchgehend Master-System bleibt, ist ein Zurückschalten auf das Altsystem technisch grundsätzlich möglich.
Sind diese Fehlerbilder spezifisch für PlentyONE, oder träfen sie auch auf andere Quellsysteme zu?
Die konkreten Beispiele stammen aus der PlentyONE-zu-Odoo-Migration, die zugrunde liegenden Fehlermuster – doppelte Schlüssel, fehlende Idempotenz, synchrone Abhängigkeiten, unzureichende Tests – sind jedoch typische Risiken jeder ERP-Migration, unabhängig vom konkreten Quellsystem.
Risikofreies E-Commerce-Replatforming anfragen
Die meisten dieser Fehler lassen sich vollständig vermeiden, wenn Architektur, Datenmapping und Testkonzept vor Projektbeginn sauber geplant werden. Genau diese Prüfung leisten wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie Ihr Migrationsrisiko technisch bewerten – kostenfrei und unverbindlich.
„Wir haben schon einmal ein Migrationsprojekt erlebt, das schiefgelaufen ist.“ Dann kennen Sie das Muster: Der Fehler war vorher da, nur hat ihn niemand gesucht. Eine strukturierte Testpyramide und ein dokumentierter Rollback-Plan sind genau die zwei Dinge, die in solchen Projekten typischerweise gefehlt haben.
✔ kostenlos ✔ unverbindlich ✔ Testkonzept statt Hoffnungsprinzip ✔ Antwort innerhalb von 24 Stunden
Daniel Vogel
Daniel Vogel ist der technische Leiter (Head of Development) der HQ GmbH. Mit seiner tiefen Expertise in Systemarchitektur und Core Web Vitals führt er das In-House-Entwicklerteam bei anspruchsvollen E-Commerce-Projekten. Sein Spezialgebiet sind komplexe Replatforming-Szenarien, insbesondere die sichere Migration von Magento oder Shopify zu zukunftssicheren Shopware-Plattformen.
Darüber hinaus ist er der operative Lead für technische Notfall-Umzüge und Krisenmanagement. Wenn bestehende Systeme unter Last zusammenbrechen oder veraltete Code-Strukturen das Wachstum blockieren, konzipiert und implementiert er rettende, hochperformante Architekturen.
