Luma to Hyvä migration is the most consequential frontend decision facing Adobe Commerce retailers in 2026. The performance gap between the two themes is substantial enough that competitive pressure is forcing the conversation even for retailers who would have preferred to stay on Luma. The conversation about whether to migrate has largely been settled; the conversation that matters now is how to migrate without producing a launch that costs more than the conversion lift recovers.
This article walks through the realistic timeline, the realistic cost, and the variables that drive both. The numbers are drawn from migrations we have shipped and migrations we have rescued from other agencies. The variance across projects is wide enough that any single estimate is unreliable; the variables that drive the variance are knowable, and a retailer who understands them can budget and plan with confidence.
The Variables That Drive Timeline and Cost
The biggest variable is the number of third-party Magento modules that need to be rewritten or replaced. A storefront running fifteen common modules with mature Hyvä support is a substantially different project than a storefront running forty modules where Hyvä compatibility has to be built or sourced from less mature alternatives. The module audit is the single most important upstream deliverable for a Hyvä migration plan.
The second biggest variable is the depth of checkout customization. A storefront using stock Magento checkout is a fast Hyvä migration. A storefront with custom checkout steps, custom payment flows, custom upsell logic, or custom B2B approval workflows requires rebuilding that customization in the Hyvä checkout architecture, which is a meaningfully different project. The checkout audit typically runs second in the upstream deliverables.
The third biggest variable is the design and brand work the retailer wants to do alongside the migration. Some retailers treat Hyvä migration as a pure performance project and preserve the existing visual design. Others use the migration as the occasion for a brand refresh. The two are very different scopes – the pure performance migration is a developer project, the redesign migration is a designer-led project with developer support. Both are legitimate, but the cost and timeline reflect the choice.
The fourth variable is the team’s familiarity with Hyvä. An agency that has shipped fifteen Hyvä migrations brings pattern recognition that an agency shipping their first or second migration does not. The pattern recognition shortens discovery, sharpens estimates, and reduces the risk of late-surfacing complexity.
Realistic Timeline by Complexity Tier
For a clean Luma storefront with twenty or fewer modules, mostly stock checkout, no major B2B complexity, and no design refresh in scope, a Hyvä migration typically runs ten to fourteen weeks end-to-end. Discovery takes two weeks. Module compatibility work and theme reimplementation take six to eight weeks. Integration validation and QA take two to three weeks. UAT and launch take one to two weeks. The compressed end of this range assumes a team that knows Hyvä and is not the retailer’s first Hyvä project.
For a moderately complex storefront with twenty to forty modules, partially customized checkout, some B2B feature usage, and no major design refresh in scope, a Hyvä migration typically runs sixteen to twenty-two weeks. The extra weeks go into module rewrite work that doesn’t have ready Hyvä equivalents, checkout customization rebuild, integration depth validation, and QA time appropriate to the additional complexity.
For a complex storefront with forty or more modules, deeply customized checkout, substantial B2B functionality, headless or partial-headless elements that interact with the theme, or a design refresh in scope, the migration typically runs twenty-four to thirty-six weeks. The variance within this tier is wide because each of these complexity factors compounds with the others. A storefront with all four typically falls at the upper end of this range and sometimes beyond.
Realistic Cost by Complexity Tier
The cost ranges below assume a US or US-equivalent agency with experienced Hyvä practitioners. Offshore-only teams can produce lower nominal cost but typically produce higher total cost when integration work, customization rebuild, and QA depth require senior practitioner judgment.
The clean Luma migration in the ten-to-fourteen-week range typically costs $80,000 to $160,000 fully loaded. The moderate complexity migration in the sixteen-to-twenty-two-week range typically costs $180,000 to $340,000. The complex migration in the twenty-four-to-thirty-six-week range typically costs $360,000 to $750,000 or more depending on the depth of design work, B2B customization rebuild, and integration scope.
The numbers do not include the cost of the design refresh if that is in scope. A Hyvä migration with a brand refresh typically adds $40,000 to $150,000 depending on the depth of the redesign work and how much design discovery is required.
| Complexity Tier | Module Count | Checkout Customization | B2B Scope | Timeline | Cost Range |
|---|---|---|---|---|---|
| Clean Luma | ≤20 | Mostly stock | None or minimal | 10–14 weeks | $80K–$160K |
| Moderate | 20–40 | Partial | Some B2B usage | 16–22 weeks | $180K–$340K |
| Complex | 40+ | Deep customization | Substantial B2B | 24–36 weeks | $360K–$750K+ |
| With design refresh | Any | Any | Any | +4–8 weeks | +$40K–$150K |
| With B2B feature rebuild | Any | Any | Heavy B2B | +4–8 weeks | +$60K–$180K |
| Headless interaction work | Any | Any | Any | +3–6 weeks | +$40K–$120K |
What the Variance Within Each Tier Looks Like
The cost ranges within each tier are wide because individual project decisions move the number substantially. The retailer choosing to preserve more custom modules rather than replacing them with Hyvä-native alternatives pays for the additional rewrite work. The retailer choosing to rebuild B2B approval workflows rather than simplifying them pays for the additional checkout customization. The retailer choosing to address accumulated technical debt during the migration pays for that work but exits the migration with a cleaner codebase.
The decisions that drive variance should be made deliberately rather than by default. The agency should be willing to walk through each module, each customization, and each integration with the retailer to decide whether to preserve, replace, or remove. The conversation is more involved than most retailers expect, but it produces a migration plan that fits the actual storefront rather than a generic template.
Bemeir’s Hyvä migration discovery process explicitly produces this module-by-module decision matrix before the migration estimate gets locked. The discovery typically takes two to three weeks and costs $12,000 to $24,000 depending on storefront complexity. The output is a documented decision matrix, a refined estimate with the assumptions visible, and a project plan that the retailer can defend internally.
The Performance Outcomes That Justify the Cost
The cost of Hyvä migration is substantial. The performance outcomes that justify the cost are also substantial, but only when measured properly and only when the migration is executed well. The typical outcomes from a well-executed Hyvä migration on a Luma baseline include LCP improvements of forty to seventy percent (typically moving from 4–6s to 1.5–2.5s on mobile), INP improvements of sixty to eighty percent (typically moving from 400–600ms to 100–200ms), and CLS reductions to near zero when the migration is paired with image dimension discipline.
The business outcomes that follow from these performance improvements are typically conversion rate improvements of five to fifteen percent and revenue per session improvements of similar magnitude. The variance is wide because conversion lift depends on the baseline (worse baselines see larger lifts), the product category (some categories are more performance-sensitive than others), and the funnel design (storefronts with longer funnels see larger lifts because compound friction reduction matters more).
The financial case for Hyvä migration works for most retailers with annual revenue above $5M and Luma performance below industry median. The payback period typically runs six to eighteen months depending on the conversion lift and the migration cost. Retailers with very high revenue can see payback in three months or less; retailers with smaller revenue or smaller lifts may see payback over the full eighteen months.
What Goes Wrong When Migration Is Underestimated
The most common failure mode for Hyvä migrations is underestimating the module compatibility work. The discovery says “thirty-five modules, most have Hyvä versions available.” The implementation discovers that some of those Hyvä versions are immature, that some require configuration work that wasn’t accounted for, and that some modules used in production are not on the discovery list because they were undocumented customizations. The cumulative effect is timeline slip and budget overrun.
The fix is rigorous module discovery that goes beyond the composer.json. The discovery should include a runtime inventory of what is actually loaded on production pages, a customization catalog of what has been modified beyond stock module behavior, and a documented assessment of Hyvä compatibility for each item including the maturity of available alternatives.
The second common failure mode is underestimating checkout customization rebuild. The discovery captures the checkout customizations at a feature level but misses the operational dependencies – the third-party integrations that the customizations relied on, the analytics events that the customizations emit, the experimentation framework that the customizations participate in. The implementation has to rebuild not just the customization itself but its full operational context.
The third failure mode is underestimating QA depth for Hyvä-specific behavior. The theme renders differently than Luma, the JavaScript model is different, the browser compatibility profile is different, and the performance characteristics are different. The QA scope has to account for the architectural difference, not just functional parity testing.
Choosing the Right Migration Partner
The depth required to ship Hyvä migrations well lives in a small number of agencies. The Hyvä partner program maintains a directory of certified partners, and the certifications correlate reasonably with migration depth – though the correlation is not perfect, and the right diagnostic is still to ask each candidate agency for three recent Hyvä migrations with specifics on module compatibility decisions, checkout rebuild scope, and measured CWV outcomes.
Agencies that can walk through specific migrations with module names, checkout patterns rebuilt, and measured performance results are demonstrating the pattern recognition that produces reliable estimates. Agencies that speak in generalities are showing you that they have not built the practice depth yet, regardless of their certifications.
Bemeir’s Hyvä practice has shipped Hyvä migrations across retail, B2B, and DTC contexts, with the Adobe Commerce engagement model supporting the broader platform work that often accompanies the theme migration. The retailers who get the best outcomes from Hyvä migration are the ones who run rigorous evaluation of partners, structure the engagement with the right pricing model for the work, and treat the migration as the performance investment it is rather than a cosmetic update.
For deeper reference on Hyvä migration patterns and outcomes, the Hyvä documentation, the Adobe Commerce DevDocs, and the Web.dev Core Web Vitals documentation provide structured technical context. Industry research from Forrester on commerce performance and broader analysis from Digital Commerce 360 frames the conversion economics that justify the migration investment.
