Picture the moment your Shopware partner says a sentence in the regular status meeting that you don’t want to hear: “The B2B Suite your entire wholesale business runs on won’t be maintained forever.” No drama, no red screen. Just a module that runs in production, carries revenue, processes orders every day – and still has an expiry date. Exactly this moment is the starting gun for a project most people would rather postpone: the migration from the Shopware B2B Suite to the B2B Components.
Don’t want to shoulder the migration alone? We migrate B2B Suite shops to B2B Components – with a reliable effort estimate up front: Shopware B2B agency – services & approach.
And it reliably does get postponed, for an understandable reason: as long as the Suite keeps running, nothing hurts. No outage, no ticket, no pressure. Until it suddenly does hurt, because the roadmap moves closer and a version upgrade is due at the same time. The good news: this is not a fire alarm but a plannable project. The bad news: whoever leaves it until the last minute turns a calm rebuild into an expensive emergency. This article shows you what really happens during the migration, what it costs, how long it takes, and what an honest migration demo looks like before you sign any contract.
Why the migration belongs on the table now
Let’s start with the sober facts, because this is where more half-truths circulate than reliable statements. Shopware has moved the B2B Suite, the classic, monolithic B2B plugin, into maintenance mode and positioned the modular B2B Components as its successor. For new installations, the Components have been the only path since May 2025: new B2B projects on the Evolve plan no longer get the Suite at all – they start modular right away.
The Suite’s end of support is tied to Shopware 6.8. And this is where a close look beats stirring up panic: Shopware has officially postponed the next major version 6.8 to 2027. So there is no gun to your head, and anyone selling you “by the end of the year or your shop grinds to a halt” is exaggerating. But the direction is unambiguous, and it is not going to reverse.
That is precisely the constellation in which expensive mistakes are made. Not because the deadline is tomorrow, but because it feels far enough away to ignore – and close enough to catch you cold if you already have a replatforming, an assortment expansion, or an ERP integration ahead of you.
“The migration is not an if, it is a when. The cheapest moment is the one you choose yourself, not the one the roadmap forces on you.”
If you still want to sort out the larger context – Suite, Components, and the honest decision for new projects – the following section sums up features, pricing, and status in compact form. This article starts one step later: you run the Suite in production, and the question is no longer whether you switch, but how.
The B2B Suite in 2026 at a glance: features, pricing, status
Before we get to the how of the migration, for the sake of completeness the what: where does the Suite stand today, what can the Components do, and what does the framework around them cost? If you only want to settle the migration question, simply skip this block.
Functionally, the B2B Suite was a complete package: sub-accounts with roles and permissions, approval workflows with budget limits, quote requests, quick ordering via SKU or CSV, shopping lists, customer-specific assortments and prices, plus OCI/punchout connections to procurement systems. The B2B Components cover this spectrum modularly – as six individually activatable building blocks: Employee Management, Quote Management, Order Approval, Quick Order, Shopping Lists, and Organization Units.
| Criterion | B2B Suite (legacy) | B2B Components (new) |
|---|---|---|
| Architecture | Monolithic plugin – everything bundled | Six individually activatable modules |
| Activation | Complete package | Only the building blocks you need |
| Ongoing development | Maintenance only, no new features | Active, continuously extended |
| Availability | Being phased out – no more support from Shopware 6.8 | Standard for new projects (from Evolve) |
| Customization | Requires changes to the entire plugin | API-first, selectively extensible |
| Recommendation for new projects | Do not start anymore | First choice |
| Existing shops on the Suite | Plan the migration | Migration target |
To put the running costs in context: as of June 2026, Shopware 6 comes in three plans. Rise starts at around 600 euros per month but includes no B2B functionality. Evolve starts at around 2,400 euros per month and is the tier from which the B2B Components are included. Beyond is negotiated individually and, according to publicly available estimates, starts at around 6,500 euros per month (as of Q2 2026). The bigger line item is the implementation anyway: for mid-market new-build projects, the one-off budget typically ranges between 80,000 and 300,000 euros. Prices change regularly – verify them against up-to-date figures before signing any contract.
What really happens during the migration – and what doesn’t
The most dangerous sentence in any migration conversation goes: “We’ll simply carry that over one to one.” For the B2B Suite, it is not true. Suite and Components share the same functional DNA (employee management, quotes, approvals, quick ordering, customer-specific assortments), but technically they are built in fundamentally different ways. The Suite is one bundled, all-in-one plugin. The Components are individually activatable modules with an API-first architecture, closer to the core of Shopware 6.
In practice, that means: your data (customer hierarchies, roles, assortment assignments, price lists) can as a rule be migrated. Your configuration can largely be recreated, because the functional concepts are the same. What does not come along unchecked are your custom adaptations: every extension, every template override, every piece of individual logic that has been docked onto the Suite over the years. This block is exactly what decides whether your migration turns into a manageable rebuild or half a new project.
That is not bad news – it is an opportunity you should not give away. Most Suite installations that have grown over time drag along customizations nobody needs anymore: workarounds for problems long since solved, or features nobody ever used. A migration is the natural moment to shed this ballast instead of expensively lifting it onto a new architecture a second time.
What the migration costs
Now for the question most people are reading this article for in the first place. Up front, the honest answer no salesperson likes to give: there is no credible flat figure for “the migration.” Anyone quoting you a fixed price without looking at your setup is either guessing or will claw it back later. The range is real, but it follows clear drivers.
By far the biggest cost driver is the depth of your custom adaptations. A Suite installation that runs close to standard, has a few modules active, and draws its B2B logic from configuration is a project in the low five-figure range. An installation individualized over years, with its own plugins, a deeply customized checkout, and an OCI connection that has grown over time, can cost a multiple of that – not because of the migration itself, but because every special case has to be translated to the new architecture one by one.
The second driver is the question of whether you migrate in isolation or combine projects. If you already have a version upgrade, a frontend relaunch, or a new ERP integration ahead of you, do not separate the projects. Otherwise setup, testing, data migration, and go-live are all incurred twice.
“Put the migration and an upgrade that is due anyway into one project, and you pay for setup once instead of twice. That is the biggest lever on total costs.”
What is often overlooked here: on the Evolve plan, the Components themselves do not cost you a separate license – they are included from Evolve upward (as of May 2026, from around 2,400 euros per month). The migration costs are therefore almost entirely project costs, meaning analysis, development, data transfer, and testing, and not a licensing question. That is the good news for your investment request.
“You are not buying a new product. You are cleanly rebuilding one you already own.”
The exact plan conditions change regularly – check them against the latest information on shopware.com before every contract.
The realistic timeline
A B2B migration is no weekend job, but it is no year-long project either. In practice, it breaks down into five phases whose duration depends almost entirely on the first one. And precisely this lead work is the whole difference between “calm” and “expensive.”
It starts with the inventory, and this is the most important and most frequently underestimated step. Here you catalog which Suite features you actually use, which custom adaptations exist, and which of them can be migrated, replaced, or dropped without replacement. Take this phase seriously and you walk away with a reliable effort estimate. Skip it and you are building your budget on sand.
Next comes the mapping: every Suite feature in use is assigned its counterpart in the Components, and every gap is named. Then the build in a staging environment, where the Components are configured, the custom logic is ported, and the data is migrated – in parallel with live operations, without your shop standing still for a single day. This is followed by the test phase with your real processes and real customer accounts, not demo data. And finally, the go-live.
That this go-live, given clean preparation, is the most unspectacular part of the project is no accident – it is the goal. An uneventful go-live means the work happened beforehand, not on the night of the switchover. A lean, close-to-standard installation typically moves through these five phases in a matter of weeks. A complex, individualized installation with an OCI connection and many active modules is better planned in months. The difference is not the migration as a piece of technology, but the number of special cases that have to be carried through every single phase.
The B2B Components demo that actually tells you something
Before you award a migration project, you want to see that your partner understands what they are doing. A generic B2B Components demo does not help you there. It shows that the product can do sub-accounts – which you have long known. What you need is a demo that sits on your specific migration case.
Confront the demo with your three toughest existing processes. Not “can it do approvals,” but “one of your customers with fourteen employees, three cost centers, and approval required from 2,500 euros runs in the Suite like this today – show me the same flow in the Components.” Have them show you, using a concrete example, how a custom adaptation from your installation lands in the new architecture. And if OCI or punchout is business-critical for your enterprise customers, play through exactly that case. It is the component most often glossed over in demos, and it comes ready-made in the core of neither the Suite nor the Components – it runs through established extensions such as PunchCommerce or B2Bsellers.
The most important question at the end is not “what does the migration cost,” but “what does a production-ready B2B shop on Components cost us over three years,” meaning platform, migration, operations, and maintenance combined. That is the number that belongs in the investment request. A Shopware agency with real B2B migration experience answers that question concretely instead of selling you a license upsell.
What the official documentation gives you – and what it doesn’t
The gap between the official docs and your real project is exactly the space where a migration stands or falls. Shopware documents the switch in a dedicated B2B Suite migration guide in the developer docs. It lays out which Suite concepts correspond to which Component counterpart and what to watch out for technically. For the actual data transfer, Shopware also provides a dedicated migration tool: via the CLI commands b2b:migrate:commercial and b2b:migrate:progress, the data migration runs in the background through the message queue, and the tool is continuously extended.
Take this documentation for what it is: a technical map for developers, not a project plan and not a cost estimate. It answers “how does concept X translate technically,” not “what does that mean for our specific setup, our budget, and our timeline.” Skip that translation work and you end up with a migrated system that is technically clean and still does not fit your own processes. This is exactly where it is decided whether a migration deserves the name or merely shoves data from A to B.
Conclusion: The calm rebuild beats the expensive emergency
Back to that sentence from the status meeting. The B2B Suite being phased out is not a surprise that steamrolls you – it is an announcement with lead time. That is exactly what makes it plannable. You decide whether you make the switch in a calm window between two peaks, coupled to an upgrade that is due anyway, with a clean inventory and no time pressure, or whether you wait until the roadmap dictates the date and the market for good Shopware teams gets tight.
Migrating to the B2B Components is not a risk you take on. It is a risk you take down: away from a module with no future, toward an architecture Shopware is actively investing in. The only mistake you can make is to reserve it for “later” — until later means “right now.”
Frequently asked questions about migrating to B2B Components
Do I have to migrate the B2B Suite right away?
No, but you should plan the migration now. The Suite remains supported until the release of Shopware 6.8, which has officially been postponed to 2027. So no acute standstill is looming. The point of planning early is to place the switch in a calm time window and ideally couple it to an upgrade that is due anyway, instead of catching up on it under time pressure.
Can I carry my data over one to one?
Data such as customer hierarchies, roles, assortments, and price lists can usually be migrated, and the standard configuration can be recreated. What does not come along unchecked are individual custom adaptations and plugins. They have to be checked for compatibility one by one and translated to the new, modular architecture. Precisely this share determines the effort.
What does the migration from the B2B Suite to the B2B Components cost?
There is no flat figure. The costs are almost entirely project costs, meaning analysis, development, data transfer, and testing, and not a licensing question, since the B2B Components are already included on the Evolve plan (as of May 2026, from around 2,400 euros per month). The biggest cost driver is the depth of your custom adaptations. Combining the migration with a version upgrade that is due anyway noticeably lowers the total costs.
Will my shop stand still during the migration?
No. The Components are set up, configured, and tested in a staging environment while your live shop keeps running as normal. With clean preparation, the actual go-live is the most unspectacular step of the entire project.
Next step: We analyze the state of your B2B Suite installation and deliver the cost and time plan for your migration: Request a migration check.
As of June 2026. Roadmap statements (in particular the date for Shopware 6.8) as well as the plan structure and pricing of the B2B Components are adjusted regularly by Shopware. Verify the current EOL communication and licensing details against up-to-date information on shopware.com or with your implementation partner before they make their way into a budget or a contract.