Hyvä Magento developer: planning the migration

Start with the extension inventory

List the extensions and custom modules customers actually encounter: product options, search, account pages, promotions, delivery and payment. Record the installed version, storefront dependencies and who owns each integration. Backend-only modules and modules that replace templates or JavaScript need different assessments.

Check the Hyvä compatibility documentation and each vendor’s support for the exact version. A useful outcome is a short list of what already works, what needs a compatibility module, what needs custom work and what can be retired. That list is much more useful for estimating than a theme demo.

Choose the checkout separately

A Hyvä theme migration does not require moving to Hyvä Checkout at the same time. Hyvä provides a Luma theme fallback for routes that retain a Luma-based frontend. Keeping an existing checkout can give a team a smaller first release; adopting a new checkout needs its own compatibility and customer journey checks.

Make that choice against real requirements: payment methods, delivery rules, trade pricing, guest checkout and any custom address or order fields. Agree what must work on day one and test order placement all the way through to the systems that receive the order.

Define the boundary between the storefront and the backend

For each piece of customer-facing data, identify its owner and when it must be current. Price and stock displayed on a product page, checkout totals and the final order are different responsibilities. Document what happens when an integration is slow or unavailable, and which changes invalidate cached data.

I would keep unrelated ERP or backend refactors out of the first theme release where possible. Stable contracts make it easier to isolate a regression and give the frontend team something dependable to build against. My architecture and system design approach covers the ownership and failure questions behind these decisions.

Measure first, then plan the release

Capture a baseline for key page types and checkout interactions before replacing the theme. Use consistent devices, network conditions and customer states, and separate rendering time from backend response time. A frontend change will not explain every delay in an order journey.

In our Magento checkout performance case study, the team reduced LCP from 5.8 seconds to 1.6 by removing redundant fetches and reducing blocking work. That was Magento optimisation, not a Hyvä migration result. The checkout investigation guide explains how to separate those measurements.

Before launch, agree the automated checks, manual checkout scenarios, monitoring and rollback decision. Our Magento relaunch case study covers staged releases and rehearsed rollbacks. Those delivery habits matter just as much as the choice of theme.