{"id":4025,"date":"2026-11-06T09:47:42","date_gmt":"2026-11-06T09:47:42","guid":{"rendered":"https:\/\/www.magento2-agentur.de\/?p=4025"},"modified":"2026-11-06T10:51:57","modified_gmt":"2026-11-06T10:51:57","slug":"hyvae-is-free-is-now-the-time-to-move-off-luma","status":"publish","type":"post","link":"https:\/\/www.magento2-agentur.de\/en\/hyvae-is-free-is-now-the-time-to-move-off-luma\/","title":{"rendered":"Hyv\u00e4 Is Free: Is Now the Time to Move Off Luma?"},"content":{"rendered":"

For most Magento stores still on Luma, yes. The Hyv\u00e4 theme has been free and open source since 10 November 2025, so the licence fee that used to block small projects is gone. What’s left is the migration work itself, and that depends almost entirely on how many frontend extensions and custom templates you run.<\/span>\u00a0<\/span><\/p>\n

Luma is slow, and the reason is its age. It was designed in 2015 around RequireJS and Knockout.js, and it ships a lot of JavaScript to every visitor whether they need it or not. On mobile, that shows up in Core Web Vitals, in bounce rates and, eventually, in revenue.<\/span>\u00a0<\/span><\/p>\n

Hyv\u00e4 replaced that frontend with Alpine.js and Tailwind CSS. For years the main argument against it was the licence cost on top of the build. That argument ended a year ago. So the question has changed from “can we justify Hyv\u00e4?” to “what will moving actually involve for our shop?” That’s what this post answers.<\/span>\u00a0<\/span><\/p>\n

<\/b>Luma vs Hyv\u00e4: what actually changes<\/span><\/b>\u00a0<\/span><\/h2>\n

Hyv\u00e4 only touches the storefront. Your backend, admin, catalogue, orders, ERP integration and APIs stay exactly as they are. That’s the main reason it’s a lower-risk project than a headless rebuild.<\/span>\u00a0<\/span><\/p>\n\n\n\n\n\n\n\n\n\n
\u00a0<\/span><\/td>\nLuma<\/span>\u00a0<\/span><\/td>\nHyv\u00e4<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
JavaScript<\/span>\u00a0<\/span><\/td>\nRequireJS + Knockout.js, hundreds of KB<\/span>\u00a0<\/span><\/td>\nAlpine.js, about 15 KB<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
CSS<\/span>\u00a0<\/span><\/td>\nLESS, full compiled stylesheet<\/span>\u00a0<\/span><\/td>\nTailwind CSS, unused classes purged at build<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Product page weight (vendor benchmark)<\/span>\u00a0<\/span><\/td>\n~0.9 MB<\/span>\u00a0<\/span><\/td>\n~0.15 MB<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Typical Lighthouse performance score<\/span>\u00a0<\/span><\/td>\n40\u201360<\/span>\u00a0<\/span><\/td>\n90+ achievable<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Templates<\/span>\u00a0<\/span><\/td>\n.phtml<\/span> + Knockout <\/span>.html<\/span> templates + UI components<\/span>\u00a0<\/span><\/td>\n.phtml<\/span> with Alpine attributes<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Works with<\/span>\u00a0<\/span><\/td>\nAll Magento 2 versions<\/span>\u00a0<\/span><\/td>\nMagento 2.4.4 and later, Open Source and Adobe Commerce<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The page-weight and Lighthouse figures come from vendor benchmarks on throttled mobile connections. Your numbers will differ. The direction won’t.<\/span>\u00a0<\/span><\/p>\n

For developers, the bigger change is how frontend code is written. Here is the same mini-cart counter in both themes.<\/span>\u00a0<\/span><\/p>\n

Luma, with a Knockout template bound to a UI component:<\/span>\u00a0<\/span><\/p>\n

<!– ko if: getCartParam(‘summary_count’) –><\/span>
\n<span class=”counter-number”<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0 data-bind=”text: getCartParam(‘summary_count’)”><\/span><\/span>
\n<!– \/ko –><\/span>\u00a0<\/span><\/p>\n

Hyv\u00e4, with Alpine.js straight in the <\/span>.phtml<\/span> file:<\/span>\u00a0<\/span><\/p>\n

<div x-data=”{ cart: {} }”<\/span>
\n\u00a0\u00a0\u00a0\u00a0 @private-content-loaded.window=”cart = $event.detail.data.cart”><\/span>
\n\u00a0\u00a0\u00a0 <span x-show=”cart.summary_count”<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 x-text=”cart.summary_count”><\/span><\/span>
\n<\/div><\/span>\u00a0<\/span><\/p>\n

No RequireJS config, no UI component XML, no separate template file. Developers who know HTML and a bit of JavaScript can read it on day one. That matters for maintenance costs long after launch.<\/span>\u00a0<\/span><\/p>\n

<\/b>What’s free, and what still costs money<\/span><\/b>\u00a0<\/span><\/h3>\n

“Hyv\u00e4 is free” is true, but it’s only part of the picture. Here’s the split:<\/span>\u00a0<\/span><\/p>\n\n\n\n\n\n\n\n
Product<\/span>\u00a0<\/span><\/td>\nPrice<\/span>\u00a0<\/span><\/td>\nWhat you get<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Hyv\u00e4 Theme<\/span>\u00a0<\/span><\/td>\nFree, OSL 3.0 + AFL 3.0 licence<\/span>\u00a0<\/span><\/td>\nDefault theme and theme module: category, product, cart and customer account pages, Alpine.js components<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Hyv\u00e4 UI<\/span>\u00a0<\/span><\/td>\n\u20ac250 per store<\/span>\u00a0<\/span><\/td>\nLibrary of ready-made UI components (menus, sliders, product cards)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Hyv\u00e4 Checkout<\/span>\u00a0<\/span><\/td>\nPaid, via Hyv\u00e4 Commerce<\/span>\u00a0<\/span><\/td>\nReplacement for the Luma checkout<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Hyv\u00e4 Enterprise<\/span>\u00a0<\/span><\/td>\nPaid, via Hyv\u00e4 Commerce<\/span>\u00a0<\/span><\/td>\nB2B features for Adobe Commerce such as company accounts and requisition lists<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The checkout is where most people get caught. With the free theme alone, the usual route is Hyv\u00e4’s Luma checkout fallback module. It works, but it brings back the heavy JavaScript on the page that matters most. Most stores either buy Hyv\u00e4 Checkout or budget for a custom one-page checkout.<\/span>\u00a0<\/span><\/p>\n

For B2B shops on Adobe Commerce, check which B2B features your customers actually use before you price Hyv\u00e4 Enterprise. Quick order, requisition lists and company accounts all need a Hyv\u00e4 version, and some stores only use one or two of them.<\/span>\u00a0<\/span><\/p>\n

<\/b>Where the migration effort really goes<\/span><\/b>\u00a0<\/span><\/h3>\n

Installing the theme takes an afternoon. On a prepared server:<\/span>\u00a0<\/span><\/p>\n

composer require hyva-themes\/magento2-default-theme<\/span>
\nbin\/magento setup:upgrade<\/span><\/p>\n

# Build the Tailwind CSS for your child theme<\/span>
\ncd app\/design\/frontend\/Vendor\/theme\/web\/tailwind<\/span>
\nnpm ci && npm run build<\/span>\u00a0<\/span><\/p>\n

Then you set the theme under Content \u2192 Design \u2192 Configuration. That’s not where the weeks go. The weeks go into three places.<\/span>\u00a0<\/span><\/p>\n

    \n
  1. Extensions that render something on the storefront. Backend-only extensions (admin grids, APIs, cron jobs, ERP connectors) keep working untouched. Anything that outputs HTML or JavaScript on the frontend needs a Hyv\u00e4 compatibility module. Many vendors, including Amasty, Mageplaza and Mirasvit, ship them, and Hyv\u00e4 keeps a public compatibility list. Start with an inventory:<\/li>\n<\/ol>\n

    # Every enabled third-party module<\/span>
    \nbin\/magento module:status –enabled | grep -v ‘^Magento_’<\/span>\u00a0<\/span><\/p>\n

    Then sort the list into three groups: backend-only, has a Hyv\u00e4 compat module, and needs custom work. The third group is your real estimate.<\/span>\u00a0<\/span><\/p>\n

      \n
    1. Custom templates and Knockout components. If your previous agency built custom product configurators, delivery-date pickers or B2B order forms as Knockout UI components, they have to be rewritten in Alpine. Usually the rewrite is shorter than the original. It still takes time.<\/li>\n
    2. Design. Hyv\u00e4 doesn’t copy your Luma look. Most teams use the migration to tidy the design anyway, which is sensible, but agree the scope before development starts. A pixel-perfect copy of an old theme is often more work than a clean new one.<\/li>\n<\/ol>\n

      One thing that doesn’t change: the ERP integration. If your shop is connected to SAP Business One, products, prices, stock and orders keep flowing through the same backend. Just include a full order round-trip in your test plan before go-live.<\/span>\u00a0<\/span><\/p>\n

      <\/b>Budget, timing, and when to wait<\/span><\/b>\u00a0<\/span><\/h3>\n

      Industry estimates for a mid-sized store put a Luma-to-Hyv\u00e4 migration at 4 to 8 weeks of development, roughly $15,000 to $70,000, and $25,000 to $85,000 in the first year once extension compat modules and design work are added (figures quoted by MGT Commerce). That’s a wide range, and the extension inventory from the previous section is what narrows it. Get at least two quotes, and make sure both are based on the same inventory.<\/p>\n

      Timing for 2026. Don’t launch a new frontend between Black Friday and New Year. If you’re in a code freeze from 20 November (see our peak season checklist), use December for the discovery work instead: the extension audit, the design scope and the checkout decision. Start development in January and go live in February or March, well before spring campaigns.<\/p>\n

      Combine it with an upgrade, carefully. If you’re also moving to Magento 2.4.9 (supported until May 2029), doing both in one project saves a round of testing. It also means two big changes at once. Plan it as two milestones: upgrade the backend first, then switch the frontend.<\/p>\n

      <\/b>When to hold off:<\/span><\/b>\u00a0<\/span><\/h3>\n