A Hyvä migration is one of the highest-leverage performance moves available to a Magento store today. Done well, mobile Lighthouse Performance jumps 30 to 60 points and frontend dev velocity roughly doubles. Done badly, it drags for months and ends with a store no faster than where it started, plus a new theme that nobody on the team understands.
This guide covers what Hyvä actually changes, when a migration is worth it, realistic timelines and budgets, the third-party module problem, cutover patterns, and how to monitor the first 30 days. Written from the playbook the eTechFlow team has run since 2021.
What Hyvä actually is
Hyvä is a frontend layer for Magento. It replaces the default Luma theme and the layered Knockout/RequireJS frontend stack with Tailwind CSS and Alpine.js. Server-rendered HTML, modern bundlers, sensible defaults.
It does not change:
- The Magento Open Source or Adobe Commerce backend.
- Your catalog, orders, customers, prices, or promotions.
- Payment integrations or the M2 admin.
- Any custom backend modules you have written.
That separation is the most important thing to understand. A Hyvä migration is a frontend swap. The data layer, the order processing, the integrations all stay where they are. What changes is the rendering layer that customers see.
When a migration is worth it
Move to Hyvä when at least two of the following are true:
- Mobile Lighthouse Performance sits below 60. Luma cannot reasonably get above 70-75 on mobile without aggressive cleanup of every third-party module. Hyvä starts at 80-90 out of the box.
- Frontend dev velocity has stalled. If shipping a simple template change takes a sprint instead of an afternoon, the Knockout layer is the cause. Tailwind plus Alpine cuts that to hours.
- Mobile conversion is below desktop by more than 30 percent. Most of this gap is page weight and interaction lag, both of which Hyvä materially fixes.
- You have at least one engineer who can run the migration. Hyvä is conventional Tailwind + Alpine + Magento. A senior frontend engineer learns it in a week. Without one in-house or on retainer, the project does not finish on time.
Stay on Luma if your team is committed to a headless React or Vue storefront via PWA Studio or a custom build. Hyvä is opinionated about server-rendered HTML, and fighting that opinion costs more than it saves.
The timeline reality
For a typical mid-market Magento store, plan for 3 to 5 weeks of wall-clock time, depending on third-party module complexity. Breakdown:
- Week 1: Audit and inventory. Every third-party module gets checked for Hyvä compatibility. Custom code paths documented. Branding tokens captured.
- Week 2: Default Hyvä storefront running. Cart, checkout, account flows confirmed working against the production database (staged copy).
- Week 3: Brand applied. Colors, typography, logo, header, footer, hero blocks.
- Week 4: Third-party reconciliation. Compatibility modules installed and configured. Custom Knockout components rewritten to Alpine or removed.
- Week 5: Cutover and monitoring. Staging dry run, off-hours production switch, 72 hours of close watch.
We published a separate post on what week one specifically looks like, including the day-by-day breakdown and the surprises that consistently cost teams time.
Cost ranges
Hyvä migration cost varies more than most agency price ranges because it depends on what is in the existing storefront. Honest ranges from our engagements since 2021:
- Small store (under 1,000 SKU, simple checkout): £8,000 to £15,000 fixed price. 2 to 3 weeks.
- Mid-market (1,000 to 50,000 SKU, B2C): £15,000 to £35,000. 3 to 5 weeks.
- B2B or multi-store: £35,000 to £80,000+. 5 to 10 weeks. Pricing tier accounts for catalog complexity, customer-group rules, and any multi-warehouse or multi-currency flows.
What drives the variation is third-party module count and the amount of custom Knockout in view/frontend/web/js. A store with 20 untouched third-party modules and minimal custom code is fast. A store with 35 modules and a year of custom frontend overrides is slow.
Subscription pricing is a red flag here. Hyvä migration is project work, not a retainer. If an agency is offering a monthly fee for "Hyvä work," ask for the fixed-price equivalent and compare.
Third-party module compatibility
The third-party module audit is the load-bearing decision in the whole migration. For every Composer dependency in your store, one of three things is true:
- The module has an official Hyvä compatibility module. Most major modules do. The Hyvä Themes team maintains a public list. You install the compat module alongside the original.
- The module has a community-built Hyvä variant. Less stable, but usually functional. Verify the maintainer is actively shipping before relying on it.
- The module has nothing. Then you choose: build a compatibility layer in-house, patch the module, or remove the module. We have had to do all three on different projects.
Plan the audit before you start writing Hyvä code. Removing two modules that have no compat path can change the migration scope more than a week of theming.
The performance impact
On a clean reference store running Hyvä 1.3 against Magento 2.4.7, we typically see:
- Mobile Lighthouse Performance: 85 to 95.
- Largest Contentful Paint: 1.0 to 1.8 seconds.
- Total Blocking Time: under 150 milliseconds.
- Cumulative Layout Shift: 0.0 to 0.05.
Real production stores land 5 to 15 points lower than the reference, because real stores have third-party modules, analytics scripts, chat widgets, and ad pixels. The discipline that matters is measuring after every addition.
Read why we run a Lighthouse 90 budget on every module we ship to understand the testing methodology.
The cutover
The actual switch from Luma to Hyvä happens in a maintenance window of 30 to 60 minutes. By the time you are at this step, the new theme has been smoke-tested against a copy of production for at least one week.
The minimum checklist for cutover night:
- Full database backup taken 5 minutes before the window starts, stored off-site.
- DNS and CDN cache primed for the new asset URLs.
- A rollback plan that takes under 10 minutes to execute. The theme switch is reversible via
app/etc/config.phpand a cache flush. - Order capture verified end-to-end before customers hit the new theme. Place a real test order during the window.
- One engineer on standby for 72 hours minimum. Most issues surface in the first day.
Post-launch monitoring
The 30-day window after a Hyvä migration is when issues surface and conversion patterns settle. What to watch:
- Daily mobile and desktop Lighthouse scores. Should be stable. A drop of more than 3 points triggers an investigation.
- Mobile cart abandonment rate. Hyvä migrations typically improve this by 5 to 12 points. If it gets worse, the checkout has a regression.
- Customer-service ticket volume. Plan for a 30 percent uptick in week one as customers report visual inconsistencies. Should return to baseline by week three.
- SEO traffic. URLs do not change in a Hyvä migration so rankings should not move. If they do, audit your
robots.txtand canonical tags before assuming algorithmic change.
FAQ
Do customer-facing URLs change?
No. Hyvä is a theme swap, not a routing change. All product, category, and content URLs stay identical. SEO equity transfers cleanly.
Can we run Hyvä on Adobe Commerce?
Yes. Hyvä works on Magento Open Source and Adobe Commerce equally. License compatibility is documented on the Hyvä Themes site.
What about Hyvä Checkout?
Hyvä Checkout is a separate product from Hyvä Themes. It replaces the default Magento checkout with a Hyvä-native Alpine checkout. Most migrations adopt it at the same time as the theme migration, but it can be added later.
How does this affect our analytics?
Most analytics scripts (GA4, Meta Pixel, Klaviyo) work unchanged. Some Knockout-based event helpers need Alpine equivalents. We usually rewrite the cart and checkout event handlers in the migration scope.
What happens to Page Builder content?
Page Builder content blocks render in Hyvä via the Hyvä-PageBuilder compatibility module. Some advanced widgets need template overrides. Plan for one to two days of Page Builder content adaptation per heavily-styled landing page.
What if we want to migrate but cannot afford the full project?
Look at a phased approach. Stage 1 ships the homepage and category templates on Hyvä, leaving product and checkout on Luma. Stage 2 migrates the rest. The performance gain is smaller but the cost is spread across two budgets. We have shipped this pattern multiple times when CFO timing constrained the engagement.
Next steps
If you are evaluating a Hyvä migration:
- Run a baseline mobile Lighthouse audit on your top-traffic product page. Record the score.
- Export your
composer.jsonand tag every third-party module against the Hyvä compatibility list. - Get a scoped quote from at least two agencies that have shipped Hyvä migrations of a similar size. Fixed-price preferred.
- Plan the cutover for a low-traffic window. UK retail: a Tuesday evening in February tends to be the calmest.
If you would like the eTechFlow team to scope the project, the Hyvä migration service page has the engagement details. The first 30-minute scoping call is free.