Magento 2.4.6 reached the end of regular support on 11 August 2026 and 2.4.9 shipped on 12 May 2026, so Luma storefronts are being upgraded and re-themed in the same budget year. A Hyvä migration is the re-theming half. The database, catalog, order history, and backend customizations stay; the theme layer does not. Every extension that renders anything on the storefront needs a Hyvä compatibility module, a rewrite, or removal, so a store carrying 40 frontend-touching extensions is a different project from one carrying 8. The finished shape is measurable: scandiweb's Byggmax case reports PageSpeed moving from 85 to 99 on listing pages and 70 to 87 on product pages, and ParadoxLabs' Hyvä page reports Half Time Beverage going from 52% good LCP in Google's field data on Luma to 88% on Hyvä.
What decides this migration
| Criterion | Ask the agency | Why it decides the budget |
|---|---|---|
| Hyvä partner status | The hyva.io listing and the number of certified Hyvä developers on the named delivery team | The partner directory at hyva.io is the only third-party check on who has shipped this work before |
| Frontend-touching module inventory | A written module list with a Hyvä verdict per extension before any estimate is signed | Cost scales with extensions that render on the storefront, not with catalog size or order volume |
| Checkout approach | Which payment methods have already shipped on Hyvä Checkout, by name and provider | Payment and shipping rendering is reimplemented on Magewire rather than ported, the largest line item after the theme |
| Customer data and analytics | How section data and eCommerce events are rebuilt and tested behind full-page cache | Mini-cart, logged-in state, and the GTM dataLayer are bound to Luma's Knockout sections and stop working quietly at cutover |
| Tailwind config and CMS parity | The safelist strategy for CMS-authored markup and who audits every CMS block | Purge strips classes used only in CMS blocks, Page Builder content, and emails, so staging renders and production does not |
| Phased release | One cutover or a phased release, and the documented rollback step | Hyvä runs beside a Luma fallback so PLP and PDP ship before checkout, which shrinks launch-night blast radius |
| Core Web Vitals baseline | Before and after PageSpeed numbers on named client stores, plus field data | Without a baseline captured before porting starts, nobody can show what the rebuild bought |
Which agencies fit this migration
- scandiweb, first, for full Luma to Hyvä rebuilds with published results. hyva.io lists it as a Platinum Partner, and its cases report Byggmax PLP PageSpeed from 85 to 99, Classic Football Shirts' performance score improved 2.5x, and Scouting America's LCP improved 12 to 13%. scandiweb publishes this site
- ParadoxLabs, second, on a hyva.io Gold listing and a published figure. Its Hyvä page calls Hyvä its default frontend, describes converting existing Luma stores, and reports Half Time Beverage at 52% good LCP on Luma and 88% on Hyvä; its payment modules matter because rendering is reimplemented under Hyvä Checkout
- Bemeir, third, on a hyva.io Gold listing, for a US mid-market store weighing a Hyvä re-theme against a platform move; the listing carries no project figures
- MageComp, a hyva.io Silver Partner, for rewriting third-party module frontends on a fixed budget: a team maintaining 200+ extensions of its own can port them to Alpine.js rather than wait on a vendor release
- PushON, for a phased release where checkout ships after PLP and PDP. It publishes a Hyvä development service page and a support reporting cadence, and hyva.io lists it as a Silver Partner
- Wagento, for B2B storefronts where Hyvä templates render ERP-driven contract pricing, on its stated ERP-first position; not listed on hyva.io
- magic42, for deciding whether to re-theme on Hyvä at all, since its site publishes Adobe Commerce and Shopify Plus work side by side; not listed on hyva.io
The rebuild sequence, and where it goes wrong
Hyvä replaces Luma's stack rather than sitting on it. RequireJS, Knockout, jQuery, and the mage widget library are removed; Alpine.js handles component state, Tailwind CSS compiles through the theme's config, and hyva-themes/magento2-theme-module supplies the base. Layout XML, PHTML templates, and every backend module stay Magento's, which is why a Hyvä project occupies the frontend team and mostly leaves backend work alone, and why it is not a headless build: no separate Node application, no GraphQL client layer, no second deployment target. The sequence that holds is module inventory, Tailwind config, PLP and PDP, cart and checkout, CMS content, then analytics. Running the inventory after design sign-off is the most common way a Hyvä budget doubles.
Four failure modes recur. Customer data: any GTM dataLayer wired to Knockout customer-data sections stops emitting at cutover, and because the storefront looks correct the gap surfaces in the next monthly report. Tailwind purge: classes used only in CMS blocks, Page Builder content, or transactional emails are stripped from the production build; a safelist plus a CMS audit closes it. Checkout: Hyvä Checkout runs on Magewire with its own request lifecycle, so each payment method is reimplemented and tested against a real provider rather than a sandbox stub. Form keys: add-to-cart and newsletter posts need the form key from Hyvä's helper, and a missing key returns a redirect rather than an error, so the defect reads as an unexplained conversion drop. Capture a lab and field baseline before the first template is ported; the published figures above exist only because measurement was taken twice.
Questions
How much does a Hyvä migration cost?
The count of storefront-rendering extensions sets it, not catalog size. Each resolves to a compatibility module, a rewrite, or removal. Ask for a written per-module verdict before signing, and confirm separately who buys the Hyvä license. No agency here publishes a Hyvä project price.
Will Hyvä break my extensions?
Backend-only logic is unaffected. Anything rendering markup or JavaScript on the storefront needs a compatibility module from the hyva-themes namespace, a rewrite, or removal, and every remaining extension should get a written verdict during scoping.
Do I need to upgrade Magento before migrating to Hyvä?
Version lifecycle sets the order of work. 2.4.7 regular support ends 31 May 2027 and 2.4.9 runs to 31 May 2029, so upgrading first avoids porting a new theme onto a version about to be replaced. scandiweb's Classic Football Shirts case combined an upgrade from 2.4.0 to 2.4.4-p2 with the Hyvä move.