An overview of the six modules
The B2B Components bundle the typical requirements of digital business-to-business commerce into six building blocks. Each can be activated independently, but many build on one another in a logical way.
The modular design is the very core of the concept: a retailer with a simple re-ordering business might only activate Employee Management and Quick Order, whilst a corporate supplier would also need Order Approval and Organisation Units. It is precisely this flexibility that distinguishes the Components from the ‘all or nothing’ logic of the old suite.
What the Components do not cover
An important distinction: the B2B Components provide the B2B sales logic on the Shopware platform; they are not a replacement for an ERP, a PIM or a CRM. Furthermore, OCI and Punchout integrations with the procurement systems of large purchasing organisations are not included as standard in either the Suite or the Components; in practice, they are implemented via established extensions such as PunchCommerce or B2Bsellers. Anyone advertising ‘natively included’ is oversimplifying matters here. The Components handle the self-service and ordering processes within the shop, not the underlying master data or logistics architecture.
B2B Components versus the B2B Suite
The difference between the two is less a question of functional scope than of architecture and lifecycle. The Suite is the ready-made, bundled package from the past, which is now only maintained but no longer being developed further. The Components are the modular system of the present, in which Shopware is actively investing and which can be specifically extended via APIs.
In terms of functionality, the Components are steadily catching up with the Suite and already cover the core B2B requirements of small and medium-sized enterprises. For new projects, the recommendation is therefore, in almost all cases, to start with the Components rather than the Suite. Existing Suite installations should plan to migrate to the Components in the medium term, ideally in conjunction with an upgrade that is due anyway.
Availability and licensing
The B2B Components are not an extension that must be purchased separately, but are part of the commercial Shopware plans. They are included from the Evolve plan onwards (as of May 2026, from around 2,400 euros per month); the lower-tier Rise plan does not include B2B functionality. Larger setups with multiple shops, high order volumes or specific support requirements typically fall under the Beyond plan. As the plan structure and terms are regularly updated, the exact figures should be checked against the official Shopware specifications on the day before signing any contract.
A concrete real-world example
A technical wholesaler supplies industrial customers who place orders via their own purchasing departments. Using the B2B Components, they implement this as follows: via Employee Management, each customer creates their own buyers and assigns roles. Via Order Approval, orders of 5,000 euros or more must first be approved by the relevant department head. The customer’s service technicians use Quick Order to place recurring orders with three hundred items by part number in a matter of minutes, rather than having to click through categories. And via Organization Units, each branch sees only its own product range and terms and conditions.
This configuration illustrates the principle: the retailer activates precisely the four modules that support its business model, leaving Quota Management and Shopping Lists inactive for the time being. Should the quotation business be added later, Quote Management could be integrated without having to overhaul the existing setup. It is precisely this step-by-step scalability that forms the economic core of the Components.
B2B Components and migration from the Suite
For existing Suite shops, the Components are the migration destination. Data such as customer hierarchies, roles and price lists can generally be transferred, and the business configuration can be replicated because the concepts are the same. What needs to be assessed on a case-by-case basis are the customisations that have accumulated over the years: these determine whether a migration will be a manageable overhaul or a larger-scale project. Shopware provides its own migration path, complete with CLI tools, for the technical transfer, which is being continuously expanded.
The recommended process for such a migration follows five phases: a thorough inventory of the functions actually in use; mapping each Suite function to its Component counterpart; setting up in a staging environment running in parallel with live operations; a test phase using real customer accounts; and finally, the go-live. As this setup takes place alongside the running shop, there is generally no downtime. The duration depends almost entirely on the extent of the existing customisations: a near-standard installation can be migrated in a few weeks, whilst a heavily customised installation with an OCI connection is typically planned over a period of months. It is crucial to plan the migration early on, rather than postponing it until shortly before the end of support for the suite.
Detailed technical information on the architecture and the individual modules is provided in the official Shopware documentation on the B2B Components.
B2B Components in headless and composable setups
A key reason for the modular design is Shopware 6’s API-first approach. Unlike the old suite, whose logic was closely tied to the included storefront, the B2B Components provide their functions via the Store API. This makes them suitable for headless and composable architectures, where the frontend is not the classic Shopware storefront but a separate application, for example based on a modern JavaScript framework or a customer portal.
In practical terms, this means that a company can implement order approvals, staff management or quick ordering within a custom-built front-end or even an existing portal, whilst using Shopware as the commerce backend. This decoupling of functionality and presentation was difficult to achieve with the suite’s monolithic structure. For retailers with specific requirements regarding user interface, performance or integration into an existing system landscape, it is one of the greatest strategic advantages of the Components.
At the same time, it is important to note that a headless architecture is not an end in itself. For many medium-sized businesses, the supplied storefront – complete with activated Components – is entirely sufficient, and the additional effort involved in developing a bespoke front-end only pays off in cases of clear, specific requirements that differ from the standard. The Components allow for both approaches without requiring a permanent commitment at the initial decision stage, and it is precisely this flexibility that forms part of their concept.
Frequently asked questions about the Shopware B2B Components
Are the B2B Components the same as the B2B Suite? No. The B2B Suite is the older, monolithic B2B plugin, which now runs only in maintenance mode. The B2B Components are the modular successor, in which Shopware is actively investing and which is the standard for new projects.
How many modules do the B2B Components consist of? Six: Employee Management, Quote Management, Order Approval, Quick Order, Shopping Lists and Organisation Units. Each module can be activated individually.
From which Shopware plan onwards are the B2B Components included? From the Evolve plan onwards (as of May 2026, from around 2,400 euros per month). The Rise plan does not include any B2B functionality. Terms and conditions are subject to change and should be checked before signing a contract.
Can I migrate from the B2B Suite to the B2B Components? Yes. Data and standard configuration can largely be carried over; individual customisations must be checked for compatibility on a case-by-case basis and adapted to the modular architecture. It is advisable to plan the migration at an early stage, as support for the Suite ends with Shopware 6.8.
Do the B2B Components support OCI/Punchout? Not in the core. OCI and Punchout connections to procurement systems are implemented via established extensions and should be factored into the project budget from the outset.
