When not to choose Hyva

Decision brief first, then the engineering view. Part 3 of the Hyva series.

Decision brief: the honest "no"

The previous post argued Hyva is the sweet spot for most Luma stores. This one is the counterweight: the situations where adopting Hyva costs more than it returns, or where a different architecture simply fits better. Reading both is what turns a preference into a decision.

Five cases where Hyva is the wrong tool

1. A headless PWA is already mandated

If the business has already committed to a headless storefront — a React/Vue application over GraphQL, a shared cart across web and native, an app-like journey — Hyva does not enter the picture. Hyva is a server-rendered theme; it optimizes the Luma-style path, not the headless one. Adding Hyva on top of a PWA decision is solving a problem you chose not to have.

This is the cleanest "no": the architecture decision was made upstream, and Hyva competes with it rather than complements it.

2. The storefront is a tiny slice of a larger app

Some Magento installations are not really storefronts — they are the commerce engine behind a portal, a configurator, or a heavily custom application where the catalog page is a minor surface. If less than, say, a fifth of the user journey touches the theme, the performance payoff of rewriting it is small, while the compat work still has to be done. Spend the effort on the parts users actually feel.

3. Heavy reliance on Luma-only extensions with no Hyva port

Hyva needs a Hyva-specific template for any module that renders interactive frontend. Many popular extensions ship one; many do not. If your store depends on several niche or abandoned extensions that only provide Luma PHTML, migrating to Hyva means writing and maintaining those templates yourself.

A rough rule from the field: count the interactive third-party modules, check how many publish a Hyva compatibility package, and treat the gap as custom frontend work. When the gap is large and the extensions are unmaintained, the rebuild cost can exceed the benefit — especially if those modules are central to the buying flow.

4. Complex B2B with heavy negotiated flows

Magento B2B brings company accounts, shared catalogs, quote negotiation, and approval rules. Much of that UX lives in default or custom Luma templates. Hyva supports B2B, but the compatibility surface is larger and some B2B-specific widgets need hand-built templates. If your differentiation is the B2B negotiation experience rather than raw catalog speed, validate those specific flows on Hyva early — do not assume they "just work."

5. The license math does not close

Hyva is a paid, per-project license. For a single high-traffic storefront, the license is a rounding error against the conversion gain from faster pages. For a portfolio of many small, low-traffic storefronts, the cumulative license cost per store can outweigh the benefit each one sees. If you operate dozens of small catalogs, model the license against the performance gain per store before standardizing on Hyva.

Engineering view: what the "no" actually means

Saying "Hyva is not the right tool here" does not mean "do nothing." It means pick the lever that matches the problem:

• Slow catalog, but headless is mandated → invest in GraphQL coverage and client caching, not a theme.
• A few Luma-only extensions block you → either replace them with Hyva-compatible equivalents, or scope the migration to the catalog/checkout and keep Luma for the dependent areas (a hybrid is viable short-term).
• B2B flows are central → prototype the specific negotiation widgets on Hyva before committing the whole storefront.
• Many small stores → standardize on a tuned Luma child theme or a shared PWA shell instead of per-project Hyva licenses.

The point is that Hyva optimizes one thing extremely well — the JavaScript weight of a server-rendered Magento theme. When your bottleneck is elsewhere, point the effort elsewhere.

How to make the call without guessing

Inventory, then measure. List every interactive module on the storefront, mark which have Hyva ports, and stand up a throwaway environment to benchmark the current Luma pages (category and product, where weight hurts most). The numbers turn "Hyva feels right" into "Hyva returns X on Y cost" — or the reverse, which is just as valuable to know early.

The next part of the series stops deciding and starts building: the architecture of a Hyva theme, beginning with the three pillars in practice.

Next in this series: Hyva architecture — the three pillars in practice — /blog/magento2-hyva-deep-dive