A Hyvä migration is one of the most reliably high-ROI technology investments available to mid-market Adobe Commerce retailers, but the ROI case has to survive board-level scrutiny to actually get budgeted. The case the engineering team wants to make — “Hyvä is faster, Luma is slow, conversion will go up” — is true but not defensible against a CFO who wants to see assumptions, sensitivities, and a model that holds together under questioning.
This article is the ROI model that actually works in a budget meeting. It is the framework Bemeir’s Hyvä migration practice uses with retailers building the internal case for migration approval, and it is designed to be transparent about assumptions, conservative in its base case, and explicit about which variables drive the result. The CFOs who approve Hyvä migrations are the ones who see this kind of model; the ones who reject the migration are usually the ones who only saw the engineering pitch.
The model structure
The ROI model has six inputs, three outputs, and a sensitivity table. The inputs are measurable from the retailer’s existing analytics. The outputs are derived from a documented assumption framework. The sensitivity table shows what happens when the assumptions move.
Inputs (measurable from current analytics):
- Annual revenue
- Mobile revenue share (percentage of revenue from mobile sessions)
- Annual mobile sessions
- Current mobile conversion rate
- Current mobile LCP
- Gross margin (for calculating gross profit impact)
Outputs (derived from assumptions):
- Projected mobile LCP post-migration
- Projected mobile conversion rate post-migration
- Incremental annual revenue
- Incremental annual gross profit
- Payback period on migration investment
- Three-year cumulative gross profit impact
Sensitivity table: Shows how the outputs change under different assumptions for the key drivers.
The assumption framework
Three assumptions drive the model. Each one needs to be defensible.
Assumption 1: Post-migration mobile LCP. A well-implemented Hyvä migration consistently delivers mobile LCP between 1.2 and 2.0 seconds, with the median around 1.5-1.7 seconds on a non-trivial mid-market storefront. The conservative model assumes 1.8 seconds; the base case assumes 1.6 seconds; the optimistic case assumes 1.3 seconds. The actual outcome depends on the implementation quality, the third-party script footprint, and the discipline maintained post-launch.
Assumption 2: Conversion lift per 100ms of LCP improvement. The published research, including Akamai’s eCommerce performance research and Google’s Core Web Vitals studies, supports a directional relationship of roughly 1% mobile conversion lift per 100ms LCP improvement, for retailers starting in the “poor” CWV band. The relationship is not linear — there are diminishing returns once LCP gets under 2 seconds — so the model should use a discounted lift estimate for the latter half of the improvement.
A conservative model uses 0.7% per 100ms for the first 1,500ms of improvement and 0.4% per 100ms for the remainder. A base case uses 1.0% per 100ms for the first 1,500ms and 0.5% per 100ms for the remainder. The conservative assumptions are what survives board review.
Assumption 3: Lift realization timeline. The performance improvement is instant on launch; the conversion impact materializes over 4-12 weeks as user behavior adjusts and as search rankings reflect the improved CWV signals. The model should assume conversion lift is realized linearly over the first six months post-launch, then steady-state at the projected level.
| Assumption | Conservative case | Base case | Optimistic case |
|---|---|---|---|
| Post-migration mobile LCP | 1.8 seconds | 1.6 seconds | 1.3 seconds |
| Conversion lift per 100ms (first 1,500ms of improvement) | 0.7% | 1.0% | 1.2% |
| Conversion lift per 100ms (remainder) | 0.4% | 0.5% | 0.7% |
| Realization period | 6 months linear | 4 months linear | 3 months linear |
| Migration cost | $180K | $150K | $130K |
A worked example
For a mid-market Adobe Commerce DTC retailer with the following inputs:
- Annual revenue: $25M
- Mobile revenue share: 55%
- Annual mobile sessions: 8.5M
- Current mobile conversion rate: 1.8%
- Current mobile LCP: 4.2 seconds
- Gross margin: 55%
The model runs as follows.
LCP improvement: Pre-migration LCP is 4.2 seconds. Base case post-migration LCP is 1.6 seconds. Total improvement is 2,600 ms.
Conversion lift calculation (base case): The first 1,500 ms of improvement contributes 1.0% lift per 100 ms, for a total of 15% lift. The remaining 1,100 ms of improvement contributes 0.5% lift per 100 ms, for a total of 5.5% lift. Combined lift: 20.5%. However, this is the theoretical maximum; the realistic mobile conversion lift, accounting for the fact that not all visitors are CWV-sensitive and that the lift dilutes over time, is typically 50-70% of the theoretical. Applying a 60% realization factor: 12.3% practical lift.
The conservative case applies a 50% realization factor and produces an 8.5% lift. The optimistic case applies a 75% realization factor and produces a 15.4% lift.
Revenue impact (base case): Mobile annual revenue is $25M × 55% = $13.75M. The 12.3% lift produces $1.69M in incremental annual mobile revenue. Gross profit impact at 55% margin is $930K.
Migration cost: Base case $150K.
Payback period: $150K / $930K per year = 1.9 months on gross profit. On the conservative case ($580K gross profit lift, $180K cost), payback is 3.7 months. On the optimistic case ($1.20M gross profit lift, $130K cost), payback is 1.3 months.
Three-year cumulative gross profit: Base case $2.79M, conservative case $1.74M, optimistic case $3.6M.
The sensitivity table
What survives board review is not the headline number; it’s the table that shows how the result changes under different assumptions. The CFO’s job is to find where the model breaks. The framework’s job is to show that it holds across a reasonable range of assumptions.
| Scenario | LCP improvement | Conversion lift | Gross profit lift (annual) | Payback period |
|---|---|---|---|---|
| Pessimistic (poor implementation, low realization) | 2,000ms | 5% | $379K | 5.7 months |
| Conservative | 2,400ms | 8.5% | $580K | 3.7 months |
| Base case | 2,600ms | 12.3% | $930K | 1.9 months |
| Optimistic | 2,900ms | 15.4% | $1.20M | 1.3 months |
| Best case | 3,100ms | 18% | $1.36M | 1.1 months |
The pattern across the table is what makes the case. Even in the pessimistic scenario, the payback period is under six months. The base case is dramatically better, but the case does not depend on the base case materializing — the migration is economically positive across the full range of reasonable assumptions.
What can break the model
Three categories of issue can produce results below the pessimistic scenario, and the model should be honest about them.
Implementation quality. A Hyvä migration that re-introduces all the third-party scripts that made Luma slow, that keeps every existing custom JavaScript pattern, and that does not exercise performance discipline in the build will not achieve the LCP targets the model assumes. The implementation team’s performance discipline is what protects the model’s downside. Bemeir’s Hyvä team treats post-launch performance budget as part of the engagement scope, with monitoring and remediation discipline that prevents the worst-case implementation drift.
Post-launch script accumulation. A clean Hyvä launch followed by six months of adding heavy chat widgets, tracking pixels, A/B testing libraries, and personalization scripts can erode half the performance gain. The model assumes performance discipline is maintained post-launch. Retailers who do not maintain this discipline see the conversion lift erode toward the pessimistic scenario.
Business changes that affect conversion independently. The model assumes other factors affecting conversion (pricing, product mix, marketing strategy, competitive environment) hold roughly constant. Significant business changes during the realization period can mask the Hyvä lift in the conversion data, even if the underlying CWV-driven lift is real. The remediation is to track the lift through CWV-segment analysis (conversion among CWV-good sessions versus CWV-poor sessions) rather than purely through aggregate conversion.
What the model doesn’t capture
The model is intentionally conservative about what it counts. Three sources of value are real but excluded from the headline ROI calculation:
SEO ranking improvement. Improved Core Web Vitals are a Google ranking signal. Retailers who move from “poor” to “good” CWV scores typically see modest organic traffic improvement over the following 6-12 months. The model excludes this because the attribution is messy, but the impact is real. According to Google’s Page Experience documentation, the ranking benefit is variable but consistently positive for retailers who maintain strong CWV scores.
Engineering velocity. Hyvä codebases are dramatically 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 the dollar value is hard to model 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 typically 10-20% of the previous frontend maintenance budget.
All three of these dimensions add real value over three years. Including them in the headline ROI would produce a more impressive number but a less defensible one. The conservative-base-optimistic structure is what survives CFO review.
How to present the case
The board-ready presentation has three slides. The first is the framework and inputs (one slide, with the inputs measured against the retailer’s actual analytics). The second is the sensitivity table (one slide, with the four-scenario comparison and the pattern observation: positive ROI across all reasonable assumptions). The third is the implementation plan and risk mitigations (one slide, addressing what protects the model’s downside).
This format is what gets approved. The format that doesn’t get approved is the engineering pitch about Hyvä being technically superior. The CFO’s question is not whether Hyvä is technically superior; it’s whether the migration is economically positive against the retailer’s specific operating reality. The model above answers that question, defensibly, in a way that survives the questioning the CFO is going to apply. That defensibility is what produces the budget approval, which is the precondition for the migration actually happening. Everything else follows from getting the case made cleanly enough that the resources get committed.
