The single most underestimated variable in a Hyvä migration is the third-party module situation. Most retailers begin migration planning with a composer.json that lists fifty or eighty modules and assume that the agency will figure out compatibility during implementation. The reality is that the module compatibility work, when surveyed properly, determines a substantial portion of the migration timeline and cost. The retailers who do this work upstream get accurate estimates and predictable execution. The retailers who defer it get the discovery cost as implementation overrun.
This article describes the compatibility framework we use during Hyvä migration discovery. The framework classifies every module by Hyvä compatibility tier, by retailer dependency on the module, and by the work required to land it on Hyvä. The output is a documented decision matrix that drives the implementation plan rather than producing surprises in the middle of the project.
Tier 1: Modules With Native Hyvä Support
The first tier is modules that already ship with Hyvä-compatible frontend implementations, either from the original vendor or from the Hyvä Themes module compatibility list. The work for these modules is configuration and validation rather than implementation. The risk is low.
The modules in this tier typically include the major payment gateways (Adyen, Klarna, Stripe, PayPal in most variants), the major search providers (Algolia, Klevu, Searchspring in newer versions), the major analytics platforms (Google Tag Manager, Adobe Launch when properly configured), and a growing list of subscription, loyalty, and personalization tools whose vendors have invested in Hyvä support.
The discovery work for this tier is to verify that the specific version of each module installed on the storefront has Hyvä support, that the configuration translates cleanly, and that the integration’s behavioral parity matches what the storefront depends on. The verification typically takes a few hours per module and surfaces edge cases early.
Tier 2: Modules With Hyvä Community Compatibility
The second tier is modules that do not have native Hyvä support from the original vendor but have community-maintained compatibility patches available. The work for these modules is to integrate the community patch, validate it, and accept the ongoing maintenance burden of the patch sitting between your production code and the vendor’s upstream releases.
The tier 2 risk profile is moderate. The community patches are usually high quality, but they introduce a coupling between the storefront and the patch maintainer that is not formally supported. The patch maintainer may move on, the vendor may release a breaking change that the patch does not handle, or the patch may fall behind on security updates. These risks are manageable but require ongoing attention.
The discovery work for this tier is to identify which community patches are available for which modules, assess the patch maintainer’s track record and the maintenance cadence, and decide whether to use the community patch or move the module to tier 4 (replacement). The decision depends on how critical the module is to the storefront, how active the community maintenance is, and how much you trust the patch maintainer to keep it current.
Tier 3: Modules That Need Frontend Rewrite
The third tier is modules that work fine on the Adobe Commerce backend but whose frontend implementation is built for Luma and does not have Hyvä compatibility (native or community). The work for these modules is to rewrite the frontend layer for Hyvä while preserving the backend functionality.
The rewrite scope varies substantially by module. Some modules have minimal frontend – a few configuration screens and a checkout widget – and the rewrite is contained. Other modules have substantial frontend – full product configurators, complex cart behaviors, custom navigation – and the rewrite is a meaningful engineering project. The discovery has to assess each module specifically to estimate the rewrite cost.
The tier 3 modules are usually where the migration cost variance lives. A storefront with five tier 3 modules is meaningfully more expensive than a storefront with one tier 3 module. The discovery should produce a documented count of tier 3 modules and a per-module estimate of rewrite work, with assumptions visible so the retailer can make informed decisions about which modules to preserve, which to replace, and which to remove.
Tier 4: Modules That Need Replacement
The fourth tier is modules that should be replaced with Hyvä-native alternatives rather than carried forward through rewrite or community patches. The replacement may be a different vendor’s module that has native Hyvä support, a different architectural approach that uses Hyvä’s native capabilities, or removal of the functionality if it is not critical.
Replacement is often the better economic decision even when rewrite is technically feasible. A module that hasn’t been actively maintained, whose vendor has not invested in Hyvä, and whose functionality has commodity alternatives is usually cheaper to replace than to rewrite. The rewrite preserves the module’s quirks (including the ones the retailer doesn’t like); the replacement allows the retailer to upgrade the functionality at the same time.
The discovery work for this tier is to identify replacement candidates, estimate the migration cost from the current module to the replacement (data migration, configuration migration, integration retest), and assess whether the operational team is ready to switch vendors. The decision is not purely technical – it involves the relationship with the existing vendor, the support agreements, and the team’s familiarity with alternatives.
Tier 5: Modules That Should Be Removed
The fifth tier is modules that have accumulated on the storefront over time and should be removed during the migration rather than carried forward. The audit usually surfaces these – modules that were installed for a campaign three years ago, modules that duplicate functionality that has since been replaced, modules that introduce overhead without delivering value, and modules whose vendors are no longer in business.
The pattern is that storefronts accumulate modules faster than they remove them. A Luma storefront that has been running for five years often has fifteen or twenty modules that nobody on the current team installed, and that nobody on the current team can fully explain. The Hyvä migration is the natural occasion to clean this up.
The discovery work for tier 5 is to identify modules that should be removed, validate that no critical functionality depends on them, and document the decision so future audits don’t reinstall what was deliberately removed. The cleanup typically reduces the migration scope rather than expanding it.
| Tier | Description | Risk Profile | Discovery Output |
|---|---|---|---|
| Tier 1 | Native Hyvä support from vendor | Low – configure and validate | Verified config, parity test plan |
| Tier 2 | Community-maintained Hyvä patch | Moderate – accept maintenance dependency | Patch source, maintainer assessment |
| Tier 3 | Backend OK, frontend needs rewrite | Moderate to high – engineering scope | Per-module rewrite estimate |
| Tier 4 | Replace with Hyvä-native alternative | Moderate – vendor switch operational cost | Replacement target, migration plan |
| Tier 5 | Remove during migration | Low – but validate nothing depends on it | Removal list, dependency confirmation |
| Unsupported | Critical module with no clear path | High – may block migration | Escalation to vendor, contingency plan |
The Module Audit Process
A useful module audit produces six artifacts. The first is the runtime module inventory – what is actually loaded on production pages, gathered from logs and live profiling, not just the composer.json. The composer.json sometimes lists modules that are not actually enabled, and sometimes misses modules that are loaded through other means.
The second is the customization catalog – for each module, what has been modified beyond stock behavior. The customizations live in custom modules that override the original, in di.xml entries that change behavior, in theme overrides that change presentation, and sometimes in patches applied directly to vendor code. The catalog identifies what needs to be preserved or rebuilt during migration.
The third is the integration map – which modules participate in integrations with external systems, and what those integrations depend on. A payment module’s frontend rewrite has to preserve the integration contract with the gateway. A search module’s frontend rewrite has to preserve the indexing pipeline. The integration map ensures these dependencies don’t get lost in the rewrite.
The fourth is the operational dependency map – which modules participate in business-critical workflows, and what the workflow consequences are if the module misbehaves. A checkout customization that drives revenue is a different priority than a marketing widget that drives engagement. The dependency map informs QA priority and rollback planning.
The fifth is the tier classification itself – every module assigned to one of the tiers above, with the rationale documented. The classification is the input to the migration plan and the estimate.
The sixth is the prioritized work list – which modules need to be handled first because they are on critical paths, which can be handled later, and which can be deferred to post-launch if necessary. The prioritization shapes the implementation sequence.
How the Audit Drives Implementation Sequencing
The audit’s output drives the implementation sequence. The migration plan should start with the modules that have the highest combination of business criticality and migration complexity, because those are where the risk lives. Getting them right early reduces the chance of late-surfacing issues that compromise the launch.
Tier 1 modules (native Hyvä support) typically get configured and validated during the discovery phase itself, because the work is small and the validation surfaces edge cases early. Tier 2 modules (community patches) get integrated during the early implementation phase, with patch maintainer relationships established for ongoing support. Tier 3 modules (rewrite required) get prioritized by business criticality, with the most critical ones rewritten first. Tier 4 modules (replacement) get sequenced against vendor availability and team readiness. Tier 5 modules (removal) get handled during the migration cleanup phase.
The sequencing reduces the risk that a critical module’s complexity surfaces late in the project. The early validation of high-risk modules also produces useful information about whether the migration estimate needs to be revised. If the first tier 3 module rewrite takes substantially longer than estimated, the retailer learns that early enough to adjust scope or budget rather than discovering it at week sixteen.
Choosing the Modules to Standardize On
The Hyvä migration is the natural occasion to standardize the storefront’s module set rather than carrying forward the accumulated mix. Standardization means moving toward modules that are well-maintained, that have strong Hyvä support, that have community traction, and that fit the retailer’s ongoing needs. The migration cost increases marginally to do the standardization, but the long-term operating cost decreases substantially.
Bemeir’s Hyvä migration practice explicitly produces this module standardization recommendation during discovery. The recommendation reflects ecosystem patterns we have seen across migrations – which modules are aging well, which are getting deprecated, which vendors are investing in Hyvä, and which retailers should preserve versus replace. The recommendation is not a sales pitch for specific modules; it is a structured assessment that informs the retailer’s decisions.
For deeper reference on Hyvä module compatibility, the Hyvä Themes compatibility list is the authoritative source, and the Hyvä documentation provides technical reference. The Adobe Commerce marketplace provides the broader module ecosystem context, and the Adobe Commerce DevDocs provide the platform-level reference that informs compatibility assessment. Bemeir’s broader Adobe Commerce engagement model supports the full migration scope including the backend Adobe Commerce work that often accompanies the theme migration.
