From plentymarkets / PlentyONE to Shopware: when the switch pays off

When the switch pays off and which ERP strategies make sense

Many retailers start with plentymarkets, now PlentyONE, because the system combines shop, inventory management, marketplace connections, order processing, warehouse and automation in one platform. That is attractive, especially at the beginning: one system, lots of features and a relatively quick start. As the shop grows, however, the question often arises whether the entire e-commerce setup really has to stay in an all-in-one system for good, or whether it is more economical and flexible to separate shop and ERP cleanly.

This is exactly where Shopware becomes interesting. Shopware can be used as a modern, flexible shop system, while the ERP either stays in place, is replaced later or, for simpler requirements, can even be partly covered by Shopware itself. Especially with standard requirements and no special logic, meaning no extremely complex warehouse processes, individual production workflows or highly specialised marketplace logic, switching from PlentyONE to Shopware can bring a significant improvement in cost and flexibility.

How is PlentyONE structured?

PlentyONE is not just a shop system. It is a combination of ERP, PIM, OMS, WMS, CRM, multichannel management and online shop. The system manages product data, stock, orders, warehouse processes, documents, payment and shipping processes and marketplace connections.

Technically, this makes sense if retailers sell heavily via marketplaces, want to manage many channels centrally or prefer an all-in-one solution. Depending on the plan, PlentyONE offers different options for marketplaces, shops, external shop integrations, SKUs, workflows, users, syncs and warehouses.

The important point, however, is that the pricing is not based on a simple shop licence alone. PlentyONE charges according to tariff, plan and the GMV processed. GMV here means the value of goods that runs through the system. If a booked limit is exceeded, additional fees may apply. For retailers this means: the more revenue and volume grow, the more closely you need to check whether the platform costs are still in proportion to the functionality you actually need.

Why Shopware often makes sense as a standalone shop system

Shopware takes a different approach. Shopware is first and foremost a flexible shop system with a strong focus on storefront, shopping experience, product presentation, checkout, Rule Builder, Shopping Experiences, sales channels, an API-first structure and extensibility.

The self-hosted variant with the Shopware Community Edition is particularly interesting. Here the typical fixed costs are for hosting, maintenance, updates, monitoring, plugins and technical support. For many standard shops, a solid technical setup can be budgeted with predictable monthly costs, for example around €200 a month for operation, hosting and basic technical support, depending on traffic, server size and the scope of maintenance.

The big difference: with a Shopware Community setup, the shop licence is not automatically tied to monthly revenue. Traffic can be scaled technically via hosting. If revenue rises, the licence costs of the shop system do not necessarily rise with it. For retailers with standard processes, the combination of Shopware Community, suitable hosting and a lean ERP solution can therefore be very attractive economically.

The economic core

Many retailers don’t need a large all-in-one platform permanently. If your own shop is at the centre and the ERP processes are fairly standardised, a Shopware architecture can be considerably leaner, more flexible and cheaper in the long run.

Three sensible migration scenarios

1. PlentyONE stays as ERP, Shopware becomes the shop system

This is often the most pragmatic first step. PlentyONE remains the leading system for items, stock, orders, warehouse and processes. Shopware only takes over the visible shop: design, category structure, product detail pages, checkout, SEO, content and conversion optimisation.

This model is ideal when inventory management in PlentyONE works well but the shop itself is reaching its limits visually, technically or in terms of SEO. The retailer gains the flexibility of Shopware without having to tackle the entire ERP project straight away.

Typical data flows in this scenario

• Items and variants are transferred from PlentyONE to Shopware.
• Categories, properties, images and prices are synchronised.
• Orders from Shopware flow back to PlentyONE.
• Stock is maintained centrally in the ERP and passed to the shop.
• Payment and shipping status can be returned, depending on the interface.

The result is a hybrid architecture: PlentyONE remains the operational back end, and Shopware becomes the modern front end for better conversion, SEO, performance and customer experience.

2. A complete switch to Shopware with lean ERP functions

With simple requirements, Shopware can take on more than many retailers initially think. Shopware manages products, variants, categories, customers, orders, payment status, delivery status, documents, shipping methods, rules, discounts, sales channels and stock levels.

That is not enough for every business. If you need complex purchasing processes, several warehouses, batches, serial numbers, production, stock planning, Amazon FBA processes or extensive accounting processes, you should connect a proper ERP. For retailers with a manageable product range, a simple warehouse, clear shipping processes and few sales channels, however, Shopware can be sufficient as the central operational platform.

