PlentyONE Odoo Migration Errors: The Most Critical Pitfalls When Switching ERP Systems
The most expensive migration errors are not those that cause the import to fail. They are the ones that run silently: a data record that is discarded without anyone logging it. A variant that is linked to the wrong parent product. A tax rate that is calculated incorrectly on all subsequent invoices.
These errors are often not recognized as immediately visible technical errors. They appear in 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 the dry run instead of in live operation.
The error patterns described are not hypothetical edge cases, but recurring patterns – mostly where time pressure or a lack of systematic approach causes individual test steps to be skipped.
Silent Data Loss and Unrecognized API Errors
The most dangerous type of error in a migration is not the loud one, but the silent one: an import that appears to run successfully, but discards or incorrectly processes individual data records without this being noticed. Fixed basic rules prevent this: no silent errors, no suppressed exceptions, complete logging of every incident, and an automatic retry strategy with the postponement of unprocessable messages to a dead letter queue instead of a silent discard.
The consequence for project practice: These errors must be discovered in the dry run, not after go-live. A migration process without structured logging and without automated validation reports makes silent data loss practically invisible until a customer or an 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, item numbers are accidentally duplicated. The SKU serves as a central business key – duplicates must be identified and cleaned up before import, otherwise they will destroy the variant assignment in the ERP.
- Missing relations: If products refer to categories that have already been deleted or if variants exist without a parent product, the import of this specific data record is aborted. A clean ETL process logs this error for manual post-processing without stopping the overall migration.
- UUID conflicts: The Shopware frontend works internally with UUIDs. 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 will break. Whether a UUID in your setup takes on this reference function is part of the mapping analysis.
- Incorrect fiscal positions: An incorrect assignment of the 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 access data is not correctly retained in the Shopware frontend, all customers will be forced to reset their passwords – an avoidable but consequential point of friction during go-live.
We explain the mapping logic using business keys and surrogate keys in data mapping for ERP migration.
Shopware and Checkout Issues
A synchronous dependency between the checkout and the ERP system is one of the most common causes of instability during a migration: if the ERP response is delayed, the checkout is also immediately delayed. 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.
Before the productive go-live, a User Acceptance Test (UAT) should therefore 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 lead to the termination of the migration. 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 that the repeated operation is demonstrably idempotent. For non-idempotent write operations, it must also be checked before a retry whether the original request has already successfully modified the target system. We will discuss the specific PlentyONE-specific limits and their control in Bypassing PlentyONE API Limits.
Missing QA
A migration project without a structured test 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 Tests. Each of these stages covers different classes of errors – from individual functional errors to faulty system integration to performance problems under real load. If one of these stages is skipped, error detection tends to shift towards live operation – with correspondingly higher costs and risks.
A practical indicator of insufficient QA: If a project team understands the dry run as the "final test before go-live" instead of as an integral, repeatedly executed component of the entire development phase, the necessary test depth is usually lacking. A dry run is not a one-time event shortly before the deadline, but a repeatedly executed process over the entire project duration.
Architectural planning
A large proportion of avoidable migration errors arise even before the actual data migration, in the architecture planning itself:
- Incorrect system responsibilities: If it is not clearly defined which system is responsible for which data, duplicate master data maintenance with conflicting data statuses will occur.
- Synchronous interfaces: A blocking ERP dependency in the checkout process jeopardizes the availability of the entire shop. We describe the resilient alternative in the Odoo Shopware 6 Connector.
- Lack of idempotence: Without stable external IDs and appropriately designed import logic, there is a risk of duplicates instead of clean updates with each repeated run – for example, after a network error.
Performance Pitfalls in the Target Infrastructure
In addition to pure data errors, an inadequately dimensioned target infrastructure also regularly leads to problems that are incorrectly interpreted as data errors. A standard installation of Odoo is not automatically pre-configured for catalogs with several hundred thousand products. Relevant, workload-dependent parameters to be validated:
- PostgreSQL parameters such as
max_connections,shared_buffers, andwork_memmust be adjusted to the available memory of the server infrastructure – default values are often too conservative for large migration projects. - Number of Odoo workers: The rule of thumb is (number of CPU cores × 2) + 1, but the actual number must be validated based on CPU utilization, RAM, request profile, and parallelism in the specific operation. Longpolling workers should be operated separately.
- Reverse Proxy: Using NGINX or HAProxy as a reverse proxy in front of the Odoo instance is common.
A system that reaches its limits due to a lack of resources during migration generates symptoms that are easily confused with actual data errors – for example, timeouts that are actually due to too few workers instead of faulty mapping. Therefore, a robust error analysis always checks both levels: data quality and infrastructure dimensioning.
Data protection as an overlooked risk
A migration project inevitably processes highly sensitive company and customer data. If test environments are populated with unmodified production data, a GDPR-relevant risk arises that is easily overlooked in technical planning. Personal data should therefore be pseudonymized before use in staging environments, and temporary CSV exports or SQL dumps should be subject to a documented, time-bound deletion concept after project completion.
These error patterns are distributed throughout the entire migration process. Our overview of the migration from PlentyONE to Odoo shows which phases these are in detail and where each is checked.
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 selective manual control. Each import should provide a complete, evaluable summary: how many data records were processed, how many were skipped, and for what reason.
Is a single dry run before go-live sufficient?
Usually not. Since production data continues to change until the cutover, at least one more test run should be carried out shortly before the actual go-live in order to detect newly created data quality problems in good time.
What if a critical error occurs during migration that we cannot resolve immediately?
Precisely for this case, a documented rollback plan should be available before the cutover. Since PlentyONE remains the master system continuously until the final cutover, switching back to the old system is technically possible.
Are these error patterns specific to PlentyONE, or do they also apply to other source systems?
The specific examples come from the PlentyONE-to-Odoo migration, but the underlying error patterns – duplicate keys, missing idempotency, synchronous dependencies, insufficient testing – are typical risks of any ERP migration, regardless of the specific source system.
We have 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. This is exactly the kind of review we provide as part of our free, no-obligation e-commerce audits.
✔ Free ✔ Non-binding ✔ Test concept instead of the principle of hope ✔ 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.
