Will Your Magento Extensions Survive the Move to Hyvä?

Ask any merchant what worries them about moving to Hyvä and it is rarely the theme. It is the twenty, forty, sometimes eighty extensions their store runs on. The good news: most of them are fine. The work is knowing which are not before you start, not after.

Hyvä publishes a public tracker for exactly this question and it currently holds a little under a thousand entries. That number is reassuring and misleading at the same time. Here is how to read it properly, and how to audit your own store before anyone quotes you a price.

What actually changes, and what does not

Hyvä replaces the view layer and nothing else. Knockout.js is gone, replaced by Alpine.js. RequireJS is gone, so there is no module loader left to register anything with. jQuery and its widget library are gone. LESS is replaced by Tailwind. Everything below that line is untouched.

So an extension’s dependency injection, its plugins and observers, its resource models, its cron jobs, its console commands, its admin screens and its REST or GraphQL endpoints all keep working exactly as before. Your ERP connector does not care what your theme looks like. Neither does your tax engine, your import tool, or your server-side tracking.

What breaks is anything that ships a storefront view. Hyvä’s own documentation puts it plainly: modules built on the Luma or Blank themes need a compatibility module to work with Hyvä. In practice those modules give themselves away with four signatures:

• templates under view/frontend carrying Knockout data-bind attributes or x-magento-init blocks,
• a requirejs-config.js file,
• frontend JavaScript written as a RequireJS module or a jQuery widget,
• LESS files under view/frontend/web/css/source.

The useful consequence is that a compatibility module is a rewrite of the view layer only. The original extension’s PHP is reused as it is. That is why this work is bounded and estimable rather than open ended, and why vendors who have done it describe most of the code as copied rather than rewritten.

Five outcomes, not three

Every extension in your store lands in one of five places.

• It already supports Hyvä natively. The vendor ships support inside the extension itself, so you upgrade and move on. Amasty works this way across their catalogue. So do Smile Elasticsuite, the Dotdigital modules and Snowdog Menu.
• A free Hyvä compatibility module exists. Around three hundred and thirty tracker entries sit here. Algolia is the single most requested one on the whole tracker. Magefan Blog, Yotpo, Nosto, Klaviyo, Ebizmarts MailChimp and most of the Aheadworks and MageWorx catalogues are in this group too.
• The vendor distributes its own adapter. Sometimes from its own Composer repository rather than Hyvä’s. Mirasvit moved several of theirs to Mirasvit-owned packages. Aheadworks now ships some compatibility modules only through their own repository, which means an active subscription. Mollie, Tweakwise and SeQura publish their own.
• Nothing exists and it has to be rebuilt or replaced. This is where the bespoke modules a previous agency dropped into app/code always land, because they will never appear on any tracker.
• You leave it on Luma. Hyvä ships a theme fallback module that keeps nominated routes rendering in the old theme. More on that below, because it is both the escape hatch and the trap.

The audit is simply counting how many of yours sit in the last two buckets. That count is your real scope. Anyone quoting a Hyvä project without doing it is guessing.

What the tracker will not tell you

The tracker is public, it has been running since 2021, and it is the right starting point. Search it by vendor name and read the issue body, not just the label. Three things it will not tell you matter more than the status:

Published does not mean complete. Each issue carries a feature checklist showing which parts of the extension were actually ported. The Klaviyo entry ticks two items: the layout does not break, and customer information reaches Klaviyo. Everything else is unticked. A full port and a partial one look identical from the outside if you only read the label.

A compatibility module can exist and still be the wrong answer. Exactly one entry on the tracker carries a performance warning label, and it is a widely used page builder. Somebody did the work, the result is slow, and the tracker says so if you read past the status.

Vendor support is version scoped. Amasty’s own tracker entries carry a disclaimer telling you the information may only be accurate for specific module versions and to verify directly with them. If your store is pinned to 2023 releases, a green entry is not a green light for your store. Roughly a hundred entries carry no label at all. Those are requests nobody has picked up.

Start here: the Hyvä compatibility module tracker. There is a second one for checkout, which is where most scoping goes wrong.

Checkout is a separate project

The most common mistake is treating checkout as part of the theme migration. It is not.

