The cheapest part of a Hyvä migration is the day you sign the contract. The most expensive part is discovering, three months in, that the seven Luma extensions your store depends on do not have Hyvä compatibility, and rebuilding their functionality is going to add three months and six figures to the budget. The audit that prevents this is straightforward, it takes about a week, and almost no one does it before pricing the project.
Bemeir’s Magento team runs Hyvä compatibility audits as a standalone engagement for merchants evaluating the migration. The output is a 20-to-30-page document that tells the merchant, with line-item specificity, what works, what needs to be rebuilt, what should be replaced, and what the realistic budget looks like. Here is what the audit actually covers and why each piece matters.
What the audit is actually checking
A Hyvä compatibility audit is not a Lighthouse score or a brand-new screenshot review. It is an inventory of every piece of frontend code and every third-party extension that touches the customer-facing experience, scored against three questions: does it have native Hyvä compatibility, can it be made compatible with reasonable effort, or does it need to be rebuilt or replaced.
The scope falls into seven buckets. Each one is a place where the migration budget can move significantly based on what the audit finds.
Theme customizations. Every CSS override, layout XML change, and PHTML template modification in the existing Luma theme needs to be re-implemented in Hyvä’s Tailwind-based system. The audit catalogs how much custom code lives in the active Luma theme and estimates the rebuild effort in hours.
Third-party Magento extensions. The single largest variable in the budget. Each installed extension is checked against the Hyvä compatibility tracker, the vendor’s documentation, and (if necessary) a manual code inspection. Extensions are scored as native-compatible, vendor-supported compatibility module available, community-built compatibility module available, requires custom compatibility work, or no path forward and must be replaced.
Custom modules. In-house Magento modules that render frontend HTML need their templates rebuilt in Hyvä. The audit counts the templates, scores the complexity, and estimates rebuild hours per module.
JavaScript customizations. Custom KnockoutJS components, RequireJS modules, and inline scripts on the Luma frontend must be rewritten in Alpine.js for Hyvä. This is usually a smaller scope than feared, but it needs to be cataloged.
Checkout customizations. Separately tracked because Hyvä Checkout is its own migration. If the existing Luma checkout has custom fields, custom payment methods, custom order placement logic, or custom totals calculations, those need explicit handling in the Hyvä Checkout migration.
Search, recommendation, and personalization integrations. Algolia, Klevu, Searchspring, Nosto, Dynamic Yield, Bloomreach: each integration is checked for Hyvä-native modules, fallback paths, or the need for custom Alpine.js integrations.
Analytics and tag management. Custom Google Tag Manager triggers, custom Adobe Analytics implementations, custom Facebook Conversion API setups: the audit verifies that DOM selectors will survive the migration and the events will continue to fire.
What the audit actually outputs
A useful compatibility audit produces five concrete artifacts. If you are buying one, ask for all of them.
An extension compatibility matrix listing every installed extension, its current version, its Hyvä compatibility status (one of five categories above), the recommended action, and the estimated hours of work to resolve it.
A custom code inventory counting templates, layout XML files, JavaScript files, and PHTML overrides in the active theme and in custom modules, with effort estimates for re-implementation.
A risk register of the specific items in the codebase that are likely to balloon the budget. Common entries: one-page checkout extensions with deep DOM dependencies, custom KnockoutJS components doing real-time pricing, Adobe Page Builder content that uses widgets without Hyvä equivalents, and personalization scripts that inject HTML into the DOM after page load.
A scope-tiered budget showing the migration cost at three scopes: minimal viable Hyvä migration (replace what’s broken, defer everything else), recommended scope (replace, rebuild, and improve known weak points), and full optimization (use the migration to also rework checkout, search, and recommendation surfaces).
A roadmap with checkpoints that lays out the migration in phases with go/no-go gates, so the merchant can pause or change direction if the audit assumptions turn out to be wrong during build.
The risks the audit catches that change the budget
A handful of specific findings reliably move the Hyvä migration budget by six figures or more. These are the things the compatibility audit is most valuable for catching before pricing.
Adobe Page Builder content with custom widgets. Page Builder is supported in Hyvä, but only the standard widgets. If the merchant or a previous agency built custom Page Builder widgets, each one needs a Hyvä-compatible rebuild. We have seen catalogs with 40+ custom widgets, each one a small engineering project.
One-page checkout extensions. Aheadworks, Amasty, Mageplaza, and others publish one-page checkout extensions for Luma. None of them are drop-in compatible with Hyvä Checkout, which has its own architecture. The audit needs to identify which extension is in play and whether the merchant is willing to switch to Hyvä Checkout’s native flow.
Layered navigation extensions with heavy AJAX behavior. Several popular layered navigation modules use KnockoutJS components that do not exist in the Hyvä world. The migration may require switching to a Hyvä-native solution like the Hyvä-compatible Magento module ecosystem recommends, or building custom Alpine.js components.
Custom B2B account features. If the store uses Adobe Commerce B2B with custom company-account workflows (custom approval rules, custom requisition lists, custom requote flows), each customization needs explicit re-implementation. B2B audits typically add three to six weeks to the timeline that B2C migrations do not need.
Search and personalization integrations using DOM injection. Tools that inject HTML into the page after load (some Klevu setups, older Nosto integrations, custom personalization scripts) need to be re-validated against the new DOM structure. Selector breakage is the most common cause of post-launch personalization regressions.
What the audit does not need to catch
Worth setting expectations on what is not in scope. A Hyvä compatibility audit does not validate that your business logic is correct, does not redesign the customer experience, does not optimize your conversion funnel, and does not benchmark your Core Web Vitals (that’s a separate performance audit). It is a frontend code inventory with a budget attached.
If you need those other outputs, they are separate engagements. The Hyvä team at Bemeir typically runs the compatibility audit first, then layers a UX review or performance audit on top if the merchant wants them. Bundling them up front tends to slow the audit down without changing the migration scope.
A reasonable comparison framework
Here is how the audit findings typically distribute across the merchants we evaluate.
| Audit finding | Typical % of merchants | Typical budget impact |
|---|---|---|
| All extensions have Hyvä compat available | ~25% | Baseline migration cost |
| 1-3 extensions need custom compatibility work | ~40% | +10-25% budget |
| 4+ extensions need custom work or replacement | ~25% | +30-60% budget |
| Custom B2B features require explicit rebuild | ~10% (B2B subset) | +20-40% budget |
| Heavy Page Builder customization needs rebuild | ~8% | +15-35% budget |
| Combination of above (worst case) | ~5% | +60-100% budget |
The merchants in the bottom quartile of that table are also usually the merchants who most need the migration: they have the heaviest Luma stack, the worst Core Web Vitals, and the most to gain from getting off KnockoutJS. The audit is what makes that conversation honest before contract signature.
When to commission the audit
The compatibility audit is most valuable in three situations. First, when the merchant has decided to migrate to Hyvä and is gathering competitive proposals: the audit normalizes the scope across vendors so the proposals can actually be compared. Second, when the merchant is uncertain whether Hyvä is the right choice: the audit makes the math honest about what the migration will actually cost. Third, when an in-house team is going to lead the migration: the audit becomes the team’s project plan and risk register.
The audit is least valuable when the merchant has a fixed-price proposal from a vendor and just wants validation. In that situation, the merchant should ask the vendor for their version of the audit; if the vendor cannot produce one, that is the signal.
For the audit itself, our team at Bemeir runs the standalone engagement over five to seven business days, depending on the size of the extension footprint and whether B2B is in scope. Pricing reflects the engineering hours required to manually review the codebase, not a sales discovery process. The output is the document the merchant uses to scope the actual migration, whether they hire us to deliver it or not.
The Hyvä migration is one of the highest-ROI Magento projects available in 2026, but the ROI math only works when the budget is set against a realistic scope. The audit is the cheap insurance that makes that math real. Skipping it is how three-month projects become twelve-month projects.