Why a Partial Hyvä Migration Usually Fails (and How to Scope a Full One)

“Let’s just migrate the homepage and product detail pages first.” On paper, a partial Hyvä migration is the cautious choice. In practice, it is the most expensive way to get to Hyvä, and almost every merchant who starts down that path eventually has the same conversation about scrapping the partial approach and rebuilding properly. The reasons are structural to how Hyvä and Luma actually work, not opinions.

At Bemeir’s Magento practice, we have inherited enough partially migrated Hyvä projects to recognize the pattern. The merchant wanted to de-risk the project. The agency agreed to scope a smaller slice. Six months later the store has two themes, two checkout codebases, two analytics implementations, and a Lighthouse score that is barely better than where they started. Here is why that happens and how to scope a Hyvä migration that actually works.

What “partial migration” usually means

When merchants ask for a partial Hyvä migration, they usually mean one of three things. Each one has a different failure mode.

Page-type partial. Migrate certain page types (homepage, category, product detail) to Hyvä, leave others (account, wishlist, customer service pages) on Luma. The merchant assumes this means less code to write and faster delivery.

Feature partial. Migrate the storefront catalog to Hyvä but keep the checkout on Luma, or migrate the front-end but leave admin-facing customer screens on Luma.

Module partial. Migrate the base theme to Hyvä but skip the third-party extensions that do not yet have Hyvä compatibility, leaving them running their Luma fallback rendering.

All three sound reasonable in a planning meeting. All three create the same underlying problem: the customer’s session crosses a theme boundary, and that boundary breaks more than the planning meeting accounts for.

The structural reasons partials fail

Hyvä and Luma are not two themes that can coexist for the same customer like a desktop and mobile theme. They are two different rendering pipelines, two different JavaScript runtimes, and two different sets of asset bundles. When a customer navigates from a Hyvä page to a Luma page, the browser has to throw away most of what it loaded and rebuild from scratch.

This produces five failures that consistently show up in partial migrations.

Asset double-loading. Luma pages load roughly 350KB of JavaScript (KnockoutJS, RequireJS, jQuery, plus extension JS). Hyvä pages load roughly 25KB (Alpine.js, Tailwind CSS). A customer browsing across both types of pages downloads both bundles repeatedly because nothing caches usefully across them. Average page weight increases instead of decreasing.

Style conflicts. Tailwind’s utility classes and Luma’s BEM-style classes use different naming conventions and different CSS specificity. Shared header and footer components, if they are touched by both themes, end up needing two implementations or a brittle bridge layer that breaks every time either side gets updated.

JavaScript runtime collisions. Both Alpine.js and KnockoutJS use the `x-data` and `data-bind` attribute patterns respectively, and they do not interfere directly. But shared third-party scripts (analytics, personalization, chat widgets) often look for DOM elements that exist in one theme and not the other, and silently fail on the wrong page type.

Checkout funnel breakage. This is the most expensive failure. If a customer’s session crosses from Hyvä storefront to Luma checkout, the cart pages typically render twice (once in each theme system), trust signal placements jump, payment method ordering changes, and conversion data becomes uncomparable from before to after. The conversion lift the merchant expected from the Hyvä migration does not show up.

Analytics regression. Event triggers, page-view definitions, and ecommerce data layer fields are usually implemented in the theme. Mixed themes mean events fire from two different code paths, with two different naming conventions, and the data warehouse stops being trustable for the duration of the partial migration.

The budget math is also worse

The partial migration is rarely cheaper than the full one when honestly modeled, because the partial path has costs that the full migration does not.

The “re-migration to full Hyvä later” line is the one most people miss. Every partial Hyvä migration we have seen eventually becomes a full one, usually within 12 to 18 months, because the merchant gets tired of the operational tax. The deferred cost is real.

This is consistent with what the Hyvä team has published in their own commentary on partial migrations and with the consensus across the Magento community on Reddit about the pattern.

When a partial migration is actually defensible

There are two narrow situations where a partial migration is the right call. Both look different from what most merchants ask for.

