Guides - Hyvä

Should You Migrate to Hyva? An Honest Decision Tree

- Alexandru-Manuel Carabus

Hyva is not a magic wand. If your TTFB is 15 seconds because your backend is drowning, Hyva changes nothing. Here is the honest decision tree we use with merchants before we take migration money: three checks, real numbers, and when to say no.

A minimalist geometric decision-tree diagram. A small filled navy circle sits at the bottom-centre of the frame; from it, three thin straight lines rise and splay outward, each ending at a small hollow shape at the top of the frame (circle, square, diamond, left to right). The middle shape, the square, carries a small muted orange dot indicating a chosen branch.

Hyva is not a magic wand. If your TTFB is 8 seconds because your Magento backend is drowning in 400 modules, Hyva will not fix that. You will spend three months migrating and end up with a slightly faster shell wrapped around the same broken engine.

Nobody tells merchants this. The Hyva pitch is always 'migrate and be fast'. Sometimes that is true. Often it is not. Here is how to tell which one you are.

The three checks before you migrate

Before you sign a migration contract, three numbers decide whether Hyva will actually help you.

1. Your TTFB

Open your storefront. Run it through PageSpeed Insights or WebPageTest. Look at Time to First Byte. If it is under 500ms, Hyva can genuinely halve your Largest Contentful Paint. If your TTFB is 3 seconds, 6 seconds, 15 seconds, Hyva changes nothing. The browser is still waiting on your server before rendering the first pixel.

We wrote a full breakdown of why fast themes do not fix slow servers: why your Hyva store is still slow. Read that first if your PageSpeed score has not moved.

2. Your extension footprint

Hyva reimplements the Magento frontend from scratch. This means every third-party extension that ships its own frontend, checkout add-ons, one-page checkout replacements, product configurators, review widgets, live chat, needs a Hyva-compatible version. If it does not exist, you rebuild it. If it exists as a paid add-on, you pay for it. If your store runs 40 extensions and 25 of them touch the frontend, budget realistically.

The honest ratio we see: for a Magento store with under 15 frontend-touching extensions, Hyva migration is usually straightforward. Between 15 and 30, it is a real project. Above 30, you are effectively rebuilding the frontend piece by piece, and the value case changes.

3. Your team

Hyva uses Tailwind, AlpineJS, and a much thinner PHP layer. If your dev team knows Knockout, Require.js, and LESS, they can learn Hyva, but plan for the ramp-up. If you rely on a freelance developer who touches the site quarterly, migration is not a weekend job. It is a two to four month engagement depending on scope, and someone has to maintain it after.

When Hyva is the right answer

If your backend is healthy, your extension footprint is modest, and you have a team that can support the stack, Hyva delivers what it promises. The numbers are not marketing fiction.

At Meet Magento France 2026, the Uniwax team presented the data: Lighthouse score +1725 percent after their Hyva migration. That is not typical, it is what happens when you combine a Hyva rollout with a proper backend cleanup at the same time.

Our own Vitacom rebuild at LIQUIDLAB: PageSpeed score from 12 to 100. TTFB from 15,814ms to 12ms. That is roughly 1,300 times faster. Same product catalog, same traffic, same business logic. What changed: we rebuilt on Hyva and removed roughly 180 modules that were choking the backend. Hardware requirements dropped from 64 cores and 256GB RAM to 8 cores and 32GB. Eight times less infrastructure. Read the full Vitacom case study.

Notice the pattern: the wins are not 'we installed Hyva'. The wins are 'we installed Hyva AND fixed everything else that was wrong at the same time'. Hyva is the trigger for the cleanup. It is not the cleanup itself.

Migration without optimisation is money out the window

If you decide Hyva is right for you, one more rule matters. A migration on its own, without optimisation of everything else, is money out the window. You pay for three months of engineering, get a faster theme layer, and still ship the same slow queries, the same broken cron jobs, the same accumulated custom code and third-party extensions from the last five years. The theme is one layer. The store is a stack. The migration is also the best moment you will ever get to fix the rest, because you are already in the codebase, already breaking and rebuilding, already paying for engineering hours that would otherwise not be scheduled. Doing the cleanup separately costs roughly twice as much because you pay for setup, discovery and QA rounds twice.

That is why the partner you pick matters as much as the platform you migrate to. You need a partner who understands two things: your business, and your code base. Business context tells them which parts of the store are load-bearing and which parts are historical clutter nobody uses. Code review tells them what your last few years of Magento work actually consists of. If you have been on Magento for a couple of years, your custom modules and your third-party extensions are the first thing under the microscope. Some of them are legitimate business logic that has to be ported. Some of them are dead weight installed by an agency two hires ago that nobody has touched since. A partner who cannot tell the difference will port everything, and you will pay Hyva prices for Magento debt.

When Hyva is the wrong answer

You should not migrate to Hyva if:

Your TTFB is above 1 second and you do not have budget to also clean up the backend. Migrate later. Fix the server-side first.
You depend on a specific extension that has no Hyva port and no vendor plan to build one. Either wait, sponsor the port, or accept the cost of a custom build.
You launched three months ago and are still stabilising. A migration is a rebuild. Rebuilds interrupt everything for eight to twelve weeks. If you cannot afford that interruption, wait.
Your traffic pattern is B2B with logged-in users doing heavy carts and quote workflows. Hyva's default performance wins are on cold, anonymous, first-page traffic. If your users are always logged in with 200-item carts, the gains are smaller and the porting cost of your B2B extensions is higher.

None of this means Hyva is bad. It means Hyva has a shape, and your store has to fit that shape.

The real question is when, not if

The question is not whether Hyva is worth it. The development economics answer that clearly. On a Hyva storefront, front-end work drops by roughly six times compared to Luma. Checkout work drops by up to twenty times, because Hyva replaces the tangled Knockout and Require.js stack with Magewire, Tailwind and AlpineJS. A new checkbox in your checkout, the kind of change that used to take a Luma team eight hours across theme layers and JavaScript bindings, drops to fifteen minutes on Hyva. Multiply that by every quarterly checkout tweak, every new payment method, every A/B test, and the argument for staying on Luma disappears.

What we watch merchants get wrong is not the decision to migrate. It is the sequencing. They migrate first and try to clean up the backend later. That leaves them paying Hyva prices for a Magento stack that still runs on the same 400 modules, the same misconfigured Varnish, the same two-year-old database indexes. The theme is now fast, but everything upstream of the theme is still slow, so the visible speed gain caps at what the server permits.

Our Deep Code and Server Analysis is built exactly for this sequencing question. Three days of engineer time, a written report with concrete findings, 30 days of support afterwards. The report tells you what has to be fixed in the backend before or during migration, what can wait, and what your realistic engineering envelope is. Migrate with a written plan. Do not migrate hoping the theme will fix everything else.

What to do this week

Three concrete actions before you spend anything on a migration:

Measure your TTFB. PageSpeed Insights gives it to you in ten seconds. If it is above 800ms, that is your problem before anything else.
List your frontend-touching extensions. Open your `app/code` folder or your Composer manifest. Count how many extensions register frontend components. Above 20 is a warning sign for migration cost.
Ask your current agency what the migration plan actually is. If the answer is 'we install Hyva and it is fast', walk away. The real plan involves backend cleanup, extension audit, custom development where needed, and a staged rollout. If nobody is talking about those steps, nobody is planning them.

Talk to us

If you are weighing a Hyva migration and want an honest read on whether it fits your store this quarter, book a free strategy call. Thirty minutes with an engineer who has migrated real stores. No slides. No pressure. If Hyva is not the right answer for you, we will tell you.