When Shopware can be enough as the central solution

• The shop is the most important sales channel.
• There is only one warehouse or a few.
• Stock planning is not highly complex.
• Products, variants and prices follow a clear structure.
• Orders can be processed directly in the Shopware admin.
• Marketplaces play no role or only a minor one.

The advantage: there are no costs for an additional ERP system. Especially if an all-in-one system was previously only partly used, this variant can be very economical.

3. Shopware plus a separate ERP such as weclapp or VARIO Cloud

If the ERP requirements go beyond Shopware but PlentyONE is no longer the right platform, Shopware can be combined with a specialised ERP. Two typical alternatives are weclapp and VARIO Cloud.

weclapp is interesting for many retail and e-commerce processes, because inventory management, purchasing, warehouse, orders, customers and accounting processes can be bundled in a cloud-based ERP. Via a Shopware connector, items, stock and orders can be synchronised between Shopware and weclapp.

VARIO Cloud is another possible solution for retailers who need a standalone inventory management system. Here too, Shopware can be connected as the shop system while VARIO Cloud handles the ERP functions.

In many cases, a setup of Shopware plus ERP still stays within a predictable monthly budget. Even with an ERP such as weclapp or VARIO Cloud, many simple to medium requirements often remain below €500 a month, depending on the number of users, interfaces, hosting, support and additional modules needed.

The difference between an all-in-one system and a flexible architecture

The biggest difference lies not only in the technology but in the strategic direction. An all-in-one system like PlentyONE bundles a great many functions in one platform. That can be convenient, but it also ties the retailer closely to that particular platform logic.

A Shopware architecture is more modular. Shopware handles the shop, the shopping experience and the commerce processes. The ERP is chosen according to what is actually needed. In simple cases, Shopware can take on many tasks itself. In more complex cases, a specialised ERP such as weclapp, VARIO Cloud or another inventory management system is connected.

Advantages of a modular Shopware architecture

• More freedom in front-end design and conversion optimisation
• Better options for SEO, content and landing pages
• More predictable running costs with self-hosted setups
• No mandatory link between shop costs and revenue
• Free choice of the right ERP system
• Gradual migration instead of a risky complete switch
• Better extensibility through custom plugins and interfaces

How does a switch from PlentyONE to Shopware work?

The most important point is not the technical migration alone but defining the leading system. Before the project, you need to decide where which data will be maintained in future.

The key questions before the project starts

• Where will product data be maintained in future?
• Where are prices and special prices created?
• Where is stock held?
• Where are orders processed?
• Where are invoices generated?
• Where are returns and cancellations handled?
• Which marketplaces need to stay connected?
• Which historical data needs to be migrated?

Only once these roles are clear should the migration be carried out.

Project phase 1: analysing the existing PlentyONE structure

First, we check how the current system is set up. This includes products, variants, categories, properties, images, stock, customer data, orders, tax rules, shipping methods, payment methods, SEO URLs, redirects and custom fields.

With systems that have grown over time in particular, it often turns out that many data structures have evolved historically. Not everything should be carried over to Shopware unchecked. A migration is therefore always an opportunity to clean up data and improve the shop structure.

Project phase 2: data mapping and target structure

The next step is to define how the data from PlentyONE will be represented in Shopware. PlentyONE attributes, properties and variant logic need to be transferred to Shopware products, options, properties, custom fields and sales channels.

This is where it is decided whether the project will remain cleanly maintainable later on. Good mapping ensures that product data is understandable, filterable, search-engine-friendly and technically well structured.

Project phase 3: Shopware setup

Then Shopware is set up technically. This includes hosting, theme, storefront, categories, Shopping Experiences, payment providers, shipping rules, email templates, legal texts, tracking, analytics and interfaces.

The interplay between design, performance and data structure is particularly important here. Shopware shouldn’t simply rebuild the old shop, but should use the opportunity to set up a shop that sells better, looks more modern and is easier to maintain.

Project phase 4: implementing the ERP strategy

Next, the ERP strategy is implemented. Depending on the target model, PlentyONE stays connected, a new ERP such as weclapp or VARIO Cloud is integrated, or Shopware initially takes over the standard operational processes itself.

The crucial thing is that there are no unclear responsibilities. If several systems are allowed to change the same data, errors quickly arise in prices, stock, orders or customer data. It must therefore always be clearly defined which system is leading for which data.

