PlentyONE Odoo Data Migration: Which data needs to be transferred?
Does everything really need to be included? No. The question in an ERP migration is not "How do we migrate everything?", but rather: What belongs in the new live system, what belongs in the archive, and what was already a burden in the old system?
This decision is made before the project begins, not during the extraction. It directly determines how much volume must be processed using the limited PlentyONE quota and whether existing data quality issues will be copied unchanged to the new system.
This page clarifies the scope. How the selected data is then technically correctly mapped to the Odoo data model is explained elsewhere. Data mapping during ERP migration.
Define migration scope
A clear scope definition distinguishes three data categories:
- Master data: Articles, categories, customers, conditions – all needed in live operation, up-to-date and permanently.
- Movement data: Current stock levels, open orders, and current prices – these must also be available in the live system.
- Historical data: Completed orders, archived documents, discontinued items – required for auditability and customer service, but not necessarily in the same operational database as master data.
These three categories differ not only in content but also in their technical handling: Master data is typically imported completely and with high priority, as it directly supports daily operations. Transactional data requires careful delta logic, as it can change right up until go-live. Historical data, on the other hand, can usually be migrated with less time pressure, but requires special care regarding unchanged prices and tax rates to prevent past invoice amounts from being retrospectively falsified.
This distinction is not an academic exercise: it directly determines how much data volume actually needs to be extracted via PlentyONE's limited API quotas (see Bypass PlentyONE API Limits) and how long the migration phase lasts.
A practical approach to scope definition begins with a simple categorization of all relevant data classes into one of three groups: "essential in the live system," "archivable but retrievable," and "no longer business-relevant." This classification should be carried out jointly with the business stakeholders, not solely by the technical project management – only the business departments know the actual business relevance of individual historical data sets.
Must-have vs. Archive
Typically essential for ongoing operations:
- Categories and manufacturers
- Attributes and variants
- Product images
- Customers and addresses
- Tax information
- current prices
- current stock level
- Relevant historical orders (for returns, customer service, auditability)
Not every project necessarily has to fully adopt all of these categories – expired marketplace special items or very old, commercially irrelevant order history can sometimes be archived separately, depending on legal retention requirements, instead of being fully integrated into the new live system.
A more detailed examination of the individual categories:
Categories and manufacturers They form the backbone of the navigation structure and should generally be adopted completely and in the correct hierarchy – an incomplete category tree directly affects navigation and SEO structure in the frontend.
Attributes and variants These are particularly prone to errors because they represent relationships between parent and child objects. If the correct mapping is missing during migration, variants "without a parent product" are created – a classic import error that blocks the affected data record instead of allowing it to pass through with the error.
Product images For performance reasons, they are typically transferred separately and asynchronously to the actual master data import in order to avoid unnecessarily extending the duration of the core migration.
Customers and addresses Special care is required when combining billing and delivery addresses, especially if a customer has used different addresses across multiple orders.
Tax information They directly determine the legal certainty of future invoices – a low tolerance for error applies here, as an incorrect fiscal position leads to incorrect tax calculation.
Properly separating Shopware and ERP data
For retailers with an existing Shopware 6 frontend, the additional question arises as to which system is the primary one for which entity. Article, category, and customer data are often already complete and up-to-date in the shop system for existing online stores; inventory levels, purchase prices, and accounting remain solely the ERP domain. We will discuss the specific allocation by entity and setup (single-channel vs. multichannel) in more detail in [section/section name]. Use Shopware as a data source.
This limitation has a direct impact on the scope: Data classes that are already fully available in the shop system do not need to be extracted again using the limited PlentyONE API quotas. How this simplification works in practice and where its limits lie is explained below. Bypass PlentyONE API Limits.
Historical data and auditability
A key advantage of fully migrating relevant historical orders is that Odoo manages business partners, orders, invoices, and payment histories in a central, audit-proof model. This significantly simplifies subsequent tax audits, as tax advisors and auditors can access a complete history in the new system instead of manually reconciling data between the old and new systems.
Odoo employs a highly integrated approach: companies and contacts are managed within a shared parent-child model. During the import process, the parent company is created first, followed by the linking of the associated contacts. The existing customer number from PlentyONE is retained as a unique reference – an important point of contact for customer service, which can continue to refer to familiar customer numbers. Based on the VAT ID and country of origin, the system automatically assigns the appropriate fiscal position, such as domestic, EU, or third country – a prerequisite for legally compliant invoice generation. Individual payment terms and B2B credit limits are also transferred precisely.
The import sequence follows a fixed logic that prevents database inconsistencies: Products → Customers → Orders → Items → Deliveries → Invoices.
Crucial for the technical implementation: Historical prices and tax rates are adopted unchanged; automatic recalculation by the ERP system is specifically suppressed for this legacy data – otherwise, invoice amounts would be retroactively altered. Furthermore, orders that have already been delivered must not generate any new stock movements in the new system; delivered and invoiced quantities are precisely synchronized with the historical values, so the old order is immediately considered closed. However, any open orders will continue seamlessly in the new ERP system after the go-live.
Data quality over data quantity
Historically grown systems almost always contain legacy issues that should be cleaned up before migration, instead of being adopted unchanged:
- Duplicates: multiple item numbers or customer records
- Orphaned relations: Products that link to categories that have already been deleted
- Inconsistent variants: Variants without a corresponding parent product
- Historical errors: Negative inventory levels, missing required fields
These problems can be identified in a clean ETL process through systematic validation steps before they are implemented in the new system – significantly cheaper than correcting them later in an already productive Odoo system. A simple but effective practice: Before each test run, duplicate checks are performed directly at the database level, for example, for duplicate article numbers or email addresses. Every match is documented and, before the next run, either cleaned up or deliberately released as an exception – never silently accepted.
Clean-Slate Strategy
In some cases, it makes more technical sense not to carry over every legacy issue, but rather to selectively choose a clean start for specific data classes – for example, with highly fragmented category trees or those that have been maintained inconsistently for years. However, this is not a blanket recommendation to "simply delete everything": The decision should be made on a business basis for each data class, with a clear rationale as to why creating a new entry is preferable to migrating a flawed history.
A proven approach: For every clean slate decision under consideration, it is documented in writing which specific data quality problem it solves, which alternative (such as a more extensive cleansing of the legacy data) was rejected, and who is technically responsible for this decision. This documentation prevents situations months later where it is unclear why certain historical data is missing in the new system.
The scope definition is the first step in the project. Our overview shows what follows – mapping, test run, cutover, and monitoring. Migration from PlentyONE to Odoo.
Frequently asked questions about the scope of the migration
Do all historical orders really need to be migrated?
Not necessarily all data, but all data with ongoing relevance for customer service, returns, or legal retention requirements. Purely archival data without this relevance can often be stored separately instead of being completely transferred to the new live system.
How do we decide whether a data class is suitable for a clean slate strategy?
This applies whenever the existing data quality is so poor that cleaning up the old data would be more costly than creating a new, controlled version – and when there are no legal or technical reasons for a complete historical transfer.
Who should make the scope decision – IT or the business department?
Both together. IT knows the technical effort required for each data class, while the business department (sales, accounting, customer service) knows the actual business relevance of the respective data. A decision made unilaterally regularly leads to misjudgments in one direction or the other.
We fear that a complete migration will take unnecessarily long.
Therefore, the scope definition comes first, not last. Every data class that demonstrably does not belong in the live system shortens the extraction time and reduces the API quota.
Have the migration scope defined
A structured inventory of your specific systems reveals which of your data are truly essential and which can be meaningfully archived. This is precisely what our services cover. free, non-binding e-commerce audits.
✔ Free of charge ✔ No obligation ✔ Detailed scope checklist ✔ Response within 24 hours
Lukas Ehrenberg
Lukas Ehrenberg is HQ GmbH’s operational spearhead when it comes to complex, high-volume e-commerce infrastructures. Across numerous projects, he is responsible for the technical implementation of extensive ERP migrations — particularly the transition from legacy systems such as PlentyONE to modular platforms such as Odoo. Combined with his deep Shopware expertise, he builds scalable enterprise infrastructures. His extensive hands-on experience makes him the primary point of contact for brands seeking risk-free, data-secure and downtime-free replatforming.
As the technical administrator of a highly available enterprise Shopware cluster with more than 14 servers, he has mastered load balancing and system stability in high-frequency environments. His particular technical expertise lies in the architectural realignment of e-commerce ecosystems: He combines in-depth knowledge of secure data extraction from restrictive systems (such as the PlentyONE REST API with strict rate-limit optimization) with high-performance, asynchronous integration into modern ERP solutions such as Odoo. This enables him to ensure seamless system transitions even at the highest transaction volumes.
