Migrating PlentyONE to Odoo: Costs, alternatives, Shopware and technical implementation
Can PlentyONE be replaced as an ERP system without affecting the online store? Yes. Shopware 6 and the underlying ERP are two separate systems and can be replaced independently: Shopware remains the commerce and presentation layer, while Odoo 19 handles inventory management, purchasing, accounting, and CRM.
Whether this change is worthwhile and how complex it will be depends not on a general answer, but on the existing data model, the business processes, the existing interfaces, PlentyONE's API limits, and the desired target architecture. Anyone who fails to answer these questions before starting a project will either miscalculate the effort required or miss an opportunity to structurally improve their system landscape.
An ERP migration is therefore not simply a data export, but an architectural project. It changes which system is responsible for which data, how systems communicate with each other, and how operations are secured during the transition. Those who underestimate this end up with two poorly integrated systems instead of one clearly structured one.
This is especially true for PlentyONE as the source system: It's a multichannel commerce ERP with its own API model, rate limits, and tight integration of inventory management and sales channels. Switching to Odoo 19 doesn't mean "shutting down and restarting" this system, but rather transferring the individual data domains—products, customers, inventory, prices, accounting—in a targeted and transparent manner to a new, relational target system. The migration architecture is planned in such a way that day-to-day operations can continue uninterrupted and the impact on ongoing shop operations is minimized.
This article guides you through the entire decision-making process: from the economic or technical trigger, through the target architecture and the actual data migration, to integration, go-live, and the technical audit that marks the beginning of a real migration project.
Why companies are considering switching from PlentyONE to Odoo
Economic development and ERP costs
Rising costs are often the first reason to question an existing ERP system. With a provider using a revenue-based pricing model (GMV tariff), cost development is directly linked to the company's own revenue growth – an effect that becomes particularly noticeable for rapidly growing retailers, because the cost base then increases faster than originally calculated internally.
That alone doesn't justify a change. What's crucial is a total cost of ownership (TCO) analysis over several years, rather than just a monthly calculation: migration, development, training, and integration costs must be weighed against ongoing cost increases. A detailed economic analysis, including break-even logic, can be found in our article on… PlentyONE price increase.
Technical and functional limitations
Alongside rising costs, requirements often increase as well: more complex B2B pricing logics, multiple warehouses, fine-grained forecasting processes, or deeper financial integrations. PlentyONE is therefore not inherently unsuitable – the question is rather whether the current system architecture can still adequately support the next stage of growth or whether workarounds have already become the norm.
This question cannot be answered with a simple system comparison, but only by looking at the specific target architecture. More on this in PlentyONE Alternative Odoo.
Requirements of growing e-commerce companies
As the system landscape grows, it becomes more complex: ERP, commerce frontend, data storage, interfaces to marketplaces and logistics providers, scalability, and ongoing operations must be considered as a cohesive architecture – not as a collection of individual tools. In this context, Shopware 6 is an existing, functioning commerce component that can retain its role in the target architecture.
Requirements of growing e-commerce companies (in-depth)
The larger a company grows, the more a system landscape built for the last stage of growth, rather than the next, backfires. Typical symptoms include: pricing logic maintained via Excel spreadsheets instead of the system, inventory levels manually reconciled between multiple locations, or financial accounting reports generated indirectly instead of directly within the ERP system. None of these symptoms, in itself, proves the need for a system change – but collectively, they indicate that the architecture is reaching its design limits.
Decision criteria for ERP migration
Before planning a migration in detail, a short checklist is worthwhile:
- Cost development of the existing system (especially with revenue-based tariffs)
- Functional boundaries in B2B, warehousing, purchasing, or financial processes
- Number and scope of existing workarounds
- Distribution of data across multiple systems
- Number and stability of existing interfaces
- Scalability for the next 3–5 years
- Data sovereignty and dependence on the previous provider
- general future viability of architecture
The more of these points apply, the more worthwhile a structured review becomes. Ultimately, an ERP migration is an architectural decision – not purely a cost decision or a simple functional comparison.
Keep Shopware 6 and replace the ERP in the backend
No. Switching from PlentyONE to Odoo does not automatically require a relaunch of Shopware 6.
Decoupling ERP and Commerce frontend
In a clean target architecture, Shopware 6 handles only the presentation and sales layer: storefront, checkout, search, and customer experience. Odoo 19 becomes the primary instance for master data, inventory, pricing, purchasing, and accounting. This separation is not a workaround, but a deliberate decision within the underlying migration architecture: Odoo 19 exclusively replaces the ERP system, while Shopware remains the frontend system.
Shopware 6 as an existing commerce system
A frontend relaunch carries its own risks: existing SEO structures, the theme, and established URL structures are all at risk. If Shopware 6 remains unchanged, these risks are completely eliminated for the ERP project. This doesn't mean that a frontend relaunch is inherently harmful – only that it should remain an independent decision, rather than being technically linked to the ERP migration.
Odoo 19 as the target ERP system
In this architecture, Odoo 19 assumes the role of the single source of truth for ERP data. The specific data classes that remain entirely within Odoo, and those that may also originate from the existing shop system depending on the situation, are described in the data migration section below.
Responsibilities of the systems
| Area | Shopware 6 | Odoo 19 |
|---|---|---|
| Storefront, Checkout, Search | ✓ | – |
| SEO URLs, metadata, structured data | ✓ | – |
| Master data (articles, customers) | consumed | leading |
| Inventory levels, goods received | consumed | leading |
| Purchase prices, supplier data | – | leading |
| accounting | – | leading |
Those who have already migrated their frontend from PlentyONE to Shopware and now only want to replace the ERP backend can find the architectural details in Keep Shopware when switching ERP systems.
This architectural decision is not a minor detail, but is documented in our technical migration manual as a separate Architecture Decision Record: Shopware 6 will remain the permanent frontend system because the existing SEO structure, theme, and URLs will be retained – this minimizes both project risk and potential loss of visibility. The immediate consequence: The system architecture will be distributed, Odoo 19 will not be publicly visible on the web, and a Shopware-Odoo Connector This will be absolutely necessary. A second, supplementary architectural decision stipulates that Odoo 19 will exclusively replace the ERP system and become the leading instance for master data – Shopware may no longer contain its own business logic for price or inventory calculations, but will instead consume this data exclusively from the ERP database.
Migrate data from PlentyONE to Odoo
An ERP migration involves more than just data transfer: it consists of defining the scope, selecting suitable data sources, extraction, transformation, semantic mapping, validation, and import. The real risk rarely lies in the data volume, but rather in the semantic mapping: a field that is a simple property in PlentyONE might require its own linked structure in the relational Odoo model. Anyone who mechanically transfers data 1:1 instead of mapping it correctly will, at best, produce import errors – at worst, unnoticed incorrect mappings that only become apparent weeks after go-live.
Migration scope
Not every migration needs to be a 1:1 copy of all historical data. Relevant operational data (active items, current customers, open inventory) and historical data (completed orders, archived documents) require different treatment. Details on the scope definition can be found in [reference to relevant documentation]. PlentyONE Odoo Data Migration.
Data sources
PlentyONE doesn't necessarily have to be the sole data source during migration. Much of the information for articles, categories, customers, or order history already exists in the existing shop system – often more up-to-date and complete than in the ERP. The decision as to which system is the primary source for each field is made on a per-entity basis, not as a blanket "one system is the golden record." More information can be found in… Shopware as a data source.
API extraction
PlentyONE provides its data via a REST API, which is subject to significant rate limits depending on the chosen plan: The documented baseline values range from approximately 60,000 read requests per day in the entry-level plan to nearly 300,000 in higher plan tiers – further limited by the number of concurrently active API sessions. Migration and day-to-day operations share the same quota – a point that is often noticed too late in project planning. Therefore, an API-friendly extraction strategy that measures the available budget in advance rather than estimating it is an essential part of any serious migration plan; the complete pricing details and the specific control logic can be found in [link to relevant documentation]. Bypass PlentyONE API Limits.
Shopware as a supplementary data source
For SEO-relevant data, media, and category structures, the existing, self-hosted shop system is often the more practical source – provided it is not subject to restrictive API limits imposed by a third-party provider. This role is not necessarily tied to Shopware, but is described in this cluster using Shopware 6 as a reference case.
Transformation and Import
The technical process follows a clear pattern: Extract → Transform → Mapping → Validation → LoadThis decoupling of the steps makes the process reproducible and traceable – a key difference from improvised CSV exports between systems. For the actual import into Odoo, a sequence of individual steps is deliberately not used. create()-calls to use, but the batch-capable load()-Method: It processes multiple data records per call and is also the central idempotence mechanism of the migration, as it updates existing data records via external IDs instead of duplicating them. This very feature enables repeatable test migrations against a suitable staging environment without having to reset the target system after each run. We will discuss the specific semantic mapping of PlentyONE and Shopware data to Odoo models in more detail in [section/document/etc.]. Data mapping during ERP migration.
Integrating Odoo 19 and Shopware 6
Odoo 19 JSON-2 API
Odoo 19 communicates externally via the JSON-2 API – the current interface generation introduced with version 19.0. The older XML-RPC and JSON-RPC endpoints are considered deprecated and, according to Odoo, will be removed in future versions. Therefore, new developments should no longer rely on these older interfaces. A practical advantage of this newer API is that it provides true HTTP status codes and a structured error object for problems, which significantly simplifies error handling in the connector. The technical details – methods, pagination, authentication in a system comparison – can be found in [link to documentation]. Odoo 19 JSON-2 API.
Important for target architecture planning: The availability of this API depends on the chosen Odoo operating model and edition. According to Odoo, external API access for Odoo Online is only available in Custom plans, for self-hosted instances starting with the Custom plans, and is always available in the Community Edition. In practical terms, this means that the architecture described here requires either the Community Edition or a Custom plan – a requirement that should be clarified before finalizing the target architecture.
API authentication
Authentication is stateless and performed via an API key transmitted as a bearer token in the HTTP header. This significantly simplifies integration compared to older, session-based methods.
Event/Queue Architecture
For ongoing communication between Shopware and Odoo, an event-based architecture is recommended: An event triggers a message in a message queue, a consumer processes it asynchronously, and errors are caught via retry mechanisms. In the described reference architecture, a RabbitMQ message queue fulfills this role – this is one specific implementation option, but not necessarily the only one for every project. The crucial factor is not the chosen product, but the underlying pattern: Sender and receiver remain loosely coupled, so that a brief outage of one system does not immediately jeopardize the operation of the other.
Ongoing synchronization
Migration and continuous operation are two different things: Migration transfers historical and current data once, while continuous operation keeps inventory, prices, orders, and statuses continuously synchronized thereafter. Continuous operation has an additional technical requirement that goes beyond simple migration: idempotence. The specific import and synchronization logic is programmed to allow repeated processing without duplicates or inconsistent states – achieved through external IDs in conjunction with the load()-A method that updates existing IDs instead of creating new ones. Odoo Shopware 6 Connector.
Securing go-live, SEO and operations
Delta migration
The actual full import takes place weeks before the go-live. Until the final cutover, new orders and inventory changes continue to occur in the legacy system – these are then incorporated via one or more delta synchronizations.
Cut-over
The actual switchover process follows a fixed sequence: final data synchronization, temporary write protection in the legacy system, final validation, switchover to Odoo as the primary system, and subsequent monitoring. A documented rollback plan provides additional security for this step. This short, precisely planned switchover phase—typically a few minutes rather than hours—affects only the ERP level; the Shopware frontend remains accessible, and incoming orders are buffered. We explain the cutover logic in [link/section]. ERP migration without downtime.
Operational risks
The biggest risk factors are data inconsistencies, undetected API errors, insufficiently tested interfaces, and a lack of exception handling. We address these risks with a firm principle: no silent errors, complete logging of every incident, and automated monitoring starting from the very first day after go-live—not just after a customer reports a discrepancy. The most common pitfalls and how to detect them during a dry run rather than in live operation are described below. PlentyONE Odoo migration error.
One aspect that is often neglected in many projects is data protection. An ERP migration processes highly sensitive company and customer data, which is why the underlying architecture consistently operates according to the principle of "Privacy by Design"—minimal data transfer, end-to-end encryption, and strictly separated test and production environments. Production customer data does not enter test systems unfiltered; personal data is pseudonymized before being used in staging environments.
SEO maintenance
Switching ERP systems doesn't automatically mean SEO loss. Risks only arise when URLs, metadata, or structured data change during migration. As long as Shopware 6 remains the sole public frontend, search engines will continue to crawl only this layer. How to actively safeguard SEO URLs, instead of taking them for granted, is explained below. SEO Migration Shopware 6.
Technical reference for the PlentyONE → Odoo migration
The content linked on this page is based on our technical migration guide. “Migrate PlentyONE to Odoo”, which documents in detail the architecture, data mapping, ETL processes, API strategy, connector setup, go-live approach and SEO migration.
The manual is maintained as living documentation and updated whenever there are relevant changes to the Odoo, Shopware, and PlentyONE interfaces. The underlying reference implementations were practically verified against a self-hosted Odoo 19 instance, a production PlentyONE instance, and a Shopware 6.7 instance – not just statically tested.
Over 500 reference scripts for Odoo, PlentyONE, Shopware, and monitoring/infrastructure are publicly available at github.com/HQ-GmbH/plenty-erp2odooThey cover authentication, read and write operations, batch import via load() The data mapping for all three systems is derived from a common structure, although PlentyONE and Shopware are resource-oriented REST APIs, while Odoo provides a complete ORM via HTTP using the JSON-2 API. The resulting production migration tool itself is not part of this publication – the example scripts serve to demonstrate the described procedures, not as a complete migration automation solution.
For whom a complete migration is worthwhile
A complete migration from PlentyONE to Odoo is generally advisable when several of the following characteristics apply: e-commerce structures with hundreds of thousands of products, sophisticated B2B processes with individual price lists and approval workflows, multiple warehouses or complex multi-warehouse management, and existing, complex integrations with third-party systems. For smaller, less complex system landscapes, remaining with PlentyONE may still be the more economically viable option – this is a question that should be answered by an open-ended technical analysis, not a blanket system recommendation.
This prioritization is not random, but follows a clear sequence: user pain and real business questions first, then search intent, business intent, functional differentiation, and only lastly keyword signals. Decision-makers reading this article should, by the end, not only know… that not only whether a migration is possible, but also at what point in its own system landscape it would have to start.
Frequently asked questions about the PlentyONE-Odoo migration
Does the Shopware frontend also need to be replaced?
No. The strict separation of the Shopware frontend and ERP system is best practice in professional e-commerce today. Shopware 6 remains as the commerce platform, while Odoo 19 takes over the role of the leading ERP system in the background, handling inventory management, CRM, purchasing, accounting, and production.
Can I implement Odoo first and develop the Shopware frontend separately later?
Yes, this is actually a proven strategy for minimizing risk. The loosely coupled architecture allows the backend to be completely migrated to Odoo 19 initially, while the existing frontend is connected via the Shopware-Odoo connector. A frontend relaunch can then be carried out independently at a later, self-selected time.
How long does such a migration typically take?
This depends crucially on the data volume, the complexity of the data mapping, and – if PlentyONE is a significant portion of the data to be migrated – the available API budget. Doubling the developer capacity does not necessarily shorten the pure extraction phase if it is limited by the API quota rather than the development effort. A reliable time estimate is only possible after a technical analysis of your specific systems.
What happens to our historical order data?
They are transferred in a structured manner, with unchanged historical prices and tax rates, so that past invoice amounts are not subsequently falsified. This ensures both continuity in customer service and auditability for tax advisors and auditors.
PlentyONE → Odoo Migration Assessment
Before a migration makes sense, it's essential to have a clear understanding of your current system landscape: system architecture, Shopware integration, data distribution, interfaces, available API budget, realistic scope, and target architecture. We examine precisely these aspects in our analysis. free, non-binding e-commerce audit – as a diagnosis, not as a sales pitch.
Find out if and how switching from PlentyONE to Odoo would be worthwhile for you – free of charge and without obligation.
Alternatively: Speak to a technical contact person directly now – for an initial assessment of whether a complete migration, a gradual integration, or purely architectural consulting is the right next step: +49 36626 31760
✔ Free of charge ✔ No obligation ✔ Technical contact person ✔ Response within 24 hours
Mathias Goldhan
Mathias Goldhan laid the foundation for today’s digital agency in 1994 and has been leading HQ GmbH strategically and operationally since 2005. With more than three decades of experience in software development and systems architecture, he advises medium-sized businesses and brands on the digitalization of business-critical processes. He is the strategic mind behind HQ GmbH’s positioning among the Top 100 owner-managed digital agencies (iBusiness/BVDW).
As a recognized SaaS pioneer and specialist in high-performance hosting, he designs highly available cluster infrastructures and leads the technical rescue of stalled large-scale e-commerce projects. He contributes his expertise in resilient systems and API-based B2B automation internationally between the company’s headquarters in Thuringia and its branch in Spain.
