The hardest part of selling a Hyvä migration internally is not the technical case. The technical case writes itself: Luma is heavy, Hyvä is light, Core Web Vitals improve, mobile experience is materially better. The harder part is the business case in language a mid-market CFO actually accepts, with the variables that get pressure-tested in the budget meeting and the assumptions that survive scrutiny six months after the project is approved.
This article is the conversion-case framework Bemeir’s Hyvä migration practice actually uses with mid-market retailers when the CMO is convinced but the CFO needs the model. It is not a sales pitch. It is the math a board-level audience will accept, with the variables identified and the sensitivities explained.
Why Core Web Vitals are the right anchor
Hyvä can be sold on a lot of dimensions: developer ergonomics, modernization, operational maintainability, security posture. All of these are real, but none of them are anchored in a metric a CFO can model. Core Web Vitals are different. They are measurable before and after. They are published by Google as ranking signals. They are correlated with conversion through extensive published research. And they translate cleanly into revenue impact through standard eCommerce math.
The CWV anchor also forces honesty into the conversation. A migration that does not actually improve CWV, for instance, a Hyvä port that reintroduces all the third-party scripts and heavy customization that made Luma slow, does not deserve the conversion case the framework produces. The framework is honest about that, which is what makes it survive board review.
The three variables that drive the model
The conversion case rests on three variables, each of which can be measured against the existing storefront before the migration starts.
1. Pre-migration LCP on mobile. Largest Contentful Paint is the strongest single predictor of mobile conversion among the CWV metrics. The mid-market Adobe Commerce baseline ranges from roughly 2 seconds (well-tuned Luma) to roughly 6 seconds (untuned Luma with heavy customization). The Hyvä target is typically under 2 seconds; well-executed implementations hit 1.0-1.5 seconds.
2. Mobile traffic share. Hyvä’s largest gains are on mobile. The conversion model needs to know what share of revenue comes from mobile sessions today. Most mid-market DTC retailers are 60-75% mobile by traffic but 45-60% mobile by revenue, because mobile converts at a lower rate. The Hyvä migration tends to compress that gap.
3. Current mobile conversion rate. The lift is expressed as a percentage of the current rate. A retailer at 1.5% mobile conversion sees different absolute revenue from a 10% lift than a retailer at 2.5% mobile conversion. The model needs the current number.
| Input variable | Source | Sensitivity in the model |
|---|---|---|
| Pre-migration LCP (mobile) | CrUX dataset or PageSpeed Insights baseline | High, drives the conversion lift range |
| Mobile traffic share (sessions) | Google Analytics, Heap, or platform analytics | High, determines impact magnitude |
| Mobile revenue share | Google Analytics or platform analytics | High, translates lift into dollars |
| Mobile conversion rate (current) | Google Analytics or platform analytics | High, base for percentage lift |
| Average order value (mobile) | Platform analytics | Medium, scales the revenue impact |
| Annual mobile sessions | Platform analytics | High, scales total revenue impact |
| Migration cost | Vendor proposals | Medium, affects payback, not whether it’s positive |
The conversion lift function
The conversion lift is not a single number. It is a function of how much LCP actually improves and where the starting point was. The model the framework uses is grounded in published research, including Google’s Core Web Vitals research and Akamai’s eCommerce performance studies, which together support the following directional relationship:
A 100ms improvement in mobile LCP correlates with roughly 1% improvement in mobile conversion for mid-market retailers. The relationship is not perfectly linear, there are diminishing returns once LCP gets under 1.5 seconds, and the lift is larger when the starting point is in the “poor” CWV band (above 4 seconds) than when it is in the “needs improvement” band (2.5-4 seconds).
For a retailer migrating from a Luma frontend with 4.5 second mobile LCP to a Hyvä frontend with 1.5 second mobile LCP, a 3,000ms improvement, the model projects roughly 18-25% mobile conversion lift in the optimistic case, with a base case in the 7-12% range that accounts for diminishing returns, mobile-segment-specific behavior, and post-launch dilution from new content and scripts.
The base case is the number the CFO should plan against. The optimistic case is the upside. Anyone modeling a Hyvä migration entirely against the optimistic case is setting up a credibility problem six months later.
The revenue translation
For a mid-market Adobe Commerce retailer with $25M in annual revenue, 65% mobile traffic share, 55% mobile revenue share, and 1.8% mobile conversion rate, the math runs as follows. Annual mobile revenue is approximately $13.75M. A 9% mobile conversion lift (the base case) translates to roughly $1.24M in incremental annual revenue. At a typical gross margin of 55%, the gross profit lift is approximately $680K annually.
Against a Hyvä migration cost in the $130K-180K range for a mid-market storefront, the payback period sits in the three-to-four month range on gross profit, and the three-year cumulative gross profit impact (assuming no growth) is in the $2.0M range. With reasonable growth assumptions, the three-year number compounds higher.
The model is sensitive to all of the inputs above. The most common mistake in CFO-level review is using a higher conversion rate than the retailer actually has, or using a higher lift assumption than the base case supports. The framework’s job is to keep the assumptions defensible.
What gets challenged in the budget meeting
Three challenges come up in almost every CFO-level Hyvä conversation, and the framework has to handle them honestly.
“How do we know the lift will materialize?” The honest answer is that the lift is probabilistic, not guaranteed. The empirical research supports a base case in the 5-10% range for most mid-market Adobe Commerce retailers with comparable migration scope. The base case is not the median outcome Bemeir’s Hyvä team sees; the median is somewhat higher. But the base case is what the budget should plan against, and the upside is upside.
“What if we just optimize Luma instead?” Luma can be optimized, and meaningful CWV improvements are possible without a full Hyvä migration. The honest math is that aggressive Luma performance work tends to cap out around 60-70% of the Hyvä-achievable improvement, and it costs roughly 40-60% of what a Hyvä migration costs. For retailers with a three-year platform horizon, the Hyvä migration is the better economic choice. For retailers with a 12-18 month platform horizon (replatforming or selling), Luma optimization can be the right answer.
“What about other CWV improvements that don’t require Hyvä?” Some CWV improvements, image optimization, CDN tuning, deferred script loading, are available regardless of frontend stack. The honest answer is that these should be done in parallel with the Hyvä migration, not instead of it, because they compound. Bemeir’s performance practice on Adobe Commerce typically includes a stack-wide CWV audit alongside any Hyvä migration scope.
What the model does not capture
The conversion case is real, and the conversion lift is the largest single revenue impact of a Hyvä migration. But the model intentionally does not capture three other sources of value, which is part of why the base case is conservative.
SEO ranking improvements. Google has confirmed CWV signals as ranking factors. Mid-market retailers who move from “poor” to “good” CWV scores typically see modest organic traffic improvements over six to twelve months. The model excludes this because it is harder to attribute cleanly. According to Google’s Page Experience update documentation, the SEO impact is real but variable across queries.
Engineering velocity. Hyvä codebases are materially easier to work in than Luma codebases. Frontend feature work that took two weeks on Luma typically takes three to five days on Hyvä. The compounding effect on engineering throughput over three years is significant, but it is hard to model in dollars cleanly.
Operational maintainability. Hyvä’s smaller surface area means fewer dependencies to patch, fewer interactions between extensions to debug, and fewer JavaScript performance regressions to chase. The reduction in steady-state engineering cost is meaningful, typically 10-20% of the previous frontend maintenance budget.
How to present the case
The most effective board-level presentation of a Hyvä migration leads with the base-case revenue impact, shows the sensitivity to the key assumptions, and frames the upside as upside without baking it into the headline number. The presentation should include the source of every assumption, Google Analytics data, CrUX measurements, vendor cost estimates, so that the assumptions can be pressure-tested rather than treated as opaque.
The retailers who get this approved on the first board meeting are the ones who treat the conversion case as a defensible model rather than as a sales pitch. The CFOs who approve these projects are not skeptical of the technology; they are skeptical of the math, and rightly so. The framework’s job is to make the math survive scrutiny, which it does because it is grounded in measurable inputs and conservative assumptions.
That discipline is what gets the migration approved. Everything that follows, the timeline, the team, the launch, depends on the budget existing in the first place. The CWV-driven conversion case is what makes the budget happen.
