Using Shopware as a data source: Data consolidation during ERP migration
Some of the data you want to extract from PlentyONE is already stored elsewhere: in your own online store. This includes articles, categories, customers, and, in single-channel operations, order history.
This isn't just an academic observation; it's the most effective way to combat API quotas. Every data set you retrieve from your self-hosted shop system doesn't count against your PlentyONE budget. And that budget is the scarcest resource during the migration phase.
This article shows where this strategy works and where it doesn't. It also addresses the contingency issue itself, which is the very motivation behind it. Bypass PlentyONE API Limits.
Why an ERP system doesn't always have to be the sole data source
In established e-commerce system landscapes, data is rarely neatly concentrated in a single system. Product descriptions, SEO data, images, and category structures are often maintained directly in the shop system because they have immediate effect there – not necessarily in the ERP system. A migration that rigidly uses only one source in such cases either migrates outdated data or creates unnecessary additional work to update data in the ERP system that is already correctly stored in the shop system.
A typical example from practice: SEO-optimized product descriptions, which have been editorially refined in the shop system over years, often exist in the ERP system only as short, functional article titles. If the migration were to transfer only the ERP data, this editorial work would be lost – a loss of quality that only becomes noticeable after the go-live in declining conversion rates or SEO rankings.
The more practical approach: The data source is determined per entity and sometimes even per field – not across the board for the entire project.
Shopware 6 as a source for commerce-relevant data
For a single-channel setup with existing Shopware operation, the following data is typically fully available in the shop system:
- Articles, categories and variants
- Customers and addresses
- SEO-relevant metadata and media
In multichannel operation – the standard case for PlentyONE – this only applies to a limited extent: Marketplace-exclusive, inactive, or discontinued items, as well as marketplace buyers without a shop order, do not appear in the shop catalog at all. For these cases, PlentyONE remains the only available source. The order history itself also remains managed by PlentyONE in multichannel operation, as the shop system only recognizes orders from its own sales channel.
Certain data classes reside exclusively in the ERP system, regardless of the setup: inventory levels and goods receipts, purchase prices and supplier data, as well as accounting documents are purely ERP domains without direct shop reference.
Data classes in setup comparison
| Data type | Single-channel setup | Multichannel setup |
|---|---|---|
| Articles, categories, variants | Shop system | Shop system, supplemented with PlentyONE |
| Customers & Addresses | Shop system | Shop system, supplemented with PlentyONE |
| Order history | Shop system | PlentyONE (leading) |
| Inventory levels & goods received | PlentyONE | PlentyONE |
| Purchase prices & supplier data | PlentyONE | PlentyONE |
| Accounting documents | PlentyONE | PlentyONE |
As a general rule: Anything that is inherently transaction- or product-related and fully maintained within the shop context is sourced from the shop system. Anything that exclusively concerns ERP-side business logic – or is only partially present in the shop – remains with PlentyONE.
A note on the transferability of this methodology to other platforms: Magento is also self-hosted and therefore fundamentally equally suitable as a secondary data source, but its EAV (Entity-Attribute-Value) data structure requires more effort in the transformation step, as attribute values are not stored flat but are distributed relationally across multiple tables. Shopify, on the other hand, as a SaaS platform, has its own API rate limits – the reduction in load still exists, but is less pronounced because the secondary system itself is also throttled. For this cluster, Shopware 6 remains the reference case described above, because its streamlined API model makes the technical implementation the most direct.
Understanding Golden Record correctly
Saying "Shopware is the golden record" would be a dangerous oversimplification. In this context, "golden record" doesn't mean that one system is universally the leading source for all data, but rather that for each entity and each field, a decision is made individually as to which system represents the more reliable and up-to-date source. For product descriptions and SEO data, this is often the shop system; for inventory levels and purchase prices, it's almost always the ERP system.
This decision should be documented and not implicitly distributed throughout the code – only then will it remain traceable why a particular field originates from which source if questions about data provenance arise months later. A simple but effective approach: a tabular entity ownership matrix that documents the leading system and any exceptions for each relevant entity (article, category, customer, order, price, stock). This matrix becomes the central reference document for everyone involved in the ETL process – from development to final acceptance testing.
Which data source is the primary source for which entity?
The following rule of thumb has proven effective in practice: Everything that is inherently transaction- or article-related and is fully maintained within the shop context comes from the shop system. Everything that exclusively concerns ERP-side business logic – or is only partially present in the shop – remains with the ERP system.
An important limitation regarding platform selection: The decisive factor for suitability as a secondary data source is not the specific product, but whether the shop system is self-hosted and therefore not subject to manufacturer-imposed API limits. With self-hosted systems, the request volume is limited solely by the company's own infrastructure. While the reduction in bandwidth still exists with SaaS platforms, it is less pronounced because the secondary system itself may be throttled.
This substitutability is intentionally designed this way: The methodology is not tied to Shopware as a specific product, but rather to the characteristic of being "self-hosted, without vendor-imposed API limits." Switching the secondary data source would, in principle, also be possible during the ongoing migration process with a reasonable amount of adjustment, provided the alternative system fulfills the same requirements. Since Shopware 6 serves as the reference case in this cluster, the following explanations will focus consistently on it.
ETL merging before Odoo import
The technical process follows a clear, reproducible pattern:
Extract → Normalize → Merge → Validate → Load
Data from PlentyONE and the shop system are extracted separately, normalized into a common intermediate format, merged according to previously defined entity ownership rules, validated, and only then imported via the Odoo API. Crucially, the traceability of the data provenance must be identifiable: For each imported data record, it should remain clear which source system each field originates from – not least to enable targeted tracking of any subsequent data conflicts.
For the actual import into Odoo, a sequence of individual calls is deliberately not used; instead, the batch-capable method is employed. load()This method uses the JSON-2 API. It processes multiple data records per call and references them via external IDs – the same idempotence logic used in pure ERP migration. This allows the merge process to be executed repeatedly in a suitable test environment without creating duplicates in the target system, which is particularly valuable when dealing with a data source from two different systems.
Data cleansing before Odoo
Before merging data is imported, typical quality problems must be identified:
- Conflicts between sources: Different values for the same field in PlentyONE and the shop system
- Prioritization: A clear, documented decision as to which source prevails in case of conflict.
- Duplicates: identical items or customers that were created independently in both systems
This cleanup should be done structurally before the import, not in a subsequent correction loop in Odoo – any subsequent correction in an already productive ERP system is significantly more complex than a cleanup beforehand.
Our overview describes how this data consolidation is embedded in the overall process of an ERP migration. Migration from PlentyONE to Odoo.
Frequently asked questions about Shopware as a data source
Does “Shopware as a data source” mean that Shopware will become the leading system in the future?
No. This role is limited exclusively to the migration phase and only applies to specific data classes. PlentyONE remains the master system until the final cutover; after the migration, Odoo takes over this role for ERP data, while Shopware manages frontend data.
Can other shop systems besides Shopware also take on this role?
Generally, yes, provided the system is self-hosted and not subject to restrictive third-party API limits. The described methodology is tied to this characteristic, not to a specific product.
How do we ensure that no data is migrated twice or inconsistently?
Through a documented entity ownership rule that clearly defines for each data class which system is the leading source in case of conflict – combined with systematic validation before the actual import into Odoo.
Architecture audit for distributed data sources
Determining which of your data is already fully integrated into the shop system, and where PlentyONE remains the sole source, requires a thorough system analysis. This is precisely what we provide as part of our service. free, non-binding e-commerce audits.
✔ Free of charge ✔ No obligation ✔ Entity-specific data analysis ✔ Response within 24 hours
We don’t know how much of our data is actually being maintained twice.
This overview is provided by the audit as a first, clear inventory – before any decision is even made about a migration project.
Our Shopware data has been maintained differently over the years – is that a problem?
This is one of the most common starting points. The entity ownership matrix and the subsequent data cleansing are specifically designed to make such historically grown differences visible and resolve them before import.
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.
