The Shopware B2B Suite is the product most written about in German-speaking B2B e-commerce — and the one you should not start a new project with in 2026. Not because it is bad. Because Shopware’s own documentation contains a sentence that ends the discussion:
“B2B Suite will no longer be supported starting Shopware 6.8. Plan your migration promptly to avoid disruptions.” — developer.shopware.com, B2B Suite Migration, retrieved 30 Aug 2026
This article settles three things: what the B2B Suite was and what replaces it, which edition you need for which feature — and, because almost every article on the topic skips it, how much B2B you get with no licence at all. For that last part we did not research. We measured: Shopware 6.7.13.1 installed from scratch, database counted, and a real B2B price structure created.
The result up front, and it cuts both ways: in a freshly installed Community Edition, not one of the 252 tables is a B2B table. Zero. At the same time, that same free core creates a net-price customer group in 57 milliseconds and writes a three-step quantity scale cleanly into the data model. Both statements are true, and the distance between them is the entire decision.
The short version
| Question | Answer (as of 30 Aug 2026) |
|---|---|
| Is the Shopware B2B Suite still current? | No. No further development, support ends with Shopware 6.8 |
| What replaces it? | B2B Components, part of the Shopware Commercial extension |
| Which plan? | Evolve (from €2,400/month excl. VAT) or Beyond |
| Can I still get the Suite? | Only if purchased by 23 May 2025; from 24 May 2025 it is Components only |
| Is there a migration path? | Yes, an official B2B Suite Migration extension |
| Migration prerequisite | B2B Suite version 4.9.3 or higher |
| B2B tables in the free CE | 0 of 252 (counted ourselves) |
| B2B entities in the free CE | 0 of 231 DAL entities |
| Rule condition types in the free CE | 112, of which 34 are customer-related |
| Tiered pricing in the free CE | works (created and verified ourselves) |
composer create-project (Ubuntu 24.04, PHP 8.3.6, MariaDB 10.11.14, Composer 2.10.3), system:install —basic-setup in 27.8 s. Counts taken directly from information_schema and from the running instance’s DefinitionInstanceRegistry. Prices retrieved from shopware.com/en/pricing the same day.
What the B2B Suite was — and why it is ending
The B2B Suite was Shopware’s first answer to the question of how a shop system models business-to-business trade. It arrived as one large plugin: employee management, roles, budgets and quotas, order lists, quick orders — one package, all on or all off.
The official description is still online and notably plain:
“The B2B Suite provides you with the option of equipping your store with the most important B2B functions. These include budgets and quotas, order lists and quick orders.” — docs.shopware.com, B2B Suite Administration
Directly above it sits the note that the product is no longer being developed and that “all new features will be handled via the B2B components”.
The genuinely hard date sits further down that page and is left out of most summaries:
“The following installation guide only applies if you purchased your Shopware Evolve Plan (or higher) by May 23, 2025. Starting from May 24, 2025, only the B2B Components will be available in the Evolve Plan (and higher).”
That matters more than the 6.8 end date, because it answers the question people actually have: can I still get the Suite at all? Answer: no, if your plan was purchased after 23 May 2025. Anyone starting a B2B project today has no choice left between Suite and Components — the choice was made for them.

