A Luma to Hyva migration is not a theme swap. It is a full frontend rebuild: Hyva removes Knockout.js, RequireJS, jQuery, and LESS and replaces them with Alpine.js and Tailwind CSS, so every template, script, and style your storefront depends on has to be reauthored or replaced. This checklist scopes that work before you commit budget.
Most published guides are install tutorials. They tell you to run composer require, activate the theme, and “test third-party modules.” That is fine for a demo store and dangerous for a live one. What an in-house team actually needs before it engages an agency or greenlights a sprint is a scoping runbook: an inventory of what breaks, an acceptance gate that defines “done,” and a rollback plan that runs in minutes. This is that runbook.
Bemeir is the USA’s first official Hyva Gold Partner, and we have run this exact checklist across B2C, B2B, and multi-store Adobe Commerce builds. Use it to estimate honestly, not optimistically.
How to use this checklist
Work the phases in order. Each phase ends in a measurable exit condition, not a vibe. If you cannot check every box in a phase, you are not ready for the next one. Treat the boxes as the acceptance criteria you will hand to whoever does the build, whether that is your team or a Magento development partner.
The single number that determines your timeline and cost is the count of Luma-dependent frontend extensions you have to rebuild. Everything else is schedule noise around that one figure.
Phase 0: Baseline and environment
You cannot prove a migration worked if you never recorded where you started.
- [ ] Capture field Core Web Vitals from Google Search Console CrUX and lab scores from PageSpeed Insights for your five highest-traffic templates (home, category, product, cart, checkout). Save the raw numbers.
- [ ] Record current Magento or Adobe Commerce version and PHP version. Hyva 1.4.x targets Magento 2.4.7 and 2.4.8 on PHP 8.2 to 8.4. If you are below 2.4.6, scope the platform upgrade as a separate, prior workstream.
- [ ] Confirm Node.js and npm are installed on the build environment. Tailwind compilation depends on them.
- [ ] Stand up a staging environment that mirrors production data, extensions, and server config.
- [ ] Write and time a rollback: theme deactivation plus cache flush that returns Luma to the live store in under ten minutes. Test it before you need it.
Exit condition: a documented performance baseline, a confirmed version and PHP target, and a rehearsed rollback.
Phase 1: Extension and customization inventory
This is the phase every install tutorial skips, and it is the phase that sets your budget. Hyva does not touch backend PHP business logic, so an extension’s server-side code keeps working. Its storefront templates, JavaScript, and CSS do not. You have to sort every extension into one of four buckets.
| Bucket | What it means | Effort per extension | How to confirm |
|---|---|---|---|
| Backend-only | No storefront output (ERP connector, tax logic, indexer). Works untouched. | None | Check whether it renders any frontend template |
| Vendor Hyva module exists | Amasty, Mageplaza, Mirasvit, and 250+ others ship compatible builds | Install and config only | Vendor site or the official Hyva compatibility checker |
| Hyva-compat wrapper needed | Extension works but its templates need a Hyva-specific fallback module | 0.5 to 3 dev days | Renders on frontend, no vendor Hyva build |
| Full rebuild | Custom or abandoned module with jQuery/Knockout templates and no alternative | 2 to 10 dev days, or replace | Frontend output, no support, no substitute |
Checklist for this phase:
- [ ] Export the full module list (
bin/magento module:status) and mark each as backend-only or frontend-affecting. - [ ] For every frontend-affecting module, check the official Hyva compatibility list before assuming anything.
- [ ] Inventory your own theme customizations: template overrides, custom LESS, RequireJS mixins, Knockout components, and layout XML. Each is a rebuild line item.
- [ ] Flag anything touching checkout separately. Hyva ships a default checkout, and Hyva Checkout is a separate paid product. Decide now whether you keep the default, adopt Hyva Checkout, or port a third-party checkout, because that choice moves the estimate by weeks.
- [ ] Total the effort column. That number, not the theme install, is your project size.
Exit condition: every extension and customization is in a bucket, with a day estimate attached.
Phase 2: Frontend rebuild scope
Hyva leans on View Models and layout XML instead of template overrides, and it styles with Tailwind utility classes instead of compiled LESS. Do not copy old .less or .css files into the new theme. You are rebuilding, not porting.
- [ ] Create a child theme of Hyva Default. Never edit the base theme.
- [ ] Rebuild header, footer, navigation, and CMS blocks in Tailwind. Note that Hyva 1.4.0 moved to Tailwind CSS v4 and the Rust-based Oxide build engine, which changed class conventions, config format, and purge behavior from v3. If your team learned Tailwind v3, budget ramp time.
- [ ] Reauthor interactive components (mini-cart, filters, sliders, tabs, form validation) in Alpine.js. A Hyva theme uses Alpine v2 or v3, never both at once.
- [ ] Rebuild product and category page logic, including swatches, gallery, and add-to-cart.
- [ ] Use
npm run watchfor live compilation during development.
Exit condition: every template in your Phase 1 inventory is rebuilt on staging and renders without console errors.
Phase 3: Data-layer, tracking, and SEO parity
This is the phase that quietly loses revenue when teams skip it. A visually perfect Hyva storefront that breaks your analytics or drops your canonical tags is a failed migration.
- [ ] Rebuild your dataLayer pushes and Google Tag Manager triggers. Luma’s events fired off jQuery and Knockout hooks that no longer exist. GA4 ecommerce events, add-to-cart, and purchase tracking all need reattaching to Alpine events.
- [ ] Verify structured data (Product, Offer, BreadcrumbList, Organization) still emits on every template.
- [ ] Diff canonical tags, meta titles, meta descriptions, and hreflang between Luma and Hyva output for a sample of each template. Frontend rebuilds are where canonical tags silently disappear.
- [ ] Confirm robots directives, XML sitemap, and 301 redirect map are intact.
- [ ] Test that third-party pixels (Meta, TikTok, affiliate) still fire.
Exit condition: analytics, structured data, and SEO tags produce output identical to Luma on a template-by-template diff.
Phase 4: The CI acceptance gate
Treat “the theme looks right” as an opinion and the acceptance gate as the fact. Wire these checks into CI so a broken build cannot merge. This is the “acceptance checklist as a CI gate” that separates a scoped migration from a hopeful one.
- [ ] Lighthouse CI runs on home, category, product, cart, and checkout, and fails the build if performance drops below your agreed threshold (Hyva teams commonly gate at a mobile Lighthouse score of 90).
- [ ] Core Web Vitals lab checks assert LCP, INP, and CLS against Google’s good thresholds of 2.5s, 200ms, and 0.1.
- [ ]
bin/magento setup:di:compileand static content deploy run clean, with zero errors. - [ ] A JavaScript console-error check fails on any Alpine or runtime error across the five key templates.
- [ ] Automated add-to-cart-to-order-confirmation smoke test passes on staging.
- [ ] Visual regression snapshots for the five templates are reviewed and approved.
Exit condition: the full gate is green in CI on staging, twice, on separate runs.
Phase 5: Cutover and 72-hour watch
- [ ] Freeze code, take a full file and database backup, and confirm the rollback rehearsed in Phase 0 still works against current data.
- [ ] Deploy, flush caches, and run a full reindex.
- [ ] Smoke-test checkout with a live order in the first ten minutes.
- [ ] Watch error logs, Search Console coverage, 404 spikes, and conversion rate for 72 hours. A rankings or conversion dip in this window is usually a missed Phase 3 item, not a Hyva problem.
Timeline and cost, scoped honestly
The ranges below assume the platform is already on a Hyva-supported Magento version. Your Phase 1 total is what moves you within these bands.
| Store profile | Frontend extensions to rebuild | Typical timeline | Typical US cost range |
|---|---|---|---|
| Lean B2C | Under 10 | 4 to 6 weeks | $25,000 to $45,000 |
| Mid-market B2C/B2B | 10 to 25 | 6 to 10 weeks | $45,000 to $85,000 |
| Adobe Commerce B2B (company accounts, shared catalogs, requisition lists, negotiable quotes) | 25+ plus B2B flows | 12 to 16 weeks | $85,000 and up |
These are planning ranges, not quotes. The variance inside each band is driven almost entirely by how many extensions land in the “full rebuild” bucket in Phase 1.
When to bring in an agency
Run Phases 0 and 1 in-house regardless. That inventory is yours to own, and it makes every conversation with a vendor sharper. Bring in a partner when your Phase 1 total crosses roughly 15 rebuild-days, when B2B checkout flows are in scope, or when you cannot afford the 72-hour cutover window to go sideways. A team that has done this before will compress Phase 2 and catch the Phase 3 items your first migration would miss.
If the scoping exercise makes you question the platform itself rather than the frontend, that is a different decision. Bemeir also builds on Shopify and Shopify Plus, BigCommerce, and Shopware, and an honest partner will tell you when a replatform beats a reskin. More often, for a Magento store with real B2B logic and integration depth, Hyva is the faster path to the performance win. You can see the full breadth of our technology partner ecosystem and how we work as an extension of your team if you want the context behind that recommendation, and the short version of who we are lives on the Bemeir homepage.
Frequently asked questions
Our Magento 2 Luma store scores below 40 on PageSpeed. How much can Hyva realistically improve that?
A store stuck below 40 is almost always paying the Luma tax: heavy JavaScript, render-blocking LESS, and Knockout hydration. Hyva pages are commonly 4 to 5 times lighter than Luma, and teams regularly reach mobile Lighthouse scores above 90 after migration. The honest caveat is that Hyva fixes the frontend, not a slow ERP call in your cart or an unoptimized image pipeline. If your Phase 0 baseline shows third-party scripts and bloated media, those come with you unless you address them. Expect a large jump, and gate the exact target in Phase 4.
Is this a theme install or a rebuild?
A rebuild. The composer require step takes an afternoon. Reauthoring every template, script, and style your store actually uses in Alpine.js and Tailwind is the real project, and Phase 1 tells you how big it is.
What is the timeline and cost for a mid-sized store, say $40M in online revenue with several custom modules?
That profile usually lands in the mid-market band: 6 to 10 weeks and roughly $45,000 to $85,000, assuming you are already on a supported Magento 2.4 version. The custom modules are the swing factor. If those modules render frontend templates with no Hyva build available, each one is a 2-to-10-day rebuild, and enough of them pushes you toward the upper end. Run Phase 1 before you trust any single number.
Do our extensions still work after migrating to Hyva?
Backend logic works untouched. Anything that renders on the storefront needs a Hyva-compatible build, a compatibility wrapper, or a rebuild. Many major vendors ship Hyva versions, so check the official compatibility list before assuming a rewrite.
Should we adopt Hyva Checkout or keep the default?
Decide during Phase 1 because it moves the estimate materially. The default Hyva checkout covers standard B2C flows. Hyva Checkout, a separate paid product, is worth it when you have multi-step B2B requirements, custom fields, or third-party payment and shipping logic that the default cannot express cleanly.
