To justify a Luma to Hyva migration to a CFO, tie it to revenue, not PageSpeed. Documented rebuilds show conversion lifts around 25 percent and order gains near 28 percent, and Google and Deloitte measured that each 0.1 second of load-time improvement raises retail conversions about 8 percent. Model that against your traffic and average order value, and the payback period is the number that gets sign-off.
Most migration pitches die in the finance meeting because they lead with the wrong metric. An engineering team walks in talking about a PageSpeed score jumping from 34 to 92, and the CFO hears a vanity number with no line on the P&L. The score is real and it matters, but it is an input, not an outcome. The outcome is revenue per session, and that is the language the business case has to be written in.
This is a practitioner guide to building that case. We are the USA’s first official Hyva Gold Partner, and we have sat on both sides of this meeting: the engineering side that knows the frontend rebuild is overdue, and the finance side that needs a defensible number before it releases budget. What follows is the evidence base, the revenue model, and the phased spend plan that turns “our site is slow” into an approved capital request.
The CFO’s real question is about return, not speed
When a CFO asks “why are we spending on a frontend rebuild,” they are not questioning whether the site is slow. They are asking three things: how much incremental revenue this produces, how confident you are in that number, and how long until the spend pays for itself. Everything in your business case should answer one of those three questions.
Hyva is the modern, high-performance frontend theme that replaces Magento 2’s legacy Luma theme. It rebuilds the storefront on Alpine.js and Tailwind CSS instead of Luma’s heavy stack of RequireJS, jQuery, and Knockout. The technical result is dramatic: far fewer HTTP requests, a large drop in JavaScript execution time, and a much lighter page. But the CFO does not buy fewer HTTP requests. The CFO buys the conversion behavior those requests produce, because faster pages hold more shoppers through checkout.
The mistake teams make is stopping at the technical layer. You have to carry the argument one step further, from milliseconds to money, and back it with data the finance team can audit.
The evidence: documented before-and-after data
A business case needs external proof, not just your own optimism. There are two categories of evidence that hold up in a finance review: independent studies on how speed maps to revenue, and real migration case studies with before-and-after numbers.
On the study side, the strongest reference is the Google and Deloitte “Milliseconds Make Millions” research, which analyzed real data across dozens of retail, travel, and lead-generation brands. It found that a 0.1 second improvement in load speed increased retail conversions by roughly 8 percent and average order value by about 9.2 percent. That is the coefficient your model runs on, and it comes from Google, not from an agency trying to sell a project.
On the case-study side, here is what documented Luma to Hyva rebuilds have reported:
| Store / source | Metric | Result after Hyva |
|---|---|---|
| Affordable Screen Company (Bemeir build) | Conversion rate | ~25% lift |
| Turbokits.com (Navigate Commerce case study) | Orders per day | +28% |
| Turbokits.com (Navigate Commerce case study) | Page load time | -22% |
| Turbokits.com (Navigate Commerce case study) | Overall performance score | +47% |
| Industry Core Web Vitals pass rate | Sites passing CWV | Higher on modern Alpine/Tailwind frontends than legacy Luma |
Two caveats keep this honest, and stating them makes the case stronger, not weaker. First, results vary by store; a site already at a decent PageSpeed score has less headroom than one stuck below 40. Second, some of the lift in these cases comes from the redesign that ships with the rebuild, not from the frontend framework alone. A careful CFO will ask about both, so put them on the table first.
The revenue model: turning a speed gain into a number
Here is the model. It is deliberately simple, because a business case a CFO can recompute in a spreadsheet beats a black box every time. Plug in your own numbers.
Inputs (use a store doing $40M in annual online revenue as the worked example):
- Annual online revenue: $40,000,000
- Current conversion rate: 2.0%
- Implied annual sessions: revenue divided by (AOV times conversion rate)
- Average order value (AOV): $100
- Annual sessions at those figures: 20,000,000
- Expected load-time improvement from Luma to Hyva: 1.0 second is common when moving off a sub-40 Luma store
The math:
A 1.0 second improvement is ten increments of 0.1 second. The Google and Deloitte coefficient is roughly 8 percent conversion lift per 0.1 second in retail, but that relationship is not linear across a full second, and applying it ten times over would badly overstate the result. The disciplined approach is to use a conservative blended lift. Take a fraction of the headline coefficient and model a total conversion lift of 10 to 20 percent, which is also the range independent migration reports cluster around.
At a 15 percent conversion lift on a 2.0 percent baseline, conversion moves to 2.3 percent. On 20,000,000 sessions at a $100 AOV, that is 60,000 additional orders per year, or $6,000,000 in incremental revenue. Even at a cautious 10 percent lift, you land near $4,000,000. Model AOV gains separately if you want, since the same research shows faster pages lift order value too, but leave that as upside rather than baseline.
Now put the spend against it. A mid-market Luma to Hyva migration typically runs in the low-to-mid six figures depending on the number of custom modules, third-party extensions, and B2B features involved. Against a conservative $4M incremental-revenue estimate, even a $250,000 project pays back in weeks of run-rate, not years. That payback line is the single most persuasive number in the deck.
Building the business case in five numbers
Reduce the whole thing to five figures the CFO can hold in their head:
- Current conversion rate and sessions. Your baseline. Pull it from analytics, not estimates.
- Modeled conversion lift. State it as a conservative range (10 to 20 percent) with the source coefficient behind it.
- Incremental annual revenue. The output of the model above.
- All-in project cost. Design, development, testing, and a support retainer for the first quarter after launch.
- Payback period. Cost divided by monthly incremental revenue. This is the number that closes the meeting.
If you want to pressure-test the assumptions before you present, a structured Magento technical audit gives you a defensible starting point for the current-state numbers and the scope estimate that drives cost.
Why Hyva beats an endless Luma patching project
A sharp CFO will ask the obvious follow-up: can’t we just optimize the Luma site we already have and skip the rebuild? Sometimes, and you should answer it honestly. If the store is a lightly-customized Luma site scoring in the 50s, targeted fixes to images, third-party scripts, and server response time can move the needle without a migration. We published a full practitioner comparison of Hyva vs Luma frontend performance precisely because targeted optimization is the right path for some merchants.
The problem is the ceiling. Luma ships a heavy JavaScript and rendering stack to every page, and no amount of image compression removes it. Teams that pour money into patching a badly-scoring Luma store often spend a meaningful fraction of a migration budget over two years and still cannot pass Core Web Vitals, because the framework itself is the bottleneck. Hyva removes the bottleneck rather than working around it. For a store stuck below 40, the rebuild is usually the cheaper path to a durable result once you count the patching spend you would otherwise repeat every year.
That framing matters to finance: you are not choosing between spending and not spending. You are choosing between a one-time capital project with a measurable payback and an open-ended operating cost with a low ceiling.
Timeline and how to phase the spend
The last objection is cash flow. A six-figure number lands better when it arrives in stages tied to deliverables. A phased Luma to Hyva program usually breaks into scoping and extension triage, a homepage and category-page build, the product and checkout rebuild, and a launch-and-stabilize window. Each phase produces something measurable, so finance releases the next tranche against results rather than promises.
Bemeir runs this as Hyva development work inside a broader Magento and Adobe Commerce practice, which matters because most migrations touch the backend integration layer, not just the theme. Founded in Brooklyn in 2014, Bemeir works as an extension of the merchant’s team; you can read more about how we operate on the about Bemeir page. Our differentiator on projects like this is an unusually deep technology partner ecosystem, which keeps payment, personalization, and fraud integrations intact through the rebuild instead of breaking them.
We work across platforms too, so if the finance conversation ends up questioning whether Magento is even the right home, we can speak to the alternatives honestly. Bemeir also delivers on Shopify and Shopify Plus, BigCommerce, and Shopware, which means the recommendation to stay on Adobe Commerce and rebuild the frontend is one we make on the merits, not because it is the only thing we sell.
Frequently asked questions
How much conversion lift can we actually claim in the business case?
Model a conservative 10 to 20 percent conversion lift, and present it as a range rather than a single number. Documented rebuilds cluster there, and it stays defensible even if a skeptical CFO discounts it. Treat average-order-value gains as separate upside rather than baseline, since those depend on catalog and merchandising as much as speed.
What if our Luma store already scores above 60 on PageSpeed?
Then the case is weaker and you should say so. A store already passing or close to passing Core Web Vitals has less headroom, so the conversion lift will be smaller. In that situation, targeted Luma optimization may return more per dollar than a full migration. The business case is strongest for stores stuck below 40, where the framework is clearly the ceiling.
How do we account for the redesign that comes with the migration?
Separate the two effects in your model. Part of any measured lift comes from the framework being faster, and part comes from the fresh design and UX cleanup that ship alongside it. You cannot fully isolate them, but acknowledging the overlap up front builds credibility. If anything, it strengthens the case, since the merchant gets both improvements from one project.
What is a realistic payback period?
For a store stuck below 40 on PageSpeed, payback is usually measured in weeks to a couple of months of incremental revenue run-rate, not years. The exact figure depends on your traffic volume and project cost, but the model above shows why: even a low-single-digit-percent conversion lift on eight-figure revenue produces incremental revenue that dwarfs a six-figure project cost.
Who should own the business case internally?
The ecommerce or digital lead should own it, but co-author the numbers section with someone from finance. A model the CFO’s own team helped build is far harder to reject than one handed over from engineering. Bring the technical team in only for the scope and cost inputs, and keep the headline framing about revenue and payback.
The frontend score is where this conversation starts, but it is not where it should end. Translate the speed gain into conversions, the conversions into revenue, and the revenue into a payback period, and the migration stops being a technical request and becomes what it actually is: one of the highest-return capital projects an ecommerce business can make.