Project phase 5: testing, go-live and monitoring

Before go-live, test orders, stock reconciliation, payment status, shipping status, cancellations, returns, invoices, vouchers, tax cases and email processes all need to be checked.

Only then do the final data transfer with delta sync, the domain switch, redirects and monitoring follow. SEO redirects are especially important so that existing rankings and organic traffic are not lost unnecessarily.

When should PlentyONE stay?

PlentyONE shouldn’t be replaced across the board. If a retailer sells heavily via many marketplaces, uses complex warehouse processes, has automated many workflows or relies on PlentyONE as the operational core deeply embedded in daily work, a complete switch can be unnecessarily risky.

In that case, a hybrid solution is often better: PlentyONE stays as the ERP and Shopware is connected as a powerful shop system. This way the visible shop can be modernised while internal processes remain stable.

When does a complete switch pay off?

A complete switch pays off especially when PlentyONE is mainly used as a shop, while the ERP and multichannel functions are only used to a limited extent. A switch should also be considered if running costs rise through GMV-based scaling while the requirements are actually standardised.

Shopware then offers more freedom in design, SEO, performance, content commerce, conversion optimisation and custom development. At the same time, the cost structure can become much more predictable, particularly in self-hosted operation with the Community Edition and lean technical support.

Typical signs that a switch makes sense

• The shop is no longer up to date visually or technically.
• SEO and content commerce are limited in the current system.
• Ongoing platform costs are rising faster than the functionality you actually need.
• Many PlentyONE functions are not used at all or only rarely.
• Shop development is to become more individual and flexible.
• There are no highly complex special ERP processes.

Cost comparison: why Shopware is often more predictable

With PlentyONE, costs can scale depending on plan, GMV, extensions and the scope used. That makes sense for some retailers, but with growing revenue it can lead to rising platform costs.

With a self-hosted Shopware setup, monthly costs can often be planned much more reliably. Hosting, maintenance and technical support can be calculated according to the scope of the project. For simple to medium projects, technical fixed costs from around €200 a month are realistic. If an ERP such as weclapp or VARIO Cloud is needed as well, many standard setups still often stay below €500 a month.

Simplified example of possible target architectures

Model	Description	Suitable for
Shopware only	Shopware handles the shop, products, orders and simple stock logic.	Retailers with simple standard processes
Shopware + PlentyONE	PlentyONE stays as ERP, Shopware is connected as a modern shop system.	Retailers with a working PlentyONE back end
Shopware + weclapp	Shopware as the shop, weclapp as a cloud-based ERP for trade and processes.	Retailers with growing ERP needs
Shopware + VARIO Cloud	Shopware as the storefront, VARIO Cloud for inventory management.	Retailers with classic inventory management requirements

Conclusion: Shopware doesn’t have to replace PlentyONE completely right away

Switching from PlentyONE to Shopware doesn’t have to be an all-or-nothing project. In many cases, the most sensible route is a gradual transition.

First, Shopware is set up as the new shop system. PlentyONE initially stays as the ERP and supplies items, stock and process data. If it later turns out that PlentyONE is too big, too expensive or too inflexible as an ERP for your actual needs, a second step can move to Shopware’s own processes, weclapp, VARIO Cloud or another ERP.

The result is a scalable architecture: Shopware as a flexible front end and shop system, an ERP sized to actual needs and no unnecessarily large platform lock-in. For retailers with standard requirements, this can mean considerable monthly savings, especially if the previous cost block scaled more with revenue, GMV or platform scope even though the actual processes remain manageable.

Our tip

Rather than planning a full ERP migration straight away, first check which tasks PlentyONE actually performs today. Often it is enough to connect Shopware as the new shop system and keep the existing ERP structure running for the time being. After that, you can decide step by step whether PlentyONE stays for good, is replaced by weclapp or VARIO Cloud, or whether Shopware is already sufficient for your existing processes.

Who is this approach particularly interesting for?

• Retailers who mainly use PlentyONE as a shop.
• Companies that need better SEO and content options.
• Shops whose platform costs rise with revenue.
• Retailers with standard ERP requirements and no special customisations.
• Companies that want to develop their shop system more flexibly.

Note

The cost ranges mentioned are intended as a guide. Actual monthly costs always depend on hosting, traffic, number of users, ERP functions, interfaces, plugins and the level of support required.