PlentyONE Odoo Data Migration: Which data needs to be transferred?
Does everything really have to be migrated? 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 legacy burden in the old system?
This decision is made before the project begins, not during extraction. It directly determines how much volume must run through the limited PlentyONE quota and whether you copy existing data quality problems unchanged into the new system.
This page clarifies the scope. Data mapping in ERP migration deals with how the selected data is then technically mapped to the Odoo data model.
Define migration scope
A clear scope definition distinguishes between three data categories:
- Master data: items, categories, customers, conditions – required in real time and on an ongoing basis.
- Transaction data: current stock levels, open orders, current prices – also mandatory 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 data pool 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 the go-live. Historical data, on the other hand, can usually be migrated with less time pressure, but requires special care with unchanged prices and tax rates to ensure that past invoice amounts are not subsequently falsified.
This distinction is not an academic exercise: it directly determines how much data volume actually needs to be extracted via the limited API quotas of PlentyONE (see Bypassing PlentyONE API Limits ) and how long the migration phase will take.
A practical approach to scope definition begins with a simple categorization of all relevant data classes into one of three groups: "mandatory in the live system", "archivable but retrievable", and "no longer business-relevant". This classification should be carried out together with the business managers, 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 required for ongoing operations:
- Categories and Manufacturers
- Attributes and Variants
- Product images
- Customers and Addresses
- Tax Information
- Current prices
- Current stock
- relevant historical orders (for returns, customer service, auditability)
Not every project necessarily has to fully adopt all of these categories – discontinued marketplace special items or very old, business-irrelevant order history can, depending on legal retention obligations, be archived separately instead of being fully transferred to the new live system.
A more detailed look at the individual categories:
Categories and manufacturers form the backbone of the navigation structure and should generally be adopted completely and in the correct hierarchy – an incomplete category tree has a direct impact on navigation and the SEO structure in the frontend.
Attributes and variants are particularly prone to errors because they map relationships between parent and child objects. If the correct assignment is missing during migration, variants are created "without a parent product" – a classic import error that blocks the affected data record instead of allowing it through with errors.
For performance reasons, product images are typically transferred separately and asynchronously from the actual master data import in order not to unnecessarily prolong the duration of the core migration.
Customers and addresses require special care when merging billing and delivery addresses, especially if a customer has used different addresses across multiple orders.
Tax information directly determines the legal certainty of future invoices – a low error tolerance applies here, as an incorrect fiscal position leads to an incorrect tax calculation.
Properly delineating Shopware and ERP data
For merchants with an existing Shopware 6 frontend, the question also arises as to which system is leading for which entity. With an existing shop operation, item, category, and customer data are often already complete and up-to-date in the shop system; inventory, purchase prices, and accounting remain the pure domain of the ERP. We will discuss the specific assignment by entity and setup (single-channel vs. multi-channel) in more detail in the section on using Shopware as a data source.
This demarcation has a direct impact on the scope: data classes that are already fully available in the shop system do not need to be additionally extracted via the limited PlentyONE API quotas. How this relief works in concrete terms and where its limits lie is shown in Bypassing PlentyONE API Limits.
Historical data and auditability
A key advantage of fully importing 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 between the old and new systems.
Odoo follows a highly integrated approach: companies and contacts are managed in a common parent-child model. During import, the parent company is created first, and then the associated contacts are linked. The existing customer number from PlentyONE is retained as a unique reference – an important link 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 precisely transferred.
The import sequence follows a fixed logic that prevents database inconsistencies: Products → Customers → Orders → Items → Deliveries → Invoices.
Important for the technical implementation: Historical prices and tax rates are adopted unchanged; an automatic recalculation by the ERP system is specifically suppressed for this old data – otherwise, invoice amounts would change retroactively. Orders that have already been delivered must also not generate new stock movements in the new system; delivered and invoiced quantities are synchronized exactly with the historical values, so that the old order is immediately considered complete. Open orders, on the other hand, will be continued without interruption 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 data records
- Orphaned relations: Products that refer to categories that have already been deleted
- Inconsistent variants: Variants without an associated parent product
- Historical errors: negative stock levels, missing mandatory fields
These problems can be identified in a clean ETL process through systematic validation steps before they enter 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 item numbers or email addresses. Each hit is documented and either cleaned up or deliberately released as an exception before the next run – never silently accepted.
Clean-slate strategy
In some cases, it makes more technical sense not to carry over every historical legacy, but to specifically choose a clean restart for certain data classes – for example, with highly fragmented or inconsistently maintained category trees over the years. However, this is not a blanket recommendation to "just delete everything": The decision should be made on a technical basis per data class, with a clear justification as to why creating a new migration is preferable to migrating a faulty history.
A proven approach: For each clean-slate decision under consideration, document in writing which specific data quality problem it solves, which alternative (such as a more complex cleanup of legacy data) was discarded, and who is professionally responsible for this decision. This documentation prevents ambiguity months later about why certain historical data is missing from the new system.
The scope definition is at the beginning of the project. What follows – mapping, test run, cut-over, and monitoring – is shown in our overview of the migration from PlentyONE to Odoo.
Frequently asked questions about the scope of migration
Do all historical orders really need to be migrated?
Not necessarily all, but all with continuing relevance for customer service, returns, or statutory retention obligations. Pure archive data without this relevance can often be stored separately instead of being fully transferred to the new live system.
How do we decide whether a data class is suitable for a clean-slate strategy?
Whenever the existing data quality is so poor that cleaning up the old data would be more complex than a controlled new creation – and if 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. The IT department knows the technical effort per data class, while the specialist 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 another.
We are concerned that a complete migration will take an unnecessarily long time.
That’s why the scope definition is at the beginning, not at the end. Any data class that demonstrably does not belong in the live system shortens the extraction and relieves the API quota.
Have the migration scope defined
A structured inventory of your specific systems will show which of your data are actually must-haves and which can be archived in a meaningful way. This is precisely part of our free, non-binding e-commerce audits.
✔ Free ✔ Non-binding ✔ Specific 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.
