Luma to Hyva Migration: The Complete UK Guide

This guide walks through what a real Luma to Hyva migration looks like for a UK Magento 2 store in 2026. It's written for a CTO or ecommerce lead who's already decided Hyva is the right answer and now needs to plan the project.

If you're still deciding, start with Hyva vs Luma and the Hyva cost guide.

What you're actually migrating

Magento 2 has three layers: the database / catalogue / orders (which is the backend), the application logic (which includes your custom modules and configuration), and the storefront theme (which is Luma today, Hyva tomorrow).

A Luma to Hyva migration touches only the third layer. Your catalogue, your customer accounts, your order history, your URLs, your products, your prices, your inventory — all of these stay exactly where they are. You're swapping out one theme for another.

This is the single biggest difference between a re-theme and a replatform. Re-themes are 8 to 14 weeks. Replatforms are 4 to 9 months. If anyone tries to scope your Hyva project closer to a replatform timeline, ask why.

Phase 1: the module audit (week 0)

Before you commit budget, do this. Run bin/magento module:status on production and list every non-Magento and non-Hyva module installed. For each one, tag it:

• Compatible. The vendor ships a Hyva-native version, or the Hyva Module Library has an official compatibility module.
• Probably compatible via Hyva Module Library. Check hyva.io's module library. If it's listed, that's your route.
• Needs work. No Hyva support exists. You'll need to either build a compatibility module yourself, swap for a Hyva-compatible alternative, or remove the feature entirely.
• Unused. Installed at some point, no longer used. Remove it from the migration scope.

The first three categories drive your budget. A store with 15 modules where two need rewriting is a clean project. A store with 30 modules where eight need rewriting is a different conversation, and your agency needs to know which one they're quoting before they put a number on the page.

The exact same audit should cover any in-house modules. Custom code your team has written over the years often touches the frontend in ways the developers have forgotten about. Schedule time for the team lead to walk through the codebase and flag anything that touches Luma templates, Knockout view models, or RequireJS configurations.

Phase 2: discovery and design (weeks 1 to 3)

Hyva ships with a default theme. Almost nobody uses it. The first phase of the build is taking your current visual identity and reimagining it for the Hyva approach.

This is also the moment to make decisions about what to change versus what to preserve. The right answer is almost always "preserve everything visible to customers and improve only the things that are clearly broken." Don't pile a redesign on top of a re-theme. We've seen plenty of stores try this and turn an 8-week project into a 6-month one.

Key decisions at this phase:

• Which checkout strategy: stay on Luma checkout, use Hyva-styled Luma checkout, or buy Hyva Checkout.
• How you handle PageBuilder content. The default Hyva theme renders PageBuilder fine, but Luma-specific styling in existing content may need adjusting.
• Whether you adopt Hyva's React Checkout / Hyva Commerce roadmap or stick with the standard Hyva theme.
• Mobile-first decisions on navigation, search, and PDP layouts.

Phase 3: build and module work (weeks 3 to 9)

This is where the bulk of the dev time goes. It splits into:

• Theme implementation. Tailwind classes for your design system, page templates, and component library.
• Module compatibility. Installing Hyva Module Library connectors, building custom compatibility modules for niche extensions, replacing or removing extensions where appropriate.
• Custom page templates. Anything that isn't standard — custom PDP variants, configurator widgets, account dashboards, B2B-specific pages.
• JSON-LD and SEO. Your structured data, hreflang tags, canonical handling, and any custom meta logic that lived in your Luma theme has to be reimplemented.

Run this on a staging environment that mirrors production hardware. Don't let anyone tell you "we'll test on Black Friday traffic later" — performance regressions in Hyva are rare but real, and you want to know on staging.

Phase 4: QA (weeks 7 to 11)

Hyva QA is a real piece of work. Don't underestimate it. You're checking:

• Every product type and variant combination renders correctly.
• Every PageBuilder content block displays as intended.
• Every payment method and shipping method works through to order placement.
• Every account-facing feature (login, register, password reset, address book, order history, reorder, wishlist, store credit, gift cards) works.
• Every email template still renders (yes, email templates often inherit from theme).
• Every integration (ESP, CDP, analytics, tag manager, search provider, reviews) still fires correctly.
• Every B2B-specific flow if you have them.

QA gets short-changed on a lot of Hyva migrations and it's the leading cause of post-launch incidents. Budget for it explicitly.

Phase 5: cutover (week 12 to 14)

The cutover itself is the easy bit if you've done the rest right. The default approach is:

1. Final pre-cutover staging review with key stakeholders.
2. Set up a rollback plan — typically you keep Luma deployable as a fallback for 30 days.
3. Pick a quiet trading window. For UK ecommerce, Tuesday to Thursday morning, avoiding peak season, ideally.
4. Switch the default theme in admin.
5. Cache flush, run a full crawl, monitor Real User Monitoring.
6. Verify checkout end-to-end with a real order through your live payment gateway.

If you have multi-store, you can stagger the cutover per store view, which gives you a softer landing.

What goes wrong, and how to avoid it

The three failure modes we see repeatedly:

The module audit was wishful thinking. The agency listed 20 modules, said "the Hyva Module Library covers most of these," and didn't actually verify each one. In week 8 you discover four modules need bespoke work. Fix: at the brief stage, require the agency to confirm each module by name against the Hyva Module Library or commit to building a compatibility module for it.

The redesign crept in. Marketing took the re-theme as an opportunity to "refresh the look." The PDP went through three rounds. Cutover slipped twice. Fix: lock the design before sprint zero. Anything that came up after the brief is a phase 2 project after launch.

The cutover happened too close to Black Friday. Don't. Cut over by mid-September at the latest if you trade peak. Cut over in January, February, or June otherwise.

What happens after launch

The first month post-launch you'll find small bugs and visual regressions. Budget two weeks of light development for cleanup. After that, your team will be considerably faster at shipping features than they were on Luma, and the ongoing cost of frontend work should drop visibly within 90 days.

The performance gain is real and immediate. Conversion gains take a few weeks to show in the data, and tend to be bigger on mobile than desktop. Measure them properly — set up a clean before / after split in your analytics so you have the numbers to justify the spend.