The architectural reason behind the replacement
The Suite was a plugin that extended the storefront with its own templates and controllers. That worked as long as “Shopware” meant “Shopware storefront”. The moment a project goes headless — own frontend, Store API, maybe an app too — the model breaks: functionality that lives in Twig templates simply does not exist for a React or Vue client.
The B2B Components solve this by shipping each feature as a standalone component with its own Store API routes. This is not a rebrand, it is a different construction with a practical consequence: you can enable employee management and leave quote management off. With the Suite it was the whole package or nothing.
The B2B Components in detail
Shopware’s developer documentation lists the components here. In summary:
| Component | What it solves |
|---|---|
| Employee Management | Sub-accounts for a business customer’s staff, roles, permissions, invitations |
| Quote Management | Quote request from the cart, negotiation, conversion into an order |
| Order Approval | Approval workflow: orders above a threshold need a designated approver |
| Individual Pricing | Catalogue-wide discounts and company-specific pricing including volume tiers |
| Quick Order & Shopping Lists | Fast entry by SKU, reusable shopping lists |
| Organization Unit | Modelling complex company structures with differentiated access rights |
Employee management and roles
This is the component most projects come looking for in the first place. The core idea is simple and stated plainly in the docs:
“Roles can be used to bind multiple permission to employees with contexts. Every employee can have one assigned role.” — developer.shopware.com, B2B Roles
One detail matters in daily use: the business partner can define a default role that is preselected for every newly created employee. That sounds trivial, but it decides whether a 40-person purchasing department is set up in ten minutes or two hours.

Worth understanding: these roles are not the administration’s ACL roles. They live in the storefront customer account. An employee with the role “may order up to €5,000” is not a backend user — they are a customer with a restricted context.
Order approval: the workflow spreadsheets cannot do
The approval component is the one most often underestimated, and it marks the shift from “we email PDFs back and forth” to “we have a process”. The documentation describes two entities:
An approval rule is a set of conditions that must be met for an order to require approval. According to the docs, conditions can be based on order total, currency, or the role of the ordering employee. Each rule has a priority that determines evaluation order.
A pending order is an order awaiting approval. It carries the order data, the employee who placed it, and the rule that matched.
Permissions come in three clean layers:
- Employees with “Can view all pending orders” see every waiting order
- Employees see their own pending orders without any special permission
- The business partner (the main account) sees and decides on all orders from their employees

Individual Pricing: where it gets technically interesting
The pricing component is the newest and the one with the widest reach, because B2B prices are almost never simple. The documentation describes a four-phase runtime flow:
- Context creation — the system identifies whether it is dealing with a business partner, an employee, or a tag-based customer
- Product loading — a subscriber hooks into the Store API product-loaded event
- Price resolution — matching rules are pulled from a computed cache
- Price application — single price with optional strike-through, or a volume tier
One sentence from the docs deserves attention, because it pins down behaviour you would otherwise have to discover by trial:
“If multiple rules match at the highest priority level, the one with the lowest price is selected.”
On a tie at the highest priority level, the lowest price wins — not the oldest rule, not the most recently edited one. That is a deliberate decision in the customer’s favour, and a frequent stumbling block for anyone running several discount campaigns in parallel and wondering why the weaker one applies.
The price question: do you need Evolve?
This is where it gets expensive, and where measuring the primary source beats copying blog posts. On 30 Aug 2026 we loaded the pricing pages in both language versions and extracted the text.
| Plan | Price (as of 30 Aug 2026) | B2B Components included? |
|---|---|---|
| Community Edition | free | no |
| Rise | from €600/month excl. VAT | no |
| Evolve | from €2,400/month excl. VAT | yes |
| Beyond | custom (“Contact Sales”) | yes |
The decisive number is the jump from Rise to Evolve: a factor of four. Wanting B2B features inside your licence means paying not €600 but €2,400 a month — €28,800 a year instead of €7,200. That €21,600 annual difference is the real question of this article, and it is not “are the Components good?” but: does the share you actually use justify that sum?
For Beyond we deliberately quote no figure. The pricing page says “Custom”. Any number you find for it online — including in older articles of ours — is guessed or stale. A guessed number looks identical to a measured one in a table, and that is precisely the problem.
If you want the full cost picture: we broke it down in What does Shopware 6 cost? and Shopware store costs, and covered hosting in Shopware Cloud.
What the free core actually does — measured, not assumed
Now the part no vendor writes, because nobody has an interest in it. We installed Shopware 6.7.13.1 from scratch and looked at what is there without any licence.
The hard finding first
We searched for B2B structures, in source and in the live database:
| Search | Hits in the free core |
|---|---|
Files with “b2b” in the name (vendor/shopware/core) | 0 |
| Tables with “b2b” in the name | 0 of 252 |
| Tables for employee / quote / approval / organization / shopping_list | 0 / 0 / 0 / 0 / 0 |
| DAL entities for employee / quote / approval / budget | 0 / 0 / 0 / 0 |
| DAL entities in total | 231 |
find vendor/shopware/core -iname “b2b”, table counts from the installation’s information_schema.tables, entity list from the booted application’s DefinitionInstanceRegistry via a custom console command.
This is unambiguous and leaves no room for interpretation: the B2B Components are not “hidden in the core and merely switched off”. They are simply not present. No feature flag, no disabled bundle, no empty tables waiting for a licence key. If you want them, you buy Evolve.
And now the counter-measurement
This is where most articles stop, and where it gets interesting. Because “no B2B components” does not mean “no B2B”. In the same installation we actually created a typical business-customer setup — net-price customer group, rule, three-step quantity scale:
customer_group (displayGross=false): 57 ms
rule + condition: OK
tiered prices in DB: 3
from 1 pcs: net 90.00 / gross 107.10
from 10 pcs: net 80.00 / gross 95.20
from 50 pcs: net 70.00 / gross 83.30
Executed on 30 Aug 2026 via a custom Symfony console command against the running instance; values then read back directly from the product_price table, not taken from the write operation’s return value.
That ran on a Community Edition with no licence whatsoever. And it is not a workaround, it is the regular data model: the product_price table has quantity_start, quantity_end and rule_id columns — quantity tiers bound to a condition are a core feature.

