PlentyONE Odoo Migration Errors: The most critical pitfalls during ERP migration
The most costly migration errors aren't the ones that cause the import to abort. They're the ones that go through silently: a data record that's discarded without anyone logging it; a variant that's linked to the wrong parent product; a tax rate that's calculated incorrectly on all subsequent invoices.
These errors are often not recognized as immediately visible technical faults. They surface during a customer inquiry three weeks after go-live, or during the next operational audit. This article shows where they originate and how to find them in a dry run rather than during live operation.
The described error patterns are not hypothetical marginal cases, but recurring patterns – mostly where time pressure or lack of systematic approach causes individual test steps to be skipped.
Silent data loss and undetected API errors
The most dangerous type of error during a migration is not the loud one, but the silent one: an import that appears to complete successfully, but discards or incorrectly processes individual data records without being noticed. Solid ground rules prevent this: no silent errors, no suppressed exceptions, complete logging of every incident, and an automatic retry strategy that moves unprocessable messages to a dead letter queue instead of silently discarding them.
The consequence for project practice: These errors must be discovered during the dry run, not after go-live. A migration process without structured logging and automated validation reports makes silent data loss virtually invisible until a customer or accountant notices a discrepancy.
Faulty data mapping
The most common mapping errors do not arise from complex special cases, but from simple yet consequential oversights:
- Duplicate SKUs: In many historically grown systems, article numbers are accidentally duplicated. The SKU serves as the central business key – duplicates must be identified and removed before import, otherwise they will disrupt the variant assignment in the ERP system.
- Missing relationships: If products reference categories that have already been deleted, or if variants exist without a parent product, the import of that specific data record will fail. A clean ETL process will log this error for manual correction without stopping the overall migration.
- UUID conflicts: The Shopware frontend uses UUIDs internally. In the reference architecture described here, these serve as business keys and are therefore adopted unchanged instead of being regenerated – otherwise, category trees and media links would break. Whether a UUID in your setup fulfills this reference function should be included in the mapping analysis.
- Incorrect fiscal positions: An incorrect assignment of country of origin or VAT ID leads to an incorrect tax calculation in subsequent invoices – an error that is often only noticed during an external audit.
- Forgotten customer passwords: If existing login data is not correctly retained in the Shopware frontend, this forces all customers to reset their passwords – an avoidable but consequential point of friction during the go-live.
We explain the mapping logic using business keys and surrogate keys in Data mapping during ERP migration.
Shopware and checkout problems
A synchronous dependency between the checkout and ERP systems is one of the most frequent causes of instability during a migration: If the ERP response is delayed, the checkout is immediately delayed as well. Orders, returns, cancellations, and partial deliveries are particularly vulnerable cases, as they require multi-stage status changes that can remain inconsistent with an unstable interface.
Therefore, before the productive go-live, a User Acceptance Test (UAT) should specifically cover these edge cases – not just the standard case of a simple, fully paid order.
API Timeout and Rate Limits
Temporary HTTP errors such as 429 (rate limit) or 503 (server overload) must not cause the migration to fail. Odoo's JSON-2 API itself does not perform automatic retries – this responsibility lies entirely with the calling client. A robust implementation uses defined timeouts and exponential backoff with jitter; HTTP 429 and server errors 500, 502, 503, and 504 are generally considered candidates for an automatic retry – provided the repeated operation is demonstrably idempotent. For non-idempotent write operations, it must be checked before a retry whether the original request has already successfully modified the target system. We discuss the specific PlentyONE limits and their management in [section/documentation]. Bypass PlentyONE API Limits.
Missing QA
A migration project without a structured testing pyramid is one of the biggest avoidable risks. The recommended sequence goes through several stages: Unit Tests → Integration Tests → API Tests → Load Tests → Smoke Tests → Go-Live TestsEach of these stages covers different classes of errors – from individual functional errors and faulty system integration to performance problems under real-world load. Skipping one of these stages tends to shift error detection towards live operation – with correspondingly higher costs and risks.
A practical indicator of inadequate QA: If a project team understands the dry run as the "final test before go-live" instead of as an integral, repeatedly performed part of the entire development phase, the necessary testing depth is usually lacking. A dry run is not a one-off event shortly before the deadline, but a process repeated throughout the entire project lifecycle.
Architectural planning
A large proportion of avoidable migration errors occur even before the actual data migration, in the architectural planning itself:
- Incorrect system responsibilities: If it is not clearly defined which system is the leading system for which data, duplicate master data maintenance with contradictory data statuses will occur.
- Synchronous interfaces: A restrictive ERP dependency in the checkout process jeopardizes the availability of the entire shop. We describe the robust alternative in [link to relevant document]. Odoo Shopware 6 Connector.
- Lack of idempotence: Without stable external IDs and a suitably designed import logic, duplicates instead of clean updates are likely to occur with every repeated run – for example, after a network error.
Performance pitfalls in the target infrastructure
Besides pure data errors, an inadequately dimensioned target infrastructure also regularly leads to problems that are mistakenly interpreted as data errors. A standard Odoo installation is not automatically pre-configured for catalogs with several hundred thousand products. Relevant parameters to be validated based on workload include:
- PostgreSQL parameters How
max_connections,shared_buffersandwork_memomust be adjusted to the available memory of the server infrastructure – default values are often too conservative for large migration projects. - Odoo worker count: The rule of thumb is (number of CPU cores × 2) + 1, but the actual appropriate number must be validated in practice based on CPU utilization, RAM, request profile, and parallelism. Long-polling workers should be run separately.
- Reverse Proxy: The use of NGINX or HAProxy as a reverse proxy in front of the Odoo instance is common.
A system that reaches its limits during migration due to a lack of resources produces symptoms that are easily mistaken for genuine data errors – such as timeouts that are actually due to too few workers rather than faulty mapping. Therefore, a robust error analysis always examines both levels: data quality and infrastructure sizing.
Data privacy as an overlooked risk
A migration project inevitably involves processing highly sensitive company and customer data. Populating test environments with unaltered production data creates a GDPR-relevant risk that is easily overlooked in the technical planning. Therefore, personal data should be pseudonymized before being used in staging environments, and temporary CSV exports or SQL dumps should be subject to a documented, time-bound deletion policy after project completion.
These error patterns occur throughout the entire migration process. Our overview shows which phases these are and where checks are performed at each stage. Migration from PlentyONE to Odoo.
Frequently asked questions about migration errors
How do we detect silent data loss if, by definition, it goes unnoticed?
Through systematic, automated logging and validation reports after each test run – not through sporadic manual checks. Every import should provide a complete, analyzable summary: how many records were processed, how many were skipped, and why.
Is a single dry run sufficient before going live?
Generally not. Since production data continues to change until the cutover, at least one more test run should be performed shortly before the actual go-live to identify any newly emerging data quality problems in a timely manner.
What if a critical error occurs during the migration that we cannot resolve immediately?
A documented rollback plan should be in place before the cutover precisely for this scenario. Since PlentyONE remains the master system until the final cutover, switching back to the old system is technically possible.
Are these error patterns specific to PlentyONE, or would they also apply to other source systems?
The specific examples come from the PlentyONE to Odoo migration, but the underlying error patterns – duplicate keys, lack of idempotence, synchronous dependencies, insufficient testing – are typical risks of any ERP migration, regardless of the specific source system.
We’ve already experienced a migration project that went wrong.
Then you know the pattern: The error was there before, but nobody was looking for it. A structured test pyramid and a documented rollback plan are precisely the two things that were typically missing in such projects.
Request risk-free e-commerce replatforming
Most of these errors can be completely avoided if the architecture, data mapping, and test concept are properly planned before the project begins. We perform precisely this kind of review as part of our service. free, non-binding e-commerce audits.
✔ Free of charge ✔ No obligation ✔ Test concept instead of wishful thinking ✔ Response within 24 hours
Daniel Vogel
Daniel Vogel is the technical lead (Head of Development) at HQ GmbH. With his deep expertise in system architecture and Core Web Vitals, he leads the in-house development team on demanding e-commerce projects. His specialist area is complex replatforming scenarios, particularly the secure migration from Magento or Shopify to future-proof Shopware platforms.
In addition, he is the operational lead for technical emergency migrations and crisis management. When existing systems collapse under load or outdated code structures block growth, he designs and implements robust, high-performance architectures to get them back on track.
