PlentyONE Price Increase: When Does Switching ERP Systems Become Worthwhile?
When does an ERP change pay off? Not from the first price increase. It pays off from the point at which the ongoing additional costs of staying exceed the one-time migration costs plus the costs of the target system over a realistic period of time.
A look at the monthly invoice is not enough for this assessment. It requires a total cost of ownership analysis over three to five years and an honest assessment of how quickly your own growth drives the cost curve upwards. We will perform exactly this calculation below, including break-even logic and the role your existing Shopware 6 frontend plays in it.
It's not just fast-growing wholesalers that are affected. Established medium-sized companies with stable but margin-sensitive business models also feel the impact of tariff changes directly in their calculations – precisely because a GMV-based model does not take into account whether additional revenue also brings additional margin.
A note on the scope: This article provides the economic classification. The articles on the target architecture and data migration will discuss whether and how a change will be implemented technically.
The GMV Pricing Model: How Revenue Growth Affects ERP Costs
Many SaaS ERP providers in the e-commerce environment – including PlentyONE – work with revenue-dependent tariff components that are based on the GMV (Gross Merchandise Value, the gross revenue processed via the platform). This means that a portion of the monthly costs automatically increases as soon as your own revenue rises.
Initially, this is neither good nor bad – a revenue-linked model distributes the risk to the provider during phases of weak growth. It becomes problematic when a retailer's revenue growth is significantly faster than their internal cost planning had anticipated: the ERP costs then grow disproportionately to the originally calculated margin.
Important for the evaluation: As of 2025, PlentyONE is divided into five editions: Lite (€59/month), Lite+ (€99/month), Expand (€149/month), Scale (€229/month), and Ultimate (individually calculated). Each edition includes a GMV free allowance – the entry-level tariff includes a monthly turnover of €10,000. Only the portion that exceeds this free allowance is subject to an additional, contractually agreed percentage – not the entire turnover. According to the provider, this excess percentage itself is negotiated individually and is not publicly available; it should be fixed in writing before the contract is concluded. The currently valid basic fees and free allowances can be found directly with the provider.
An additional effect that is often overlooked in GMV models is that the cost base grows regardless of whether the additional revenue is accompanied by a correspondingly higher margin. A dealer who builds up revenue through aggressive discount promotions or low-margin additional channels pays the same tariff share on this revenue as on high-margin existing business. For internal planning, it is therefore worthwhile to look not only at revenue, but at the ratio of ERP costs to contribution margin – this key figure shows much more precisely whether a tariff model still fits the company's own business model.
Practical scenario: Scaling costs with increasing transaction volume
In a real case we are aware of, a merchant reported an additional charge of around 30 percent, or almost €1,000 per month, triggered by an increased transaction volume within the existing tariff. This is explicitly a specific customer statement regarding an individual case – not a general PlentyONE key figure and not a basis for extrapolation to "typical" customers.
Such a jump in costs hits retailers in different growth phases with varying degrees of severity. For a company with stable, high margins, an additional annual burden in the four-figure range may be manageable. For a business model with weaker margins – for example, in highly competitive product categories with low markups – the same absolute amount can eat up a noticeable portion of the margin. This underscores why the assessment should not be based on the absolute amount, but rather in relation to one's own cost structure.
Nevertheless, the case reveals a structural pattern that can recur in revenue-dependent models: As soon as a dealer goes through a growth phase, the cost base does not change linearly with internal budget planning, but is linked to an external tariff model that the customer can only influence to a limited extent. For your own assessment, a simple test is therefore recommended: How has your ERP cost position developed in relation to your actual sales growth over the last 12 to 24 months – and is this relationship sustainable for the next few years?
Hidden costs of staying
In addition to the pure tariff increase, it is worth taking a look at indirect costs, which rarely appear in the monthly invoice but are actually incurred: workarounds for missing B2B functions, manual processes to compensate for API limits, or individual developments that have to be adapted again with each provider update. These costs are more difficult to quantify than a tariff line, but are just as real from a business perspective. Anyone who reduces a TCO analysis exclusively to license costs regularly underestimates the actual cost position of remaining.
TCO: A cost comparison of PlentyONE and Odoo
A serious economic analysis does not compare license costs against license costs, but rather considers the total costs over a period of three to five years:
| Cost block | At PlentyONE (whereabouts) | With Odoo (change) |
|---|---|---|
| License / ongoing operation | GMV-dependent, growing | Edition/hosting-dependent |
| Migration (one-time) | – | Data extraction, mapping, cutover |
| Development / Connector | any existing individual solutions | Shopware-Odoo Connector, possibly individual modules |
| Training | mostly low (existing system) | Conversion effort for the team |
| Maintenance | on the provider's side | partly in-house, partly partner |
| Integrations | existing interfaces | If necessary, new development/adaptation |
Two points are crucial here to keep the analysis serious: Firstly, the actual Odoo costs vary greatly depending on the edition, hosting model (on-premise, Odoo.sh, Odoo Online), and scope of functions – flat-rate figures without a concrete system analysis would be disingenuous at this point. Secondly, the migration itself is by far the most variable cost block: it depends directly on the data volume, complexity of the mapping, and the scope of existing individual integrations.
A detailed look at the individual cost blocks:
License and ongoing operations. With PlentyONE, this item is usually easy to plan for, as long as revenue growth remains moderate – with strong growth, it becomes a central uncertainty. With Odoo, ongoing operations depend crucially on the chosen operating model: self-hosting shifts costs from the software license to infrastructure and internal or external operating expenses.
Migration. This item is a one-off cost, but it is the most difficult to estimate as a flat rate. It depends directly on the number of articles and variants to be migrated, the complexity of the data mapping and – in the case of a high PlentyONE share – on the available API budget for extraction.
Development and connector. If Shopware 6 remains as the frontend, a robust integration layer must be built between Shopware and Odoo. This effort is a one-time cost, with a certain amount of maintenance for further development and monitoring.
Training. Rarely planned: A system change means that the team has to learn familiar processes in a new system. This effort is limited in time, but real and should not be set to zero in the project planning.
Maintenance. With PlentyONE, system maintenance is primarily the responsibility of the provider. With Odoo, it is distributed between the internal team and the implementation partner, depending on the operating model.
This is precisely why a reliable TCO statement cannot be made at a desk, but only with a technical inventory of the specific system.
Shopware 6 as a constant
One aspect that often significantly reduces migration costs is that the frontend does not necessarily have to be replaced when switching ERP systems. If Shopware 6 remains as the commerce and presentation layer, all relaunch costs for the theme, checkout, and existing SEO structures are eliminated from the migration bill. The migration is then reduced to the pure ERP change in the backend – with a clearly defined integration layer between the two systems. Details on this architectural decision can be found under "Keep Shopware when switching ERP systems".
For cost accounting, this means the following in concrete terms: The largest one-time cost block of a complete replatforming – theme development, checkout customization, frontend testing, and SEO migration – is completely eliminated if Shopware 6 remains unchanged. What remains are the actual ERP-specific cost blocks: data extraction, mapping, connector development, and cut-over. This not only lowers the absolute costs but also generally shortens the break-even period significantly compared to a complete system change.
ERP Change ROI: When Does the Migration Pay for Itself?
The break-even logic of an ERP change follows a simple basic principle: The one-time migration costs must be amortized by the difference between the running costs of the old system and the running costs of the new system.
Three scenarios illustrate how strongly this calculation depends on the individual growth rate: With stagnant sales, the cost difference between staying and switching remains largely constant over the years – the break-even period is correspondingly long and predictable. With moderate growth, the period gradually shortens as the GMV-dependent costs of the old system continuously increase. With strong growth, amortization can accelerate significantly because the cost difference between the old and new systems increases with each growth step. Which of these scenarios applies to you depends directly on your own sales development and the exact structure of your current tariff.
To put it simply: If a one-time switch costs X and the monthly cost difference between staying and switching is Y, the break-even point is X ÷ Y months. For a rapidly growing GMV-dependent tariff, this period tends to shorten with each additional growth step – whereas for a moderately growing company, it can lengthen significantly.
A purely illustrative example to demonstrate the logic (without reference to actual customer figures): If the one-time migration investment were X and the monthly cost savings were Y, the investment would pay for itself after X ÷ Y months. If Y continues to increase over time – for example, because the GMV rate grows progressively with revenue – the actual break-even period is further shortened compared to this static calculation. This sensitivity is the real reason why a GMV model pays for itself faster with rapidly growing merchants than with stagnant ones.
The crucial point is that there is no standard amortization period that applies to every company. Reliable statements on this require concrete figures for your current rate, your growth rate, and the actual migration effort of your specific system landscape.
If you want to evaluate the functional and architectural aspects of the change instead of just the cost, you can find the appropriate in-depth information under PlentyONE Alternative Odoo.
Frequently asked questions about the PlentyONE price development
Does a single price increase already justify a change in ERP?
Usually not on its own. A single price adjustment is a reason for review, not an automatic justification for a change. It only becomes relevant in conjunction with one’s own growth rate, existing functional limits, and the question of how the cost curve is expected to develop over the next few years.
At what company size does this analysis become worthwhile?
There is no blanket revenue threshold. What is relevant is less the absolute size than the ratio between ERP costs and margin, as well as the expected growth rate in the coming years. Even medium-sized retailers with margin-sensitive business models benefit from an early TCO analysis.
Will we lose our Shopware frontend if we switch ERP systems?
No. In the target architecture we described, Shopware 6 remains as the commerce and presentation layer, while only the ERP in the background is replaced. Details can be found in Keep Shopware when changing ERP.
How can a TCO analysis be started without much effort?
At the beginning, there is no complete migration planning, but rather a compact technical and economic assessment of your current tariff, your growth forecast, and your existing system landscape – this is exactly what our free audit provides.
How to conduct a robust economic analysis
A reliable TCO analysis cannot be derived from a general table, but requires a structured look at your own system landscape:
- Record current cost basis: tariff level, actual monthly costs for the last 12–24 months, additional costs for individual developments or workarounds.
- Classifying the growth forecast: How has the GMV developed, and how realistic is the continuation of this trend for the coming years?
- Roughly estimate migration effort: data volume, complexity of mapping, scope of existing interfaces – as a first indication, not as a final offer.
- Calculate break-even: Compare one-time migration costs against the monthly cost difference between staying and switching.
- Sensitivity analysis: How does the break-even period change under different growth scenarios?
This process does not provide a marketing figure, but rather a reliable basis for decision-making – and that is precisely the purpose of an initial technical and economic analysis before a specific project is even discussed.
The economic evaluation is only one part of the decision. Our overview of the migration from PlentyONE to Odoo shows how it fits into the overall technical process – from the target architecture to data migration and go-live.
Sources
The information on the current PlentyONE edition structure, the basic fees, and the GMV free allowance is based on the provider's official pricing page: PlentyONE – Prices and Tariffs. Note: The GMV overage rate is individually negotiated and does not change with this source – it must be requested separately for each TCO calculation.
Have the TCO analysis and migration effort reviewed.
A reliable economic analysis requires concrete figures: your current tariff, your growth forecast, and a realistic assessment of the migration effort for your specific system landscape. This is exactly what our free, non-binding e-commerce audit provides – as a first, risk-free basis for a well-founded decision, not as a premature sales pitch.
Find out if and when switching from PlentyONE to Odoo is economically worthwhile for you.
✔ Free ✔ Non-binding ✔ Based on your actual tariff and growth data ✔ Answer within 24 hours
We currently have no budget for a major project.
No one needs to have it before the figures are even available. The audit itself is free of charge and initially only shows whether and from when a change will pay off for you – a project decision only follows afterwards.
We don’t know if our migration effort can be realistically estimated at all.
It doesn’t have to be, before someone has taken a look. The analysis begins with an inventory of your systems, and only from this does a figure emerge that can be used for calculations.
A change sounds like a big risk.
The actual risk lies not in the change itself, but in a poorly planned implementation. A thorough TCO and architectural analysis before the start of the project reduces this risk to a calculable level.
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.