Alongside that come the building blocks that make it usable:
| Building block in the free core | measured value |
|---|---|
| Rule condition types total | 112 |
of which customer-related (customer*) | 34 |
| Rule classes in source | 120 files |
Customer group with net display (display_gross) | present |
| Registration toggleable per customer group | present |
| Payment methods out of the box | 4 (incl. invoice payment) |
| Store API routes | 88 |
Directly usable rule conditions for B2B scenarios include CustomerGroupRule, CustomerNumberRule, CustomerTagRule, BillingCountryRule, CartAmountRule, OrderCountRule and DaysSinceLastOrderRule.
What this means in practice
Put the two measurements side by side and an uncomfortable truth appears for both camps:
Without a licence you get: customer-group-dependent prices, net price display for trade customers, quantity tiers, invoice payment, new-customer approval via customer group registration, and 112 rule types to condition all of it. For a substantial share of shops calling themselves “B2B shops”, that is the complete set of features they actually use.
Without a licence you do not get: multiple users under one customer account, roles and permissions inside a customer company, approval workflows, in-shop quote negotiation, shopping lists, organisation units.
The dividing line is surprisingly clean: everything to do with prices is free. Everything to do with several people inside one customer company costs €2,400 a month.
That is not a coincidence, it is logical. Prices are data attached to a product — the core has that anyway. Multi-user capability in the customer account is a second identity model, and that is expensive to build and expensive to maintain.
The decision tree: do you really need Evolve?
Instead of a recommendation, a checklist. Answer it honestly before signing off €21,600 in extra annual cost.
You need the B2B Components if any of these is true:
- Several people order under one company account at your customers, and they should not share a password
- Orders above a certain value must be approved internally before they reach you
- Your customers negotiate prices and you do not want that process to live in email
- Your customers have sites or departments with different permissions and prices
- Your customers reorder the same baskets regularly and need shopping lists
You probably do not need them if:
- One person orders per customer (the classic case for trades, small businesses, medical practices)
- You need different prices, but not different users
- Net display, tiered prices and invoice payment are your entire B2B requirement
- You are just starting out and do not yet know which processes your customers actually have
The most expensive mistake in B2B projects is not picking the wrong edition. It is buying the edition before knowing your customers’ processes — and then paying for features nobody switches on. Going the Community Edition route with customer groups and tiered pricing is not a stopgap; it is the reliable way to find out whether you need more.
The third option: third-party extensions
Between “nothing” and “€2,400/month” sits the Shopware Store. There are third-party extensions for employee accounts, quote features or approvals. Honestly: we did not test them for this article, so there is no recommendation here. What you should check before going that route:
- How many active installations does it have, and when was the last update?
- Does it support Shopware 6.7, and is 6.8 announced?
- Does it ship Store API routes or only storefront templates? (In a headless setup, that decides everything.)
- What happens at the next major upgrade if the vendor does not follow?
That last point is exactly where the B2B Suite is failing right now — except with a small vendor it arrives faster and without notice.
Migrating from B2B Suite to B2B Components
If you run a live B2B Suite today, this is your section. Shopware ships a dedicated extension for it, and the documentation is unusually concrete.

