You do not have to migrate your Magento store to Hyva in a single release. The Luma theme fallback module lets specific routes keep running on a Luma-based theme while the rest of the store runs on Hyva, which means you can move page by page, ship value early, and keep a working checkout the whole time. Done well, a phased rollout gets your highest-traffic templates onto the fast frontend months before the long tail is finished. Done carelessly, it leaves you paying for two frontends indefinitely. This is how we sequence it, and how we decide when not to phase at all.
The mechanism is official and boring, which is exactly what you want in migration tooling. Per the Hyva theme fallback documentation, the module (hyva-themes/magento2-theme-fallback, installed through Composer) checks each incoming frontend request before the page renders. If the request path or the route matches a pattern you configured in the admin panel, Magento serves that page with your old Luma-based theme instead of Hyva. Everything else gets Hyva. One store, one backend, one cart and session, two frontends coexisting by route.
Do you have to migrate your whole Magento store to Hyva at once?
No, and for most mid-market stores you should not. A full Luma to Hyva rebuild on a store with meaningful customization typically runs three to six months of work once you account for extension replacement and design decisions. A phased rollout changes the shape of that timeline: the store starts earning the performance improvement on its most valuable pages within the first four to six weeks, while the remaining templates migrate behind the scenes.
The business case for getting the fast frontend live early is well documented. Google and Deloitte’s Milliseconds Make Millions study measured a 0.1 second improvement in mobile site speed producing an 8.4 percent lift in retail conversions and a 9.2 percent lift in average order value. Since Hyva became free and open source in November 2025, the license fee that used to sit in this math is gone, and adoption has climbed accordingly: HTTP Archive data from late 2025 shows 65 percent of Hyva-based Magento stores passing Core Web Vitals against 41 percent of Magento stores overall. Every month your catalog pages wait for the checkout rebuild to finish is a month of that gap left unclaimed.
How does the Luma theme fallback actually work?
The module adds a check in front of every frontend controller. When a request arrives, it compares the current route (module, controller, and action, such as the product view route) and the SEO-friendly URL path against the list you configured. On a match, it swaps the active theme to the fallback theme for that request, Luma by default. On fallback pages, Hyva is genuinely absent: Tailwind CSS and Alpine.js do not load, and the page pulls RequireJS and the standard Luma stack instead. Styling changes on those pages have to be done the old Magento way for as long as they stay on the fallback.
The configuration lives in three admin settings: an enable flag, the full path of the fallback theme, and the list of URL parts that should trigger it. The canonical use case is checkout. The default configuration keeps the checkout routes, including the PayPal Express review and shipping steps, on Luma, which is precisely how stores run a Hyva storefront over an unmodified Luma-based checkout or a heavily customized third-party one. Matching is prefix-based and pattern-based: configure the customer account route and every account page falls back, configure a single URL fragment and only pages containing it do.
Two properties make this safe to run in production. The theme decision happens per request, so there is no data migration, no second store view to maintain, and the cart, session, and customer login carry across theme boundaries untouched. And it is reversible per route: pull a pattern out of the list and that page is on Hyva at the next cache flush.
Which routes should move to Hyva first?
Move the templates where speed converts to money first: category pages, product detail pages, and the homepage, in that order of engineering attention. Category and product templates carry the bulk of organic entrances and paid landings on a typical catalog store, they are where Core Web Vitals failures cost rankings, and they are structurally repetitive, so one rebuilt template covers thousands of URLs. In our Hyva projects these three template groups are routinely live while checkout, customer account, and edge-case CMS pages are still on the fallback list.
The middle of the sequence is dictated by your extension surface rather than by traffic. Every module that touches the frontend needs a Hyva-compatible version, a replacement, or a rebuild, and what breaks is predictable if you audit before you start: search overlays, review widgets, loyalty bars, quick-order forms. Group pages by the extensions they share and migrate a group at a time, so each sprint retires a known set of compatibility problems instead of rediscovering the same one on six templates.
Checkout goes last on purpose. It is the highest-risk surface, the least crawled, and the one place where a rendering bug costs orders within the hour. Keep it on the fallback until the storefront is stable, then treat the checkout swap as its own project with its own testing budget, whether that destination is Hyva Checkout or a rebuilt custom flow.
What happens to your Core Web Vitals data during a phased rollout?
Expect your field data to improve in segments, not as one clean jump, and set stakeholder expectations accordingly. Core Web Vitals field numbers come from the Chrome UX Report, which aggregates over a rolling 28-day window. Pages you move to Hyva start accumulating fast sessions immediately, but the reported numbers take a full window to catch up, and origin-level scores blend your migrated and unmigrated traffic for as long as both exist. A store that is half Hyva can show middling origin numbers while its migrated templates are individually excellent.
The practical fix is to track at the template level, not the origin level. Search Console’s Core Web Vitals report groups URLs by similarity, which maps neatly onto a route-by-route migration: your product URL group should flip to Good within a window or two of that template going live, regardless of what checkout is still doing. We wrote about why lab scores and field data disagree during exactly this kind of transition, and the short version applies here: judge each phase by its own URL group’s field data, and judge the migration by the origin number only at the end.
What does running two frontends actually cost?
The fallback is free; the parallel operation is not. Budget for it honestly or the phase stretches into a permanent condition. Every fallback page still needs its Luma theme maintained, so design changes during the migration either land twice or get frozen on the old pages. QA gains a second dimension, because the journey from a Hyva category page into a Luma checkout crosses a theme boundary that needs testing on every release. Developers context-switch between Tailwind and Alpine on one side and LESS and RequireJS on the other. None of this is prohibitive over a three-to-six month phase. All of it compounds if the tail of the migration has no owner and no end date.
The failure mode we see in inherited migration projects is always the same: the high-visibility pages moved in the first quarter, the win was declared, and the fallback list quietly became load-bearing. Two years later the store is paying the double-maintenance tax indefinitely and the last Luma pages have drifted so far behind the design system that finishing feels like starting over. The fix is contractual as much as technical: a phased migration plan should name every route group, its owner, and its target sprint, including the boring ones.
When is a phased migration the wrong call?
Phasing is overhead, and on some stores the overhead buys nothing. A store with a lightly customized theme, a modest extension list, and no in-flight redesign can often complete a full Hyva build and cut over in one release for less total cost than a phased rollout, because it never pays the two-frontend tax at all. The same is true when a hard deadline forces the decision: if the store must be fully rebuilt by a replatform date, sequencing routes adds ceremony without reducing the critical path.
The honest screening question is where your risk concentrates. If the risk is spread across a large customized surface, phase it and retire risk sprint by sprint. If the risk is concentrated in one place, usually checkout, keep just that surface on the fallback and move everything else at once, which is the configuration the module was originally built for. And if your team cannot commit an owner to the migration tail, do not start a phase you will not finish; a tightly planned single migration with a competent partner beats an open-ended hybrid every time.
The end state to hold everyone to is simple: every route group on Hyva, the fallback module disabled and removed, the Luma theme and its build tooling deleted from the repository, and one frontend to maintain. The fallback is a bridge. The stores that get full value from it are the ones that treat the far side of the bridge as a scheduled destination, not a someday.
