Luma to Hyvä migration: what actually breaks, and how long each fix takes

What Hyvä changes, and what it leaves alone

Luma’s frontend is built on RequireJS, KnockoutJS, jQuery, LESS and Magento’s UI components. Hyvä removes all of that and uses Tailwind CSS and Alpine.js instead. On the server side nothing changes: the same PHP blocks, layout XML, view models, controllers and the same Magento install. Since 10 November 2025 the Hyvä theme itself is free and open source (OSL 3.0 and AFL 3.0), together with its compatibility modules. Hyvä Checkout, Hyvä UI and Hyvä Enterprise remain commercial products.

The consequence for your store: anything that adds behaviour to the storefront through requirejs-config.js, data-mage-init, x-magento-init, Knockout templates or jQuery widgets does nothing on Hyvä. The PHP part of an extension usually works; its storefront part does not.

What does not break: products and prices, customers, orders, the admin, cron, indexers, REST and GraphQL APIs, and integrations with your ERP, PIM or marketplaces. That boundary is why a Hyvä migration can be scoped and quoted as a fixed price, unlike a replatform.

What breaks, roughly in order of cost

The times below are the ranges I plan with. They assume a developer who knows both Luma and Hyvä well. Your audit replaces them with numbers for your store.

1. Third-party extensions with a storefront part

This is the biggest variable in every Hyvä quote. Each extension falls into one of three groups:

• A compatibility module exists. Many vendors now ship Hyvä support themselves, and the Hyvä community maintains compatibility modules for many popular extensions. Installing and testing one: one to three hours.
• No module yet, so I write it. A small widget, such as a banner slider, a product label or a store locator form: half a day to a day. Something with real logic in the browser, such as layered navigation, a product configurator or a gift-card flow: three to ten days.
• Not worth carrying over. Old extensions that duplicate what Hyvä or Magento already do, or that nobody uses. Removing them is the cheapest fix and often a performance gain on its own.

The audit puts every extension into one of these groups before you commit, because this is where projects without an audit go over budget.

2. Checkout

Checkout is the second big decision, and there are two good options:

• Keep your current checkout through Hyvä’s Luma checkout fallback. Checkout keeps running on the Luma stack, including most third-party one-step checkouts, while the rest of the store runs on Hyvä. Styling it to match and testing every payment and shipping method: one to three days. It is the quickest route to go live, and nothing stops you from replacing checkout later.
• Move to Hyvä Checkout, a paid licence from Hyvä. It is faster and much easier to customise. A standard setup with your payment and shipping methods: about one week. Custom steps, B2B fields, delivery date pickers or unusual payment flows: two to three weeks. Check early that each of your payment providers has a Hyvä Checkout integration; that question decides more timelines than any other.

3. The theme itself

Luma themes are LESS files and template overrides full of x-magento-init blocks. None of that carries over, so the design is rebuilt in Tailwind, either as a faithful copy of the current one or from your designer’s new files. Rough ranges per page type:

• Header, footer, navigation and minicart: two to four days.
• Category pages with filters and sorting: two to four days.
• Product pages: two to five days, depending on configurable swatches, bundles, galleries and custom options.
• Cart, customer account and the remaining CMS layouts: two to four days together.

Several store views with different designs multiply part of this work; several store views sharing one design mostly do not.

4. Your own custom modules with frontend JavaScript

Custom modules written for Luma usually carry jQuery widgets or UI components: a delivery date picker, a size guide, a B2B quick order form. Each is rewritten as a small Alpine.js component. A simple widget: two to six hours. A larger UI component with server calls and state: two to five days. This code is usually shorter and easier to maintain afterwards, which is part of why later frontend changes cost less on Hyvä.

5. Page Builder and CMS content

Page Builder content renders on Hyvä, but anything with its own JavaScript needs checking: sliders, tabs, carousels and product lists placed in content. The usual surprise is inline jQuery that someone pasted into a CMS block years ago. It worked on Luma because jQuery was always there; on Hyvä it silently stops. Reviewing and fixing content: half a day to three days, depending on how much content you have and how creative the marketing team has been.

6. Tracking, tag manager and consent

Data layer events from extensions often hook into Luma’s JavaScript: add to cart, checkout steps, product impressions. On Hyvä they have to be wired to Hyvä’s own events. The same goes for consent banners, reCAPTCHA and similar form protections, chat widgets and review widgets. Getting analytics to report the same numbers before and after: one to three days. Do not skip it, or you lose the very data that should prove the migration worked.

7. Customer data, minicart and private content

Luma loads customer-specific data, such as the cart, the name in the header and wish lists, through its customer data sections and Knockout. Hyvä loads the same sections in its own way. Extensions that add their own sections or read them in the browser need adapting: a few hours per section.

8. The things that look fine but are not

• SEO details: structured data that came from Luma templates or extensions, hreflang, canonical tags and breadcrumbs. They have to match exactly, or the migration costs rankings.
• Translations: Luma’s JavaScript translations are not used on Hyvä, so strings in rewritten components need translating again for every store view.
• Accessibility: menus, modals and forms behave differently once rewritten. Keyboard and screen reader checks belong in QA.

Verifying all of this on staging: one to three days.

The summary I give clients

For a store with standard page types and well-supported extensions, this adds up to the lower end of the 6 to 12 weeks I quote from kick-off to go-live. Custom B2B flows, many store views or an unusual checkout push it towards the upper end.

How I keep it predictable

• Audit first. Every extension, custom module, template override and checkout customisation is listed and sorted before the quote. Surprises are expensive mid-project and cheap in an audit.
• Staging from week two. You click through real pages with your real products early, so design questions are settled while they are still cheap to change.
• Go live in stages if it helps. With the Luma checkout fallback, the new storefront can go live before Hyvä Checkout is finished.
• Measure before and after. Lighthouse and Core Web Vitals on the same pages and devices, so the gain is a number, not a feeling.