PlentyONE price increase: When does switching ERP systems become worthwhile?
When does an ERP system change become worthwhile? Not from the first price increase. It becomes worthwhile from the point at which the ongoing additional costs of remaining with the current system exceed the one-time migration costs plus the costs of the target system over a realistic period.
A simple look at the monthly bill isn't enough for this assessment. It requires a total cost of ownership analysis over three to five years and an honest evaluation of how quickly your own growth is driving up costs. We'll perform precisely this calculation below, including break-even logic and the role your existing Shopware 6 frontend plays in it.
It's not just rapidly growing wholesalers that are affected. Established medium-sized companies with stable but margin-sensitive business models also feel tariff changes directly in their calculations – precisely because a GMV-based model doesn't take into account whether additional sales also generate additional margin.
A note on the distinction: This article provides the economic classification. Whether and how a switch is implemented technically is addressed in the articles on… Target architecture and to Data migration.
The GMV pricing model: How revenue growth affects ERP costs
Many SaaS ERP providers in the e-commerce sector – including PlentyONE – use revenue-based pricing components that are based on GMV (Gross Merchandise Value, the gross revenue processed through the platform). This means that a portion of the monthly costs automatically increases as your revenue grows.
This is neither good nor bad in itself – a revenue-linked model distributes the risk to the provider during periods of low growth. Problems arise when a retailer's revenue growth significantly exceeds their internal cost planning: ERP costs then increase disproportionately to the originally calculated margin.
Important for evaluation: Since 2025, PlentyONE has been 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 (General Merchandise Volume) allowance – the entry-level plan includes a monthly revenue limit of €10,000. Only the portion exceeding this allowance is subject to an additional, contractually agreed-upon percentage – not the entire revenue. According to the provider, this excess rate is negotiated individually and is not publicly available; it should be agreed upon in writing before signing the contract. You can find the currently applicable base fees and allowances directly on the provider's website.
An additional effect 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 retailer who generates revenue through aggressive discount campaigns or low-margin additional channels pays the same tariff component on this revenue as on high-margin existing business. For internal planning, it is therefore worthwhile to look not only at revenue but also at the ratio of ERP costs to contribution margin – this metric shows much more precisely whether a tariff model still fits the company's business model.
Practical scenario: Scaling costs with increasing transaction volume
In a real-world case we have reviewed, a merchant reported an increased charge of approximately 30 percent, or nearly €1,000 per month, due to higher transaction volumes under their existing plan. This is explicitly a specific customer statement regarding a single instance – not a general PlentyONE metric and not a basis for extrapolating to "typical" customers.
Such a cost increase impacts retailers at different stages of growth to varying degrees. For a company with stable, high margins, an additional burden in the four-figure annual range might be manageable. For a lower-margin business model—for example, in highly competitive product categories with low markups—the same absolute amount can eat up a significant portion of the margin. This underscores why the assessment should not be based on the absolute amount, but rather in relation to the company's own cost structure.
The case nevertheless reveals a structural pattern that can be repeated in revenue-based models: As soon as a retailer enters a growth phase, the cost base does not change linearly according to internal budget planning, but rather is linked to an external pricing model that the customer can only influence to a limited extent. Therefore, a simple test is recommended for your own assessment: How has your ERP cost position developed in relation to your actual revenue growth over the last 12 to 24 months – and is this relationship sustainable for the coming years?
Hidden costs of staying
Beyond the pure price increase, it's worth considering indirect costs that rarely appear on the monthly bill but are a real expense: workarounds for missing B2B features, manual processes to compensate for API limits, or custom developments that need to be adjusted with every vendor update. These costs are harder to quantify than a single line item on the price list, but just as real from a business perspective. Those who reduce a TCO analysis solely to license costs regularly underestimate the true cost of remaining with the vendor.
TCO: Comparing PlentyONE and Odoo economically
A serious cost-benefit analysis does not simply compare license costs against license costs, but considers the total costs over a period of three to five years:
| Cost block | At PlentyONE (whereabouts) | At Odoo (switch) |
|---|---|---|
| License / ongoing operation | GMV-dependent, growing | Edition/hosting dependent |
| Migration (one-time) | – | Data extraction, mapping, cutover |
| Development / Connector | possibly existing individual solutions | Shopware-Odoo connector, possibly custom modules |
| training | usually low (existing system) | Changeover effort for team |
| maintenance | supplier-side | partly in-house, partly with partners |
| Integrations | existing interfaces | Possible new development/adaptation |
Two points are crucial for maintaining a credible analysis: First, the actual costs of Odoo vary significantly depending on the edition, hosting model (on-premise, Odoo.sh, Odoo Online), and range of functions – providing general figures without a concrete system analysis would be misleading. Second, the migration itself is by far the most variable cost factor: It depends directly on data volume, the complexity of the mapping, and the extent of existing custom integrations.
A detailed look at the individual cost categories:
License and ongoing operation. At PlentyONE, this item is generally easy to plan for as long as revenue growth remains moderate – with strong growth, it becomes a key uncertainty. At 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-time charge, but it's the most difficult to estimate in general terms. It depends directly on the number of articles and variants to be migrated, the complexity of the data mapping, and – with a high PlentyONE share – the available API budget for extraction.
Development and Connector. If Shopware 6 remains the frontend, a robust integration layer between Shopware and Odoo must be built. This is a one-time effort, with some maintenance costs for further development and monitoring.
Training. Rarely planned for: A system change means that the team has to relearn familiar processes in a new system. This effort is temporary, but real, and should not be dismissed in project planning.
Maintenance. With PlentyONE, system maintenance is primarily the responsibility of the provider. With Odoo, it is distributed – depending on the operating model – between the internal team and the implementation partner.
That 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 doesn't necessarily need 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 calculation. The migration then reduces 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 at [link to relevant information]. Keep Shopware when switching ERP systems.
For cost accounting, this means specifically: 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 truly ERP-specific cost blocks: data extraction, mapping, connector development, and cutover. This not only reduces the absolute costs but also typically shortens the break-even period significantly compared to a complete system change.
ERP migration ROI: When does the migration pay for itself?
The break-even logic of an ERP migration follows a simple basic principle: The one-time migration costs must be amortized by the difference between the ongoing costs of the old system and the ongoing costs of the new system.
Three scenarios illustrate how strongly this calculation depends on the individual growth rate: With stagnant revenue, the cost difference between staying with the old system 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 revenue development and the specific details of your current tariff.
In simplified terms: If switching costs a one-time fee of X and the monthly cost difference between staying and switching is Y, the break-even point is reached after X ÷ Y months. For a rapidly growing, GMV-dependent tariff, this period tends to shorten with each further growth step – conversely, for a moderately growing company, it can lengthen considerably.
A purely illustrative example to clarify the logic (without reference to actual customer numbers): 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 increases further over time—for example, because the GMV rate grows progressively with revenue—the actual break-even period shortens even further compared to this static calculation. This sensitivity is the real reason why a GMV model pays for itself faster for rapidly growing retailers than for those that are stagnating.
The crucial point is: there is no single amortization period that applies to every company. Reliable statements on this require concrete figures based on your current plan, your growth rate, and the actual migration effort required for your specific system landscape.
Those who wish to evaluate the functional and architectural aspects of the change, rather than just the cost, will find the appropriate in-depth information at PlentyONE Alternative Odoo.
Frequently asked questions about PlentyONE price development
Does a single price increase justify switching ERP systems?
Generally not on its own. A single price adjustment is a reason for review, not an automatic justification for switching providers. It only becomes relevant in conjunction with the company’s own growth rate, existing functional limitations, and how the cost curve is expected to develop over the next few years.
From what company size does this analysis even become worthwhile?
There is no fixed revenue threshold. What matters is not so much the absolute size, but rather 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 underlying ERP system is replaced. Details can be found in Keeping Shopware when switching ERP systems.
How can a TCO analysis be started without much effort?
The process doesn’t begin with a complete migration plan, but rather with a compact technical and economic inventory of your current tariff, your growth forecast and your existing system landscape – that’s exactly what our free audit provides.
How a reliable economic analysis is conducted
A reliable TCO analysis cannot be derived from a general table, but requires a structured look at one's own system landscape:
- Record current cost basis: Tariff level, actual monthly costs of 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, mapping complexity, scope of existing interfaces – as a first indication, not as a final offer.
- Calculate break-even: Compare one-off migration costs to the monthly cost difference between staying put and switching.
- Check sensitivity: How does the break-even period change under different growth scenarios?
This process does not provide a marketing figure, but a reliable basis for decision-making – and that is precisely the purpose of an initial technical and economic analysis before any concrete project is even discussed.
The economic evaluation is only one part of the decision. Our overview shows how it fits into the overall technical process – from the target architecture and data migration to the go-live. Migration from PlentyONE to Odoo.
Sources
The information regarding the current PlentyONE edition structure, basic fees and GMV free allowance is based on the provider's official price page: PlentyONE – Prices and Tariffs. Note: The GMV overrun rate is contractually individual 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 cost-benefit analysis requires concrete figures: your current tariff, your growth forecast, and a realistic assessment of the migration effort for your specific system landscape. That's precisely what our [service/tool] delivers. free, non-binding e-commerce audit – as a first, risk-free basis for a well-informed decision, not as a hasty sales pitch.
Find out if and when switching from PlentyONE to Odoo will be financially worthwhile for you.
✔ Free of charge ✔ No obligation ✔ Based on your actual tariff and growth data ✔ Response 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 and initially only shows whether and when a switch would be worthwhile for you – a project decision will only follow afterwards.
We don’t know if our migration effort can even be realistically estimated.
It doesn’t have to be, until someone has looked inside. The analysis begins with an inventory of your systems, and only from that can a number be derived that can be used for calculations.
A change sounds like a big risk.
The real risk lies not in the switchover itself, but in poorly planned implementation. A thorough TCO and architecture analysis before the project begins reduces this risk to a manageable 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.