Hyvä Checkout first, Hyvä storefront later. Migrating only the checkout to Hyvä Checkout while leaving the rest of the store on Luma is supported, well-documented, and delivers a clean conversion lift. It works because the checkout is a self-contained customer journey that ends in an order, not a navigation flow back into the storefront. We have shipped this for clients where the full storefront migration was a quarter away but the conversion lift on the checkout was needed immediately.

Single-store-view pilots in multi-store setups. If a merchant runs five store views on one Magento installation (multi-brand or multi-country) and wants to pilot Hyvä on one store view first, that is structurally clean: each store view is fully migrated, the customer never crosses themes, and the rollout to the other store views happens over a quarter. This is genuinely staged risk reduction. The Bemeir multi-store team has shipped this pattern for international rollouts.

Anything else that is sold as a partial migration is usually one of the failure modes above with a polite name.

How to scope a full migration that actually ships

A full Hyvä migration that lands on time and on budget has the same structural pattern regardless of merchant size. Five phases, with hard handoffs between them.

Phase 1: Compatibility audit (1-2 weeks). Catalog the extensions, custom modules, and customizations. Score the migration scope. Produce the budget. This is the gate before contract signature, not after.

Phase 2: Design system and component library (3-5 weeks). Build the Hyvä theme base, component library, and Tailwind configuration. This is where the brand visual language gets re-implemented in the new system, and where the layout primitives that will be used across all page types get standardized.

Phase 3: Page type migrations (4-10 weeks). Migrate page types in order of customer impact: PDP, category, homepage, search, account, then long-tail pages. Each page type is end-to-end tested before the next starts. This is the bulk of the engineering work.

Phase 4: Checkout, search, and personalization integration (3-6 weeks). Hyvä Checkout migration if in scope, plus integration of third-party search, recommendation, and personalization tools. This usually runs in parallel with the back half of phase 3.

Phase 5: QA, performance tuning, launch (2-4 weeks). Cross-browser regression testing, Core Web Vitals tuning, analytics QA, soft launch on a small traffic slice, full cutover. The performance tuning here typically delivers another 15-25 Lighthouse points on top of what Hyvä gives you by default.

Total timeline for a mid-market B2C migration: 14-22 weeks. For a B2B migration with custom company accounts: 20-30 weeks. The variation is driven almost entirely by what the compatibility audit found, which is why the audit matters so much.

The launch readiness check

Before going live with a Hyvä migration, the engineering team should be able to demonstrate a specific list of things. The check is short and should be hard to fake.

The new build needs to produce Lighthouse Performance scores above 90 on mobile for the homepage, category, and PDP, measured on a throttled 3G profile through a tool like PageSpeed Insights or WebPageTest. Core Web Vitals (LCP, CLS, INP) need to be in the green band on the same pages. The checkout funnel needs to complete with all production payment methods enabled. The analytics data layer needs to match the old Luma implementation event-for-event, validated by side-by-side comparison in the data warehouse. And the soft-launch traffic slice needs to show conversion rate equal to or above the Luma baseline before the full cutover.

If any of those fail, the launch waits. This is why staging the cutover, rather than a hard switch, is worth doing. Bemeir’s Hyvä team typically routes 5-10% of traffic to the new theme for a week, validates the funnel and the analytics, and only then flips the rest.

The honest framing for merchants on the fence

The pattern across the Magento merchants we have advised: a partial Hyvä migration feels like risk reduction and is actually risk extension. A full Hyvä migration feels like a bigger commitment and is actually the lower-risk path because there is no operational tax to pay for the next 12-18 months while the partial state sits there.

If the migration cannot be funded all at once, the staged path that works is Hyvä Checkout first, then the full storefront a quarter or two later. Both are full migrations of their respective surfaces. Both deliver clean wins. Neither leaves you with two themes to maintain.

The Hyvä migration is one of the highest-ROI projects available to Magento merchants in 2026. The way to get that ROI is to commit to the full scope, get the compatibility audit right before signing, and run the project in phases that each finish before the next starts. The half-measures cost more.