What the migration technically does
According to the docs it creates three tables, and their purpose says a lot about the quality of the tool:
| Table | Function |
|---|---|
b2b_components_migration_state | Migration status per entity |
b2b_components_migration_map | Maps old records to new ones (traceability) |
b2b_components_migration_errors | Logs errors encountered |
The mapping table in particular is a good sign: it lets you trace every new record back to its origin after the fact. Without such a table, a bulk migration is a black box where you count records at the end and hope.
Prerequisites you need to know beforehand
From the official prerequisites page:
- Backup. Literally: if you already hold data in B2B Commercial, back up the database before starting. The migration adds data, it removes nothing from the B2B Suite — but a backup is the only way back.
- The message queue worker must be running. The migration works asynchronously. If the worker is down, nothing happens — silently.
- B2B Suite version 4.9.3 minimum.
- Budget management requires B2B Commercial 7.6.0 or higher.
And one detail that can ruin a Friday-evening migration if you do not know it:
“The Organization Unit of the budget will be empty after migration and needs to be manually assigned in B2B Commercial.”
A budget’s organisation unit is empty after migration and must be assigned by hand. That is not a malfunction, it is documented behaviour — but anyone who reads only “migration successful” and does not look ends up with unassigned budgets in the system.
The practical plan
- Take inventory. Which Suite features do you actually use? In our experience the answer is much shorter than the feature list.
- Gap analysis. Suite and Components are not a 1:1 mapping. For each feature you use, check whether a counterpart exists — and whether it behaves the same.
- Raise the Suite to ≥ 4.9.3, otherwise the migration will not start.
- Rehearse on a copy. Not on production. Never on production.
- Check the worker, run the migration, then read
b2b_components_migration_errors— not just the success message. - Reassign budgets manually (see above).
- Rebuild the frontend. This is the underestimated item: Suite templates are not Components templates. Anyone who customised the storefront does that work a second time.
Point 7 is usually the most expensive. With a customised storefront, do not budget it in days.
How the B2B features are actually activated
One point that regularly causes confusion in consulting calls: the B2B Components are not switched on globally. They are granted per customer or per customer group. The user documentation describes both routes:
Per customer: open the customer under Customers > Overview and activate the individual options.
Per customer group: under Settings > Shop you can preset which B2B functions a customer group receives at registration. This requires the customised registration form to be active for that group. The docs list these as individually toggleable: Quick Orders, Employee Management, Quote Management, Order Approval, Shopping Lists and Organisation Units.
This is the modular promise made real — and also a trap: anyone who buys the Components and wonders why “nothing is there” has usually just not activated them for any customer.
Frequently asked questions about the Shopware B2B Suite
What is the Shopware B2B Suite?
The B2B Suite is an extension for Shopware 6 that adds business-customer features to a shop — according to Shopware, budgets and quotas, order lists and quick orders among others. It was built as one bundled plugin and is no longer being developed.
Is the Shopware B2B Suite still supported?
Not permanently, no. Shopware states in its own documentation: “B2B Suite will no longer be supported starting Shopware 6.8.” On top of that, it has not been included in newly purchased Evolve plans since 24 May 2025 — those get the B2B Components exclusively.
What is the difference between B2B Suite and B2B Components?
The Suite was a single large plugin that bundled all features together and leaned heavily on the storefront. The B2B Components are standalone modules that can be activated individually per customer or customer group and work in headless architectures through Store API routes. In practice: more choice, but also no 1:1 migration.
Which Shopware edition do I need for B2B?
For the B2B Components you need at least the Shopware Evolve plan, which according to the pricing page (as of 30 Aug 2026) starts at €2,400 per month excluding VAT. Shopware Rise at €600/month does not include them. Basic B2B capabilities such as net price display, customer group pricing and quantity tiers are already part of the free Community Edition.
Can I run a B2B shop on the Shopware Community Edition?
Yes, for many scenarios. In a freshly installed Community Edition 6.7.13.1 we measured: customer groups with net price display, three-step quantity tiers, 112 rule condition types (34 of them customer-related) and invoice payment are present and working. Not included are employee accounts, roles, approval workflows, quote management and shopping lists — our installation had 0 of 252 tables for those.
Are the B2B Components part of the Shopware core?
No. This is a common misunderstanding created by the phrase “part of the core” in older announcements. We checked: in the shopware/core package of version 6.7.13.1 there is not a single file with “b2b” in its name and no entity for Employee, Quote, Approval or Organization. The Components arrive through the separate Shopware Commercial extension, which is tied to the Evolve plan.
How do I migrate from the B2B Suite to the B2B Components?
Through the official B2B Suite Migration extension. Prerequisites per Shopware: B2B Suite version 4.9.3 or higher, a running message queue worker, and a database backup. The migration adds data and deletes nothing from the Suite. Important: for budgets, the organisation unit stays empty and must be assigned manually. The largest effort is usually not the data migration but adapting the storefront.
What does a Shopware B2B shop cost in total?
The licence is only one line item. On top of €2,400/month for Evolve come hosting, development, storefront customisation, interfaces to ERP or inventory systems, and ongoing maintenance. We broke down a full cost calculation in Shopware store costs.
Do the B2B Components work headless?
Yes, and that is one of the main reasons the Suite is being retired. The Components ship their own Store API routes — the documentation describes a dedicated Store API for organisation units, for example. The old Suite was tightly bound to the Twig-based storefront, which made it unusable for custom frontends.
When does an order approval trigger?
You define that through approval rules. A rule bundles conditions — per the docs, things like order total, currency, or the ordering employee’s role — and carries a priority that determines evaluation order. When a rule matches, the order becomes a pending order in the approval process instead of going straight through.
Conclusion: the decision is smaller than it looks
The Shopware B2B Suite is finished. That is not an opinion, it is in Shopware’s own documentation, with dates attached: support ends with 6.8, and it has not been sold since May 2025. If you run it, migration is not an option — it is an appointment.
For everyone else, the real question is not “Suite or Components?” but: are you paying €21,600 a year extra for features your customers actually use, or for features that look good on a requirements list?
Our measurement gives you a usable dividing line. The free core handles everything to do with prices: net display per customer group, tiered pricing, 112 rule types to condition it, invoice payment. It handles nothing to do with several people inside one customer company: no employee accounts, no roles, no approvals, no quotes.
If one person orders at each of your customers, you very likely do not need Evolve. If a buyer orders, a department head approves and accounting expects an invoice — then €2,400 a month is not a surcharge, it is the price of not building that process yourself.
And the mistake genuinely worth avoiding appears in no price table: buying the edition before knowing your own customers’ processes. The Community Edition is the cheapest way to find that out — and, as measured, it reaches considerably further than its reputation in B2B circles suggests.
Read next: Shopify vs. Shopware for the system choice before this one, Shopware installation for the technical entry point, Shopware Cloud for the hosting decision, and Best shop system for the wider overview.
