Hyvä has become the default frontend trajectory for serious Adobe Commerce retailers, and that has produced a predictable pattern: every Magento-aware retailer is told they need to migrate, every Adobe Commerce agency is selling the migration, and the actual question of when the move is right for a specific business is getting lost in the noise. The honest answer is that Hyvä migration makes sense for most mid-market Adobe Commerce retailers, but not for all of them, and not at every moment in their roadmap.
This article is a framework for deciding whether the migration is right for your business right now, or whether the right answer is to wait six to twelve months. It is the framework Bemeir’s Hyvä migration practice actually uses when retailers ask us to help them think through the decision, and it includes the cases where we have advised against migrating, which is most of what makes the framework honest.
What Hyvä is actually solving
Before deciding when to migrate, it helps to be clear about what Hyvä is and what problem it solves. Hyvä is a frontend theme for Magento and Adobe Commerce that replaces the default Luma theme. It is built on Tailwind CSS and Alpine.js rather than on KnockoutJS and the Magento UI Component framework, and the result is dramatically lighter — typically 1-2 MB of JavaScript instead of 5-8 MB, and Largest Contentful Paint times that drop from 4-6 seconds to under 2 seconds for properly tuned implementations.
The performance improvement is not marginal. According to Hyvä’s published benchmarks and corroborated by independent retailer case studies, Hyvä migrations consistently deliver 3-5x improvement in Lighthouse mobile scores and 30-60% improvement in real-user LCP. The conversion impact varies more, but the median lift is meaningful: typically 4-12% on mobile conversion rate, sometimes higher for retailers whose pre-migration mobile experience was particularly slow.
The cost is real. A full Hyvä migration for a mid-market Adobe Commerce storefront typically runs $80,000 to $250,000 in engineering effort, depending on the customization depth of the current Luma implementation, the number of third-party modules involved, and the complexity of B2B or multi-store features. The timeline is typically twelve to twenty weeks of calendar time, with overlap between design, development, third-party module compatibility work, and QA.
When the migration makes sense now
Hyvä migration makes immediate sense in three specific scenarios.
Scenario 1: Performance is leaking measurable revenue. If your current Adobe Commerce storefront has LCP above 3 seconds on mobile, INP above 200 ms, or mobile bounce rate above 60%, you have a performance problem that is costing you conversion right now. The Hyvä migration math is straightforward in this case: the migration cost is bounded, the performance lift is predictable, and the conversion improvement typically pays back the engineering cost within six to nine months on a mid-market retailer.
Scenario 2: You are already planning a frontend refresh. Frontend refreshes are expensive even on Luma. If your team is about to commission a new design system, redo the navigation, refactor the cart flow, or rebuild the product detail page, that engineering work should be done on Hyvä rather than on Luma. The incremental cost of doing the refresh on Hyvä is materially smaller than doing it on Luma and then migrating to Hyvä later. Bemeir’s Hyvä practice sees roughly half of all migration engagements arrive at the door with an in-flight frontend refresh that should be redirected to Hyvä.
Scenario 3: You are stuck on a Luma codebase that nobody wants to maintain. If your current Luma frontend has accumulated enough customization that even small changes take days, and your engineering team or agency is starting to refuse certain kinds of work because the cost is disproportionate, the Hyvä migration is also a debt cleanup. The migration is an opportunity to throw away accumulated frontend complexity and build cleanly on a smaller, more modern foundation.
| Scenario | Migration urgency | Typical ROI horizon |
|---|---|---|
| LCP > 3s mobile, measurable conversion drag | High — schedule within 6 months | 6-9 months payback |
| In-flight frontend refresh in planning | High — redirect the in-flight work | Embedded in refresh ROI |
| Heavy customization accumulated, maintenance cost rising | Medium — schedule within 12 months | 12-18 months payback |
| Adobe Commerce major version upgrade approaching | Medium — bundle with upgrade | Shared engineering cost |
| New product launch or business expansion | Variable — depends on launch timing | Variable |
When to wait
Three scenarios suggest waiting six to twelve months rather than migrating now.
Scenario A: You are mid-platform-decision. If your business is genuinely considering a platform change — Shopify Plus, BigCommerce, headless commerce — the Hyvä migration cost will be partially or fully stranded if you switch platforms in the next eighteen months. The right move is to make the platform decision first, and if the answer is “stay on Adobe Commerce,” then the Hyvä migration follows. Bemeir’s Adobe Commerce team often runs platform decision engagements that conclude with a Hyvä migration recommendation, but the sequencing matters: decide first, then build.
Scenario B: Your custom module situation is a mess. Hyvä is compatible with the majority of Magento extensions, but compatibility is not automatic. If your store relies on more than fifteen third-party modules, especially ones from smaller vendors or modules with extensive frontend customization, the compatibility work can dominate the migration budget. The right move in this case is to spend two to four weeks on a compatibility audit first, and only commit to the migration once the scope is real. Hyvä’s compatibility tracker is a useful starting point but is not the complete answer — many extensions have partial compatibility that requires custom adapter work.
Scenario C: You have a major business event in the next six months. Migrating frontend during a peak sales event, a major product launch, or an investor due diligence period is a way to take a manageable engineering risk and turn it into a business risk. The right move is to wait until the calendar clears.
The phased migration question
Some retailers ask whether a phased Hyvä migration — keep some pages on Luma, move others to Hyvä — is a way to manage risk. The honest answer from Bemeir’s Hyvä migration team is that phased migrations almost always become the worst of both worlds. The retailer ends up maintaining two frontend stacks, the performance benefits of Hyvä are diluted by the Luma pages users still encounter, and the cost is higher because the integration work between the two stacks adds engineering effort that a single-shot migration would not have.
The exception is genuinely separable sub-experiences: a B2B portal that is essentially its own product can sit on Hyvä while the consumer storefront stays on Luma temporarily. But for a single integrated storefront, the right path is a clean migration with a defined cutover, not a phased rollout.
What the migration timeline actually looks like
A typical mid-market Hyvä migration follows a predictable shape. Weeks 1-3 are discovery and design adaptation: understanding the current Luma customization, deciding what to carry forward and what to redesign, and adapting the brand design system to Hyvä’s Tailwind-based architecture. Weeks 3-12 are core development: rebuilding the storefront on Hyvä, integrating third-party modules, building the custom components the brand needs. Weeks 12-16 are QA, performance tuning, and stakeholder review. Weeks 16-20 are launch preparation and cutover.
The Adobe Commerce official documentation references this kind of timeline as standard for non-trivial Hyvä projects. The Hyvä developer documentation details the migration approach and the compatibility patterns for common extension types.
What waiting actually costs
If the right answer for your business is to wait, it is worth being honest about what the wait costs. Every month a mid-market Adobe Commerce storefront stays on Luma is a month of suboptimal mobile conversion, suboptimal Core Web Vitals signals to Google, and suboptimal user experience relative to the brand’s positioning. The cost is not catastrophic, but it is real, and it compounds. According to SOASTA’s research on eCommerce performance, every 100ms improvement in LCP correlates with roughly 1% improvement in conversion rate for mid-market retailers. The Hyvä migration typically delivers 2,000-3,000ms of LCP improvement, which is the conversion equivalent of running the storefront at one-fifth the performance level for as long as the migration is deferred.
That math is what makes the “when to migrate” decision a real decision. For most mid-market Adobe Commerce retailers, the right answer is “this year, with deliberate scheduling around the business calendar.” For a smaller subset, the right answer is “wait six to twelve months because the prerequisites are not in place yet.” The wrong answer, for almost everyone, is “we will get to it eventually.” That is the answer that produces an indefinite delay and the slow erosion of mobile conversion that follows.