Hyvä migrations get talked about in two unhelpful registers. The marketing register says everything is faster, conversion is up, and merchants are universally delighted. The skeptical register says the migration is expensive, the gains are marginal, and the work could have been done other ways. Neither is the version most merchants actually experience. The honest version is that Hyvä is a real performance win for stores in the right shape and a costly disappointment for stores that approach it without doing the prep work.
This piece looks at what actually happened across six mid-market Adobe Commerce stores Bemeir migrated to Hyvä over the last 24 months, measured at the 18-month post-launch mark. The details are anonymized but the patterns are the patterns. The goal is to give merchants considering Hyvä a more grounded picture than either the marketing or the skepticism provides.
Why 18 months matters
Most Hyvä case studies report results at 30 or 60 days post-launch. The numbers look great because the migration came with a comprehensive performance overhaul: new image pipeline, new caching configuration, fresh third-party widget audit, new hosting tuning. Some of those wins would have come from any focused performance project, with or without Hyvä.
The 18-month mark is more useful because the immediate post-launch boost has stabilized, normal operational pressure has resumed, and the differences that remain are the structural ones the migration actually produced. Whatever performance the store is posting at 18 months is what Hyvä is worth in the long run.
The six stores
Each store is described by its rough profile, not its name. The profile categories are what determined the outcome more than the brand:
Store A. $35M annual revenue, DTC apparel, 12,000 SKUs, prior Luma theme with custom design. Migration in 14 weeks. Performance ceiling was the goal; the founder wanted Adobe Commerce + Hyvä to outrun Shopify Plus.
Store B. $80M annual revenue, B2B distributor, 45,000 SKUs, complex customer-group pricing. Migration in 22 weeks (longer due to B2B catalog visibility requirements). Goal was mobile performance and ERP integration depth that Shopify Plus B2B could not deliver.
Store C. $18M annual revenue, DTC supplements, 800 SKUs, heavily reliant on subscription functionality. Migration in 16 weeks. Goal was conversion lift and a future-proof frontend.
Store D. $50M annual revenue, multi-brand retailer (4 brands on one Adobe Commerce installation), 25,000 SKUs total. Migration in 28 weeks (multi-store complexity). Goal was unified performance across the brand portfolio.
Store E. $25M annual revenue, automotive parts, 80,000 SKUs, fitment-driven catalog. Migration in 18 weeks. Goal was mobile speed and admin productivity.
Store F. $60M annual revenue, B2B industrial, 35,000 SKUs, punchout integrations. Migration in 24 weeks. Goal was reducing the Magento performance gap that was costing them deals against Shopify Plus B2B.
What changed at 18 months
The numbers are real, with the caveats noted:
| Store | Mobile LCP before | Mobile LCP at 18 months | Mobile conversion lift | Notes |
|---|---|---|---|---|
| Store A | 3.8s | 1.5s | +14% | Held the gains; further optimization pushed to 1.3s |
| Store B | 4.2s | 1.7s | +9% | B2B login flow added some weight; pure Hyvä would be faster |
| Store C | 3.6s | 1.4s | +18% | Highest lift; small catalog, simple flow, big mobile audience |
| Store D | 4.1s | 1.8s | +11% | Multi-store overhead added back some weight |
| Store E | 4.5s | 1.6s | +12% | Fitment widget rebuild was the long pole |
| Store F | 3.9s | 1.7s | +8% | B2B catalog and punchout reduced mobile gain |
The averages: LCP went from 4.0s baseline to 1.6s at 18 months. Mobile conversion lifted 12% on average. The variation across stores tells the more useful story than the average.
What predicted strong outcomes
Three factors most reliably predicted the larger conversion lifts:
Simple flow with mobile-heavy traffic. Store C had the highest lift because its checkout was three steps, its mobile traffic was 78% of total, and the catalog complexity was low. Hyvä’s performance advantage compounds when the user journey is simple and mobile-dominant.
Disciplined pre-migration extension audit. Stores A, C, and E did extension compatibility audits before the migration. They knew which extensions needed rebuilding and budgeted for it. Stores B, D, and F discovered some extension issues during migration; those discoveries added 4-8 weeks each.
Hosting and database tuned at the same time. Stores that paired the Hyvä migration with a database upgrade and hosting tier upgrade saw bigger TTFB improvements. Hyvä helps mostly with the frontend; if the server is taking 800ms to first byte, Hyvä cannot fix that.
What predicted weaker outcomes
The factors that produced smaller-than-expected lifts:
Heavy B2B logic. Stores B and F retained complex B2B-specific frontend behavior (customer-group catalog visibility, account-specific pricing display, punchout integration). Some of that logic could not be ported as cleanly as a pure DTC frontend, leaving incremental JavaScript that softened the performance gain.
Multi-store overhead. Store D’s four-brand setup added load to every request because the storefront had to determine which brand context to render. Pure single-brand stores do not pay this cost.
Late-discovered extension dependencies. Two of the stores had at least one extension whose Hyvä-incompatibility was discovered during migration. The remediation work (build Hyvä-compatible version or find replacement) added weeks and softened the launch numbers.
Less-than-optimal hosting. One store stayed on a hosting tier that was already underpowered for its traffic. The Hyvä win was real but limited by the underlying server.
Operational impact at 18 months
Beyond raw performance, the operational story at 18 months:
Frontend development cadence. All six stores reported faster frontend development on Hyvä. The Alpine.js + Tailwind approach is more accessible to mid-level developers than KnockoutJS + LESS. Feature work that took two weeks on Luma routinely takes one week on Hyvä.
Bug rates. Frontend bug counts dropped on five of six stores. The exception was Store D, where the multi-brand complexity introduced bugs of its own. The reduction comes from simpler abstractions and a smaller surface area to break.
Admin productivity. Adobe Commerce admin work was unchanged because Hyvä is frontend-only. The merchants who expected admin improvements were disappointed; Hyvä was never about that.
Extension maintenance. The maintenance burden on extensions is slightly higher because Hyvä-compatible versions and adapters need to stay in sync. The burden is manageable but real; an extra few hours per quarter per extension.
What the merchants would do differently
Asked in retrospect, the six merchants converged on a short list of changes:
Do the extension audit before signing the migration contract. All six wished they had spent two weeks on this before the agency conversation. The merchants who did some audit work upfront had less surprise. The merchants who did not had more.
Budget for a hosting upgrade in the same window. The merchants who paired the migration with hosting work got the bigger TTFB wins. The merchants who deferred hosting saved money in the short term and lost performance gains in the long term.
Plan the third-party widget reset. Every migration is a natural moment to revisit third-party scripts: do you still need all of them, are they still necessary, are they on Hyvä-compatible versions. Skipping this step left some stores with the same widget bloat as before.
Have a real performance baseline before migration. The merchants who captured baseline Core Web Vitals before the project could later prove the wins. The merchants who did not had a hard time attributing later wins to the migration vs. other factors.
Honest assessment
Hyvä migration is worth the investment for mid-market Adobe Commerce stores that have mobile-heavy traffic, a finite roadmap of frontend customization, and the budget to do the work properly. The conversion lift in the 8-18% range is real, the performance gains compound across the site, and the development velocity improvement is meaningful at 18-month horizons.
Hyvä migration is not the right move for stores that are about to replatform anyway, stores with extreme B2B complexity that loses most of the Hyvä advantage, or stores where the budget would be better spent on database upgrades or hosting work that would deliver more performance per dollar.
The honest summary Bemeir gives Adobe Commerce merchants considering Hyvä: it is the right call for most mid-market DTC stores, the right call for B2B stores willing to accept some compromise, and the wrong call for stores where the prerequisites are not in place. The cases above represent the population of stores that did go through with the work; the population of stores that wisely chose not to also exists, and they made the right call for their context. The Hyvä Themes documentation and ongoing community work make the platform a real option for the next several years; the question is whether it fits your store, not whether it is good in general.
