The single biggest risk in a Hyvä migration is not the migration itself; it is discovering, three weeks in, that two of your business-critical extensions do not work on Hyvä and were never going to. Hyvä replaces Luma’s frontend stack with Alpine.js and Tailwind CSS, which means any extension that ships its own KnockoutJS, RequireJS, or LESS-based frontend logic does not work without intervention. The intervention can be as small as a published Hyvä-compatible release, as medium as a community-built adapter, or as large as a full rebuild. Knowing which bucket each of your extensions falls into before you start the migration is the difference between a 10-week project and a 24-week disaster.
This piece walks through the compatibility framework Bemeir’s Hyvä team uses to evaluate Adobe Commerce extensions for migration readiness. The framework is designed to be runnable by a merchant or in-house team in a few days, before agency conversations begin.
The four compatibility tiers
Every extension on a Magento store falls into one of four tiers when it comes to Hyvä:
Tier 1: Native Hyvä support. The extension vendor ships a Hyvä-compatible release. The frontend logic has been ported to Alpine.js and Tailwind. Installation on a Hyvä-themed store is similar to installation on Luma. The Hyvä Compatibility Tracker maintains a public list of which vendors are in this tier.
Tier 2: Hyvä compatibility module or community adapter. A third party (Hyvä Themes itself, a community developer, or the Hyvä Compatibility Module project) ships an adapter that makes the extension work on Hyvä. Installation requires the original extension plus the adapter, and the maintenance burden is slightly higher because two modules need to stay in sync.
Tier 3: Backend logic works, frontend needs rebuilding. The extension’s PHP/business logic functions fine on Hyvä because Hyvä does not change the backend. The frontend pieces (templates, JavaScript, styling) do not work and need to be rebuilt in Alpine.js and Tailwind. Effort varies from one day for a simple display widget to several weeks for a complex checkout extension.
Tier 4: Not compatible without significant rework. The extension depends on Luma’s specific frontend stack in ways that cannot be cleanly adapted. Often these are old extensions, abandoned vendors, or extensions that bundle large amounts of custom KnockoutJS. The honest options are: replace with an alternative, rebuild from scratch, or live without the functionality.
How to evaluate your extension list
The process that works:
Step 1: Compile the extension list. Pull the composer.json and `app/code` directory listing. Cross-reference with the Adobe Commerce admin’s Module Manager. The output is a complete list of every extension installed, with version numbers.
Step 2: Check the Hyvä Compatibility Tracker. For each extension, look it up in the public tracker. The tracker marks each extension with its compatibility status. This catches most Tier 1 and Tier 2 extensions in 30 minutes.
Step 3: Check vendor websites. Some vendors maintain Hyvä compatibility on their own pages even if not yet in the public tracker. Klaviyo, Yotpo, Trustpilot, OneTrust, and similar enterprise vendors typically publish their Hyvä status.
Step 4: Inspect the extension code for any not covered above. For each extension not yet categorized, look at the contents of `view/frontend/`. If it contains `.phtml` templates referencing KnockoutJS (`x-magento-init`, `data-bind`), RequireJS (`require()` calls), or LESS imports, the extension is Tier 3 or Tier 4. If it has no frontend assets at all (admin-only or pure backend), it is generally safe (the backend works on Hyvä unchanged).
Step 5: Estimate effort for Tier 3 and Tier 4. For each Tier 3 extension, estimate rebuild effort by counting frontend files and complexity. A 2-template extension with simple display logic is usually 1-3 days. A 15-template checkout extension with payment integration is 2-6 weeks. Tier 4 extensions get the “replace or live without it” decision.
What to do with each tier
The actions are different per tier:
| Tier | Action | Time investment | Migration impact |
|---|---|---|---|
| 1: Native Hyvä | Update to compatible version | Hours | Low |
| 2: Adapter available | Install adapter alongside extension | Hours-day | Low, with slight maintenance overhead |
| 3: Backend OK, frontend rebuild | Build Hyvä frontend, retain backend | Days-weeks per extension | Moderate, depends on count and complexity |
| 4: Not compatible | Decide: replace, rebuild from scratch, or remove | Decision time + replacement cost | High, drives migration scope |
The merchants who do this exercise before agency conversations end up with much better proposals because the agencies can scope the actual work instead of pricing in uncertainty.
Common extension categories and their typical tiers
Based on common Adobe Commerce stores Bemeir has migrated, the typical tier distribution:
Email marketing (Klaviyo, Dotdigital, MailChimp). Usually Tier 1 or 2. The major vendors have committed to Hyvä support.
Reviews (Yotpo, Stamped, Trustpilot, Okendo). Mostly Tier 1 or 2; verify the specific version against the tracker.
Search and merchandising (Algolia, Klevu). Usually Tier 1; both vendors invested in Hyvä early.
Search extensions for catalog (built-in or Adobe Commerce Live Search). Native to Adobe Commerce, work on Hyvä without modification.
Payment methods (Adyen, Stripe, Braintree, PayPal). Generally Tier 1 or 2. Adobe Commerce’s payment provider ecosystem has largely caught up.
Tax compliance (Avalara, TaxJar). Backend-heavy; usually work without modification because the frontend touches are minimal.
Subscription extensions (ReCharge, custom subscription modules). Often Tier 3 or 4. The frontend logic is substantial and not always ported.
B2B-specific extensions (custom catalog visibility, quote workflows). Heavily store-specific. Custom extensions are almost always Tier 3.
Configurable product visualizers (3D product viewers, customizers). Usually Tier 3 or 4. These extensions ship heavy frontend logic that does not port cleanly.
Promotion and cart rule extensions. Backend logic works; frontend display blocks often need rebuilding.
The hidden risks that bite merchants
Three categories of compatibility risk that surface late:
Theme-customized extensions. If your current Luma theme overrides extension templates, those overrides do not carry over to Hyvä. The extension’s default Hyvä templates (if they exist) are what you will be working with. Audit theme overrides for any extension on the migration list.
Custom logic injected into extension behavior. If your current team has built event observers, plugins, or layout XML modifications that depend on extension-specific frontend behavior, those modifications need to be revisited for Hyvä. Often the modification was correct on Luma but is now redundant, broken, or needs to move into Alpine.js.
Marketplace extensions with no maintenance. Some Adobe Commerce stores carry one or two extensions from vendors who have abandoned the Magento ecosystem. These extensions are typically Tier 4 because nobody will publish a Hyvä-compatible release. Identify them early and plan replacement.
What to ask the extension vendor
For each extension on your list, three questions to send to the vendor before the migration starts:
“Does your extension have native Hyvä compatibility? If yes, what release versions support it and what is the upgrade path from our current version?”
“If not native, is there an officially supported Hyvä compatibility module or adapter? Who maintains it?”
“What is your roadmap for Hyvä support and is there an SLA you can commit to?”
Vendors that engage substantively with these questions are vendors worth keeping. Vendors that deflect or provide marketing-style answers are vendors to evaluate for replacement before they become migration blockers.
When the audit reveals a different migration scope
Sometimes the extension compatibility audit reveals that the migration is bigger than originally scoped. The five-week project becomes a fourteen-week project because three Tier 4 extensions need replacements that have their own integration and data migration work.
This is useful information to have before the migration starts. The merchants who discover it three weeks in are stuck in a bad position: the migration is partly done, the original timeline is broken, and the replacement decisions are being made under pressure. The merchants who discover it during the audit can make informed decisions: stage the migration, replace the problematic extensions in advance, or adjust scope and timeline before signing.
A clean extension compatibility audit is the single highest-leverage week of pre-migration work. Bemeir’s Hyvä team runs this audit on every prospective migration before producing a proposal, because the cost of getting it wrong is too high to skip. For merchants doing the work themselves, the framework above is the version that has held up across many migrations. The Adobe Commerce extension marketplace plus the Hyvä compatibility tracker plus a careful read of each extension’s frontend code is enough to answer the question accurately. The merchants who do this work get migrations that hit their original timeline; the merchants who do not get the other kind.
