Hyvä Compatibility Checker

A verdict of Compatible means the extension renders its frontend HTML correctly under Hyvä 1.3+, doesn’t inject Knockout or RequireJS dependencies, doesn’t break the cart or checkout flow, and survives a clean reindex + setup:upgrade. Backend admin behaviour is identical regardless of frontend theme — every status here judges only the storefront. So if a verdict says “Compatible”, you can install it next to Hyvä without porting work; if it says anything else, the row description explains exactly what gap remains.

Yes. A Hyvä module verdict means the vendor (or community) ships a small bridge package — usually free, distributed via composer or marketplace — that re-renders the extension’s frontend in Tailwind+Alpine instead of Luma’s Knockout. The pattern is: composer require vendor/extension-hyva alongside the original vendor/extension, run setup:upgrade, and the storefront just works. Both packages are required — the original handles the backend and business logic, the Hyvä one re-skins the frontend.

A Partial verdict means the backend works perfectly under Hyvä but parts of the frontend — usually small AJAX widgets or PDP-block JS — are still in Knockout/RequireJS and render either broken or not at all. The fix is rewriting the frontend templates in Alpine.js + Tailwind. Typical port budget: 6 to 30 hours per extension, depending on how big the frontend surface is. A simple PDP info-block is 6h; a quote-cart UI or marketplace vendor-storefront can be 24–30h. The Partial-row description on the checker tells you which surface needs work.

Blockers can’t cohabit with Hyvä — they own a flow Hyvä also wants to own (most often the entire checkout). The fix is replacement, not bridging: remove the blocker, install the Hyvä native equivalent, migrate any custom config across. The most common case is a One-Step-Checkout extension — replaced by Hyvä Checkout (free, included in Hyvä 1.3+). For each Blocker the checker shows you what to swap to. Replacement effort is typically 1–3 weeks of dev time depending on how many custom payment/shipping integrations you had hooked into the old flow.

Exactly because Hyvä has its own checkout. Mageplaza, Amasty and IWD One-Step-Checkout extensions all rewrite Magento’s entire checkout in Knockout — which is the layer Hyvä replaces. Two checkouts can’t cohabit. Hyvä Checkout already does what those extensions do (one-page render, < 1 second, every major payment gateway, Klarna/Adyen/Stripe-element bridges) and ships free with Hyvä 1.3+. Removing the OSC extension also drops the licence fee — net win on cost, performance, and stability.

Every row was hand-verified by installing the extension on a Hyvä 1.3+ staging store and running real customer flows — not auto-scraped, not vendor-claimed. The database is updated every quarter, plus ad-hoc whenever a vendor ships a new Hyvä bridge. Last full sweep: Q2 2026. If you spot a row that looks out of date based on your own testing, drop me an email — I’ll re-verify and update for everyone.

Treat it as ? Unknown: assume it might need work until proved otherwise. The fastest way to lock the verdict is a 2-hour spike — install the extension on a Hyvä staging copy, click through the customer flows, screenshot any visual or functional gaps. That gives you the verdict, the porting effort, and the risk profile. If you have several unknowns, send the list via the audit form below and I’ll spike the lot in a single day.

Three steps:

1. Lock all Unknowns via 2-hour spikes — never start a migration with unknowns in scope.
2. Quote every Partial with a fixed-price port budget (use the per-extension hours estimate × your dev rate).
3. Plan replacements for every Blocker — spec the swap-out (e.g. Hyvä Checkout for OSC) before the migration kicks off.

Add the totals and you’ve got a realistic Hyvä migration scope before you sign anything. Most surprise-rework on Hyvä projects comes from skipping this audit and discovering Partials / Blockers mid-build.

Per-extension port costs (rule of thumb, freelance rates):

• Small frontend surface (one PDP block, one info-widget): 6–10 hours = $500–$1,200.
• Medium surface (multi-block, AJAX category filter, customer-account page): 12–20 hours = $1,200–$2,400.
• Large surface (quote-cart UI, vendor storefront, multi-step wizard): 24–30 hours = $3,000–$4,500.

Agency rates run 1.5–2× this. The numbers are based on Hyvä ports I’ve shipped 2024–2026 — not vendor estimates.

The checker covers third-party extensions only — in-house custom modules need a per-module audit. Same verdict scheme applies: read the module’s frontend code, check whether it uses Knockout / RequireJS, count the number of phtml templates that reference Magento’s frontend JS APIs, estimate the Alpine port effort. As a quick rule of thumb, a custom module with no frontend code is automatically Compatible; one with 2 or more phtml templates and AJAX is almost always Partial. Send the module list via the audit form for a written verdict per module.

Hyvä 1.3+ is the recommended baseline because it ships Hyvä Checkout natively (no separate licence) and unlocks the official Adobe Commerce 2.4.9 native-Hyvä integration. Hyvä 1.2.x is still supported by every vendor compat module here, but if you’re upgrading the theme anyway, jump to 1.3+. Hyvä 1.1.x and earlier — some compat modules may have minor regressions; treat anything older than 1.2 as legacy and budget a small upgrade tax.

Yes — almost always. Even with 5–10 Partials and 1–2 Blockers, the Hyvä migration cost is recovered within 3–9 months of going live for most stores: 8–25% conversion lift from speed alone, lower hosting bills (fewer JS dependencies), and faster future feature builds (Tailwind+Alpine is roughly 2× productivity for frontend work vs Knockout). The audit just makes sure you go in with eyes open and a fixed budget, not with surprise rework eating the savings. Every store I’ve migrated since 2024 broke even on the Hyvä investment within a year.