Migrating from PlentyONE to Odoo: Costs, Alternatives, Shopware, and Technical Implementation
Can PlentyONE be replaced as an ERP without touching the shop? Yes. Shopware 6 and the ERP behind it are two separate systems and can also be replaced separately: Shopware remains the commerce and presentation layer, while Odoo 19 takes over merchandise management, purchasing, financial accounting, and CRM.
However, whether this change is worthwhile and how complex it will be does not depend on a blanket answer, but on the existing data model, the business processes, the existing interfaces, the API limits of PlentyONE, and the desired target architecture. Anyone who does not answer these questions before the start of the project will either miscalculate the effort involved or miss an opportunity to structurally improve the system landscape.
An ERP migration is therefore not a pure 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. Anyone who underestimates this will end up with two poorly integrated systems instead of one clearly structured system.
This is especially true for PlentyONE as the source system: It is a multichannel commerce ERP with its own API model, its own rate limits, and a close integration of merchandise management and sales channels. Switching to Odoo 19 does not mean "shutting down and restarting" this system, but rather transferring the individual data domains – items, customers, inventories, prices, accounting – in a targeted and traceable manner into a new, relational target system. The migration architecture is planned in such a way that daily operations can be continued in a controlled manner 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 to the target architecture and the actual data migration, to integration, go-live, and the technical audit with which a real migration project begins.
Why companies should consider 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 that has a revenue-based pricing model (GMV rate), cost development is directly linked to your own sales growth – an effect that is particularly noticeable for rapidly growing retailers because the cost base then grows faster than originally calculated internally.
That alone does not justify a change. What is crucial is a total cost of ownership (TCO) analysis over several years instead of just the monthly bill: migration, development, training, and integration costs must be compared to the ongoing cost increase. A detailed economic analysis including break-even logic can be found in our article on the PlentyONE price increase.
Technical and functional limitations
In addition to costs, requirements often grow as well: more complex B2B pricing logic, multiple warehouses, fine-grained forecasting processes, or deeper financial integrations. PlentyONE is therefore not universally unsuitable – the question is rather whether the current system architecture still accurately reflects 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 with a view to the specific target architecture. More on this in PlentyONE Alternative Odoo.
Requirements of growing e-commerce companies
As the system grows, the system landscape becomes more complex: ERP, commerce frontend, data management, interfaces to marketplaces and logistics service providers, scalability, and ongoing operations must be considered as a coherent architecture – not as a series 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 becomes, the more a system landscape built for the last stage of growth, rather than the next, will backfire. Typical symptoms include: pricing logic is maintained via Excel spreadsheets instead of through the system, inventory levels are manually reconciled between multiple locations, or financial accounting reports are generated indirectly instead of directly within the ERP. None of these symptoms alone is proof of a necessary system change, but taken together, they indicate that the architecture is reaching its designed limit.
Decision criteria for the ERP change
Before a migration is planned in detail, a short checklist is worthwhile:
- Cost development of the existing system (especially with revenue-based tariffs)
- functional limitations 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
- the general future viability of architecture
The more of these points apply, the more a structured review is worthwhile. An ERP change is ultimately an architectural decision – not purely a cost decision and not a pure 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 exclusively handles the presentation and sales layer: storefront, checkout, search, and customer experience. Odoo 19 becomes the leading instance for master data, inventory, pricing, purchasing, and accounting. This separation is not a stopgap measure but a conscious decision in the underlying migration architecture: Odoo 19 exclusively replaces the ERP, 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 stake. If Shopware 6 remains unchanged, these risks are completely eliminated for the ERP project. This does not mean that a frontend relaunch would be fundamentally harmful – only that it should remain an independent decision, rather than being technically coupled to the ERP migration.
Odoo 19 as the target ERP
In this architecture, Odoo 19 assumes the role of the single source of truth for ERP data. We describe the specific data classes that remain entirely with Odoo, and those that can also originate from the existing shop system on a situational basis, 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 (items, customers) | consumed | leading |
| Inventories, goods receipts | consumed | leading |
| Purchase prices, supplier data | – | leading |
| Accounting | – | leading |
If you have already migrated your frontend from PlentyONE to Shopware and now only want to replace the ERP backend, you can find the architectural details in "Retaining architectural details in Shopware when changing ERP".
This architectural decision is not a detail, but is documented as a separate Architecture Decision Record in our technical migration manual: Shopware 6 will permanently remain the frontend system because the existing SEO structure, theme, and URLs will be preserved – this minimizes both project risk and potential visibility losses. The immediate consequence: The system architecture will be distributed, Odoo 19 will not appear publicly on the web, and a Shopware-Odoo connector will become mandatory. A second, supplementary architectural decision stipulates that Odoo 19 will exclusively replace the ERP and become the leading instance for master data – Shopware may no longer contain its own business logic for price or inventory calculations, but will consume this data exclusively from the ERP database.
Migrate data from PlentyONE to Odoo
An ERP migration involves more than just data transport: it consists of scope definition, the selection of suitable data sources, extraction, transformation, semantic mapping, validation, and import. The actual risk rarely lies in the data volume, but in the semantic assignment: a field that is a simple property in PlentyONE may require its own linked structure in the relational Odoo model. Anyone who transfers data mechanically 1:1 instead of mapping it correctly will, at best, produce import errors – and at worst, unnoticed incorrect assignments that only become apparent weeks after go-live.
Scope of migration
Not every migration has to be a 1:1 copy of all historical data. Relevant operational data (active items, current customers, open stocks) and historical data (completed orders, archived documents) deserve different treatment. Details on the scope definition can be found in PlentyONE Odoo Data Migration.
Data sources
PlentyONE does not necessarily have to be the only data source during migration. For articles, categories, customers, or order history, a lot of information is already available in the existing shop system – often more up-to-date and complete than in the ERP. The decision as to which system is leading for which field is made per entity, not across the board as "one system is the golden record". More on this in Shopware as a data source.
API Extraction
PlentyONE provides its data via a REST API, which is subject to noticeable rate limits depending on the plan: The documented base values range from around 60,000 read calls per day in the entry-level plan to almost 300,000 in higher plan levels – additionally limited by the number of simultaneously active API sessions. Migration and day-to-day business share the same quota – a point that is often noticed too late in project planning. An API-friendly extraction strategy that measures the available budget in advance instead of estimating it is therefore part of any serious migration planning; the complete plan values and the specific control logic can be found in Bypassing 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 from a third-party provider. This role is not necessarily tied to Shopware, but it 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 → Load. This 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 create() calls is deliberately not used; instead, the batch-capable load() method is employed. It processes multiple data records per call and is also the central idempotency mechanism of the migration, as it updates existing data records via external IDs instead of duplicating them. This very property 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 assignment of PlentyONE and Shopware data to Odoo models in detail in Data Mapping in ERP Migration.
Integrate 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, are to be removed in future versions. New developments should therefore no longer be based on these older interfaces. A practical advantage of this newer API is that it provides real HTTP status codes and a structured error object in case of problems, which significantly simplifies error handling in the connector. The technical details – methods, pagination, authentication in system comparison – can be found in 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 is exclusively available in custom plans for Odoo Online, from custom plans for self-hosted instances, and is generally 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 prerequisite that should be clarified before the final determination of the target architecture.
API Authentication
Authentication is stateless and is performed via an API key, which is transmitted as a bearer token in the HTTP header. This significantly simplifies the connection 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 takes on this role – this is a concrete, but not necessarily the only, implementation option for every project. What is crucial is not the chosen product, but the underlying pattern: sender and receiver remain loosely coupled, so that a short-term failure 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 inventories, prices, orders, and statuses continuously synchronized thereafter. For continuous operation, an additional technical requirement applies that goes beyond pure migration: idempotence. The specific import and synchronization logic is programmed in such a way that repeated processing is possible without duplicates or inconsistent states – solved via external IDs in conjunction with the load() method, which updates instead of creating new entries if an ID already exists. The technical depth for this is provided by the Odoo Shopware 6 Connector.
Secure 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 be created in the legacy system – these are subsequently updated via one or more delta synchronizations.
Cut-over
The actual cutover process follows a fixed sequence: final data reconciliation, a brief write-lock in the legacy system, final validation, switching to Odoo as the leading system, and subsequent monitoring. A documented rollback plan provides additional security for this step. This short, precisely planned cutover phase – typically a few minutes instead of hours – exclusively affects the ERP level; the Shopware frontend remains accessible, and incoming orders are buffered. We explain the cutover logic in ERP Migration without Downtime.
Operational risks
The biggest risk factors are data inconsistencies, unnoticed API errors, insufficiently tested interfaces, and missing exception handling. We counter these risks with a firm basic rule: no silent errors, complete logging of every incident, and automated monitoring from the very first day after go-live – not just after a customer reports an inconsistency. The most common pitfalls and how to detect them in the dry run instead of in live operation are described in PlentyONE Odoo Migration Errors.
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 "privacy by design" principle – minimal data transfer, end-to-end encryption, and strictly separated test and production environments. Productive customer data does not enter test systems unfiltered; personal data is pseudonymized before being used in staging environments.
SEO maintenance
An ERP change does not automatically mean an SEO loss. Risks only arise where URLs, metadata, or structured data change due to the migration. As long as Shopware 6 remains the sole public frontend, search engines will continue to crawl only this level. SEO Migration Shopware 6 shows how to actively ensure the preservation of SEO URLs instead of treating it as a given.
Technical reference for the PlentyONE → Odoo Migration
The content linked on this page is based on our technical migration manual "Migrating from PlentyONE to Odoo", which documents architecture, data mapping, ETL processes, API strategy, connector setup, go-live procedures, and SEO migration in detail.
The manual is maintained as living documentation and updated for relevant changes to Odoo, Shopware, and PlentyONE interfaces. The underlying reference implementations have been practically verified against a self-hosted Odoo 19 instance, a production PlentyONE instance, and a Shopware 6.7 instance – not just statically checked.
Over 500 reference scripts for Odoo, PlentyONE, Shopware, and monitoring/infrastructure are publicly available at github.com/HQ-GmbH/plenty-erp2odoo. They cover authentication, read and write operations, batch import via load(), and data mapping for all three systems. They are structurally derived from a common framework, even though PlentyONE and Shopware are resource-oriented REST APIs, while Odoo provides a complete ORM via HTTP through the JSON-2-API. The productive migration tool built from these scripts is not part of this release – the example scripts are for the traceability of the described procedures, not as a ready-made migration automation.
For whom a complete migration is worthwhile
A complete PlentyONE to Odoo migration is usually advisable when several of the following characteristics apply: e-commerce structures with several hundred thousand items, distinct B2B processes with individual price lists and approval processes, 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 economical choice – this is a question that an open-minded technical analysis should answer, not a blanket system recommendation.
This prioritization does not follow a random principle, but a clear sequence: user pain and real business questions first, then search intent, business intent, technical differentiation, and only last, keyword signals. Anyone reading this article as a decision-maker should not only know that a migration is possible, but also where it would need to start within their own system landscape.
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 the ERP system is best practice in professional e-commerce today. Shopware 6 remains as the commerce platform, while Odoo 19 takes on the role of the leading ERP system in the background for merchandise management, CRM, purchasing, accounting, and production.
Can I implement Odoo first and then develop the Shopware frontend separately later?
Yes, this is even a proven strategy for risk minimization. Due to the loose coupling of the architecture, the backend can first be completely switched to Odoo 19, while the existing frontend is connected via the Shopware-Odoo connector. A frontend relaunch can take place independently of this at a later, self-chosen 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 accounts for a high proportion of the data to be migrated – on the available API budget. Doubling the developer capacity does not necessarily shorten the pure extraction phase if this is limited by the API quota rather than by 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 → Have your Odoo migration evaluated
Before a migration makes sense, it must be clear where your system landscape currently stands: system architecture, Shopware integration, data distribution, interfaces, available API budget, realistic scope, and target architecture. This is exactly what we check in the free, non-binding e-commerce audit – as a diagnosis, not a sales pitch.
Find out if and how switching from PlentyONE to Odoo is specifically worthwhile for you – free of charge and without obligation.
Alternatively: Speak directly with a technical contact person now for an initial assessment of whether a complete migration, a step-by-step integration, or initially just an architectural consultation is the right next step: +49 36626 31760
✔ Free ✔ Non-binding ✔ 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.
