Magento B2B on Hyvä: What Works, What Breaks, and What It Costs in Time

Most Hyvä migration estimates are built for a B2C catalogue. Then someone mentions company accounts, and the number doubles. B2B is the single biggest multiplier on a Hyvä timeline, and it is the one merchants and agencies both underestimate, because the features sound like backend features and are almost entirely frontend.

First, which B2B are we talking about

Two very different situations hide behind the same word.

On Adobe Commerce, B2B is an official module suite: company accounts with their own user hierarchy, shared catalogues, requisition lists, negotiable quotes, purchase orders with approval rules, and payment on account. It is a large, coherent feature set, and it ships a large, coherent amount of storefront code.

On Magento Open Source there is no native B2B. What merchants call their B2B setup is usually three or four third-party extensions plus some custom work: a customer-group price display here, a minimum order quantity there, a quote request form somebody built in 2021. It is smaller, but it is bespoke, which means nothing about it appears on any compatibility tracker.

The distinction matters because it decides who owns the frontend code you are about to rewrite. One case is a known quantity. The other is an archaeology project.

Why B2B is frontend-heavy

Here is the thing people get wrong. B2B feels like backend functionality, because it is about pricing rules, permissions and approvals. But nearly all of it is delivered to the customer as a screen, and in Luma those screens are built with Knockout and Magento UI Components, which is exactly the layer Hyvä replaces.

The business logic underneath survives the migration untouched. The company entity, the price rules, the approval engine, the API endpoints: none of that cares what your theme is. What does not survive is every interface a buyer touches.

What actually breaks, screen by screen

• Company account self-service. The company profile, the user hierarchy, roles and permissions, inviting a colleague. This is a small application living inside the customer account area and it is all view layer.
• Requisition lists. Adding, editing, reordering from a saved list. Heavily interactive, heavily Knockout in Luma.
• Negotiable quotes. The request, the back and forth, the expiry, converting a quote to an order. This is the most complex single surface in Magento B2B and the most commonly underestimated.
• Purchase orders and approval flows. The buyer submits, the approver sees a queue, rules decide who has to sign off. Multiple screens, multiple states.
• Shared catalogue and customer-group pricing display. Not the pricing logic, the display of it. See below, because this one has a trap in it.
• Checkout. Payment on account, purchase order as a payment method, quote checkout. Checkout is already a separate project on any Hyvä migration, and B2B makes it a bigger one.

The customer-group pricing trap

This deserves its own section because it catches experienced teams.

Customer-group and tier pricing is frequently delivered through Magento’s private content mechanism, so that one cached page can serve every customer and the correct price is filled in afterwards by JavaScript. It is a reasonable design and it works fine for a human with a browser.

It has two consequences worth deciding on deliberately rather than inheriting. The buyer sees the list price for a moment before their contract price replaces it, which on a slow connection looks like a pricing error and generates support tickets. And because the price is not in the HTML, it is invisible to anything that does not execute JavaScript, which includes every major AI crawler and any feed scraper.

A Hyvä rebuild is the moment to decide whether that trade is still the right one. For a B2B store where every logged-in buyer sees a different price, caching the page and patching the price is usually correct. For one where pricing is public and only volume discounts differ, it often is not.

What the published projects actually took

Agencies publishing timeline ranges agree on the direction even when they disagree on the numbers. A standard catalogue is commonly quoted at eight to fourteen weeks. Adding the Adobe Commerce B2B module pushes the same guidance to twelve to eighteen weeks, and another published range puts full Adobe Commerce B2B at twelve to sixteen.

Hyvä’s own case study index is the better evidence, because the projects are named. A full Adobe Commerce B2B suite build ran to four months with two in-house Magento specialists on the client side. A multi-brand, multi-language B2B store took three months. The longest stated project on the entire index, at twenty weeks, was four international store views plus a rebrand.

So the honest planning number for a real B2B store is three to four months, not eight weeks. If a proposal says otherwise, ask which of the six screens above are in scope.

How to scope it without guessing

Inventory the screens, not the features. This sounds pedantic and it is the whole game. A store can have the B2B module enabled and use three of its eight features, in which case you are rebuilding three surfaces, not eight.

Pull your actual usage before anyone estimates. How many companies have more than one user? How many requisition lists exist and when were they last touched? How many quotes were raised in the past year? On a surprising number of B2B installs the answer to at least one of those is zero, and a feature nobody uses is a feature you do not port.

Then decide deliberately where the Luma theme fallback is acceptable. The company account area is a strong candidate: it is logged-in, low traffic, not indexed, and the performance win there is worth very little. Keeping it on Luma for the first release and rebuilding it later is a legitimate plan, as long as there is a date attached. We covered the mechanics and the trade-offs of that fallback in our guide to migrating a live store to Hyvä.

Finally, scope checkout as its own project with its own budget, and audit your extensions before committing to anything. B2B stores tend to carry more integrations than B2C ones, and extension compatibility is what decides whether the estimate holds.

The part nobody puts in the proposal

B2B buyers are not browsing. They are reordering, checking a contract price, and getting back to work. The performance argument for Hyvä on a B2B store is weaker than on a consumer store, because your customers are not going to abandon you over 400 milliseconds.

The real arguments are different and worth being straight about. Development velocity improves, so the changes your sales team keeps asking for stop taking a fortnight. The frontend becomes maintainable by people who are not Magento specialists. And you stop carrying a 2010-era JavaScript stack that fewer developers can work on every year.

If none of those matter to you right now, a B2B Hyvä migration is a defensible thing to postpone. That is a legitimate answer and you will not hear it often.

Book a free strategy call

Send us your B2B setup and we will tell you which screens are actually in use, which ones need rebuilding, where the Luma fallback is the right call, and what the timeline honestly looks like. Book a free strategy call.