
Free and open source since 10 November 2025
Hyvä for Magento 2
Hyvä theme development and Luma to Hyvä migration for Magento 2: a storefront that passes Core Web Vitals on real devices, every extension ported or replaced, and your rankings kept. Hyvä has been free and open source since November 2025, so the only cost left is the build.
Get a Free Hyvä Migration EstimateWhy Hyvä
10 Nov 2025 Hyvä became free and open source3 metrics LCP, INP and CLS, measured on real devices
Luma, the frontend Magento 2 has shipped since 2015, was built on jQuery, RequireJS and Knockout, and it loads whole JavaScript bundles whether a page needs them or not. On a mid-range phone that shows up exactly where Google measures: a slow Largest Contentful Paint, an Interaction to Next Paint that fails the threshold Google has applied since March 2024, and layout shift from scripts arriving late. Hyvä replaces that stack with Tailwind CSS and Alpine.js, ships only the code a page uses, and leaves Magento's backend, admin and extensions' server side exactly as they are. The result is a storefront that passes Core Web Vitals on real devices rather than in a lab report, with a codebase a frontend developer can change in hours instead of days. On 10 November 2025 Hyvä Themes relicensed the theme as free and open source under the same OSL 3.0 and AFL 3.0 licences Magento Open Source uses, so the licence fee that used to sit in every estimate is gone. Hyvä Checkout and the commercial add-ons remain paid, which is one of the decisions the audit makes before the build starts.
What Luma costs you
If your store is on Luma, most of these are already in your analytics. They are the reasons a Hyvä migration pays for itself in conversion, not just in a speed score.

The largest element paints late and taps answer slowly, because the page is still parsing JavaScript it will never run. Google reports it; shoppers feel it.

RequireJS loads its bundles before the page can draw. Every category, product and checkout page pays the same tax, and no amount of caching removes it.

Each module brought its own JavaScript and CSS, years ago, and the vendors have moved on. The theme carries all of it, and nobody dares to remove a line.

A banner, a filter, a checkout field: on Luma each one means Knockout templates, LESS compilation and a deploy. Marketing waits, or gives up asking.

The checkout is the heaviest page on a Luma store and the one where a stalled tap costs the most. The shoppers who leave there never show up as a speed complaint.

Paid traffic lands on the slowest pages the store has. Every second of load on a landing page is budget that bought a bounce instead of a session.
Audit, build, verify, launch
Scope, honestly
2 libraries Tailwind CSS and Alpine.js, in place of jQuery, RequireJS and Knockout1 checkout decision made in the audit, not discovered at launch
A Luma to Hyvä migration is a frontend rebuild. Everything your customers see is written again on Tailwind CSS and Alpine.js: the layout, the category and product pages, search and filters, the cart, the customer account, the CMS blocks and the emails that share the theme. Everything they do not see stays: the Magento version, the catalog, the orders, the integrations, the admin and the server side of every extension. That split is what makes the work predictable. The extension inventory decides most of the estimate, because each module's frontend has to be ported through Hyvä's compatibility module, rewritten, or replaced, and the audit writes that decision down module by module before you commit. The checkout is the one decision that changes the shape of the project: keep the Luma checkout behind a Hyvä storefront for the first release, adopt Hyvä Checkout, which remains a paid product, or build a custom checkout; each is a legitimate choice and the audit says which fits your store. What a migration does not include is a Magento upgrade, though stores on an old 2.4.x line often take both in one rehearsed run, and it does not touch your rankings: URLs, structured data, canonical tags and the tracking stack are carried over and checked against the baseline before cutover.
Pick the scope
Your current Magento store, your design, a new frontend. The audit inventories the extensions and makes the checkout decision, the theme is built beside the live store, and the cutover is a theme switch with a rollback.
A new Magento 2 store built on Hyvä from the first commit: no Luma to migrate from, a design system in Tailwind tokens, and extensions chosen for their Hyvä support rather than ported afterwards.
For stores on an old 2.4.x line where the Luma theme is what blocks the upgrade: the release upgrade and the Hyvä frontend rehearsed together on staging and launched in one window, so there is one project and one go-live rather than two.
Not our word for it

Adobe Certified Expert
7 professionals
Adobe Certified Expert
4 masters
Adobe Certified Expert
9 experts
Adobe Certified Expert
14 experts
Adobe Certified Expert
14 experts
Google Analytics Certification
6 expertsTrusted by 100+ companies
Keep reading



FAQ
Tell us about your store and we will come back with straight answers.
Talk to usIndividually, after the extension audit, because the number of modules whose frontend has to be ported, rewritten or replaced decides most of the work. The audit produces a fixed scope and a fixed price before the build starts. There is no price list on this site because no two Luma stores carry the same extension stack.
Most stores go from audit to cutover in eight to twelve weeks. A store with few extensions and a simple design sits at the short end; a store with a large module stack, a custom checkout and B2B features at the long end. The audit gives you the dates for your store rather than the average.
Each one is handled on its own terms. Many popular modules have an official or community Hyvä compatibility module and port cleanly. Some need their frontend rewritten for Alpine.js, and a few are better replaced by a module built for Hyvä. The audit lists every extension with its route, so there are no surprises in the build.
Not necessarily. Hyvä Checkout is a paid product and a good one, but a Hyvä storefront can run with the standard Luma checkout behind it for a first release, and some stores keep a custom checkout. The audit weighs your payment and shipping extensions, your B2B needs and your budget, and recommends one of the three.
A theme switch does not change URLs, and we make sure it does not change anything else Google reads: canonical tags, structured data, meta data, internal links and the tracking stack are carried over and checked against the baseline before cutover. Faster pages tend to help rankings, not hurt them, and the ranking watch after launch confirms it.
Yes, and often both should happen in one run. Hyvä supports the current 2.4 lines, so a store on an old version usually takes the release upgrade and the new frontend together, rehearsed on one staging copy and launched in one window.
Yes. Since 10 November 2025 the Hyvä theme has been licensed under OSL 3.0 and AFL 3.0, the same licences Magento Open Source uses, and is available through Composer without a licence fee. Hyvä Checkout and the commercial add-ons remain paid products.
Yes. The Sales Agent integrates natively with Magento 2 and ships a widget for Hyvä as well as Luma, so a store that moves to Hyvä keeps its AI assistant, its catalog sync and its order tracking without any extra work.
Hyvä is the right answer for most Magento stores: it keeps Magento's own rendering, so every backend feature and most extensions keep working, and it reaches the Core Web Vitals targets without a separate frontend application to host and maintain. PWA Studio and custom headless builds make sense when a store needs an app-like experience across several channels and has the team to run it. We build both and will tell you which fits.
Yes. The theme is built from your design tokens, colours, type and spacing, and the pages are rebuilt to your existing layouts unless you want to change them. Many stores use the migration to fix what the Luma theme made hard, but that is a choice, not a requirement.
Yes. Company accounts, shared catalogs, requisition lists, quotes and customer-specific pricing from Adobe Commerce B2B or from third-party modules all run on a Hyvä storefront, with their frontends ported like any other extension. The audit lists them with the rest.
Your team can, because the handover includes the theme's documentation and the build tooling, and Tailwind and Alpine are far easier to change than Knockout and RequireJS. Many stores keep us on ongoing support for upgrades, patches and new features, but nothing in the theme depends on that.
Let’s build something great together!
Send us the store URL and your extension list. We return the migration estimate, the checkout decision and the dates, before anything is built.