Luma to Hyvä: what actually breaks, and how to plan for it

Hyvä removes RequireJS, KnockoutJS, jQuery and roughly 95% of Luma's CSS. That is exactly why it is fast — and exactly why every Luma-dependent extension on your store is a migration line-item. After 25+ Hyvä builds, here is what actually breaks.

The three categories of breakage

1. Frontend extensions with Luma templates. Anything rendering phtml with jQuery widgets — sliders, layered nav, quick view, reviews — needs a Hyvä compatibility module. Check the Hyvä compatibility tracker first; the popular vendors (Amasty, Mageplaza, Magefan) cover their bestsellers, and the long tail is where your budget goes.

2. Checkout customizations. Luma checkout is KnockoutJS; Hyvä Checkout is not. Custom fields, payment method renderers and delivery-date pickers all need to be rebuilt — usually smaller and cleaner, but it is real work that quotes routinely miss.

3. Inline scripts in CMS content. Page Builder content and CMS blocks with embedded jQuery die silently. Audit cms_block and cms_page for <script> tags before you scope.

What the audit looks like

Run composer show against the compatibility tracker, grep the theme for data-mage-init and x-magento-init, and list every checkout customization. That produces a fixed list: compatible / needs-bridge / needs-rebuild. From that list, a real quote is possible — without it, every Hyvä estimate is a guess.

What you get for the trouble

• 80%+ less JavaScript shipped to the browser
• Lighthouse mobile from the 40–60 range to 90+, routinely 95+
• CLS to zero with disciplined image and font handling
• A Tailwind + Alpine codebase any frontend developer can work on

The migration pays for itself when the store has meaningful mobile traffic — which in 2026 is every store.