Third-party one-page checkout extensions do not port. They are Knockout rewrites of Magento’s checkout, and Hyvä Checkout is a different checkout altogether, sold under its own commercial licence at one thousand euro per Magento installation. Your realistic options are to keep the Luma checkout running under theme fallback, to move to Hyvä Checkout, or to use the free open-source React checkout from the Friends of Hyvä project.

Payment methods are the sharpest version of the frontend and backend split. The gateway integration is server side and survives the migration untouched. The payment form, the hosted iframe, the redirect handling: that is frontend, and it has to be re-integrated for whichever checkout you land on. Hyvä maintains a second tracker just for this, with well over four hundred entries, and it covers shipping and address autocomplete too. Carrier pickup-point selectors and address validation are checkout frontend code and need exactly the same treatment.

Hyvä’s own FAQ lists the Luma checkouts confirmed to work under fallback, including OneStepCheckout, Amasty Checkout, Clean Checkout and Mageplaza One Step Checkout. They are explicit that this is transitional, and that a Luma checkout inside a Hyvä storefront needs extra styling work to stop looking like a different website.

The escape hatch nobody mentions

Hyvä publishes a theme fallback module and it is the honest answer for the long tail. You install it, enable it, and nominate the routes that should keep rendering in Luma. A heavy legacy configurator. A rarely visited account page. A checkout you are not ready to rebuild yet.

The trade-off is documented by Hyvä themselves. On a fallback route the Hyvä theme is not active at all. Neither Tailwind nor Alpine loads. RequireJS and the full Luma dependency chain load instead, and any styling for those pages has to be built the old Magento way. So the page keeps working, you lose the performance win on that route, and you now maintain two frontends.

Used deliberately on three routes, that is good engineering. Used to avoid the audit, it is how you end up with a Hyvä store that is not fast.

How to audit your own store in an afternoon

This is mechanical work and you can do most of it yourself before you talk to anyone.

1. Get the real module list

Run bin/magento module:status. Use that rather than composer show, because it includes modules dropped straight into app/code that Composer knows nothing about, and those are exactly the ones with no tracker entry and no vendor to ask.

2. Find which of them touch the storefront

Three searches do most of the job. Look for directories matching view/frontend. Look for any requirejs-config.js under a frontend path. Count the .phtml files under view/frontend/templates per module. A module with a frontend directory, no templates, no JavaScript and only transactional email files is almost certainly safe. A module with a requirejs-config.js and forty templates is a project.

3. Grep for the APIs that no longer exist

Search .phtml files for data-bind, x-magento-init and data-mage-init. Search the JavaScript for ko.observable, uiComponent and jQuery widget registrations. Every hit is view-layer code that has to be rewritten in Alpine.

4. Check what you already have

Run composer show and filter for hyva. Read app/etc/hyva-themes.json, which lists the compatibility modules registered in the Tailwind build. On a store that has had a partial Hyvä attempt before, this is often more than people expect.

5. Cross-reference, then price it

Check everything left against both trackers and against the vendor’s own site, because tracker data is version scoped. There is also a community tool, hyva-compatibility-checker, which walks a Magento root and writes JSON and CSV reports listing every module with its JavaScript, template and layout XML file counts and line counts. It is not a Hyvä product, so treat its output as an estimate. But line counts per module are a direct effort proxy, and that is what turns migration anxiety into a spreadsheet somebody can actually price.

Fewer extensions is often the point

A migration is the best moment to stop paying for bloat. On Vitacom we removed around 180 modules that were choking the backend, and the store got faster and cheaper to run, not poorer in features. PageSpeed went from 12 to 100, server response from 15,814ms to 12ms, and the hardware dropped from 64 cores and 256GB of RAM to 8 cores and 32GB. Eight times less infrastructure. Read the full Vitacom case study.

So before rebuilding a frontend extension to run on Hyvä, the honest first question is whether the store needs it at all. Two more are worth asking in the same pass. Is this extension doing something Magento now does natively? And is it installed but switched off, which is common on stores that have changed agencies a few times?

Every extension you retire is one you do not port, do not test, do not license and do not upgrade. That saving compounds every year, and it is the part of a migration nobody puts in the proposal.

If you want the wider picture first, we wrote separately about what a Hyvä migration actually involves, including timelines and what tends to break.

Book a free strategy call

Send us your extension list and we will tell you which survive the move, which need a compatibility module, which are worth dropping, and which will need rebuilding. Book a free strategy call and we will turn it into a clear scope before you commit to anything.