Hyvä vs Luma: 12 questions answered.

Adobe hasn’t formally deprecated Luma, but the de facto signals are clear:

• No meaningful Luma updates since 2022, only security backports.
• Adobe’s own 2024 announcement positioned Hyvä as the recommended frontend for Adobe Commerce going forward.
• Adobe Commerce Cloud onboarding for new merchants now defaults to Hyvä project templates.
• Magento Open Source still ships with Luma as default (won’t change in 2026), but every "what should I build new with?" recommendation from Adobe Solution Partners points at Hyvä.

The way to read this: Luma will keep working for 5+ more years (Magento doesn’t break things), but it’s in maintenance mode. Building greenfield on Luma in 2026 is choosing the legacy stack on day one.

Yes, Hyvä supports the full Magento B2B feature set (company accounts, requisition lists, quotes, shared catalogues, tier pricing). The work is in re-implementing custom UI on top of those features.

What needs porting:

• Company-account dashboards (custom Knockout templates → Alpine + Magewire)
• Requisition list / quick-order UIs (usually a clean refactor; the Hyvä versions are simpler)
• Custom price-tier display logic on PLP/PDP (move from KO to Alpine)
• B2B-only checkout flow tweaks (often easier in Hyvä Checkout)

B2B-heavy stores often see bigger conversion lifts after Hyvä migration than B2C ones, buyer expectations on UX have caught up to consumer-grade, and B2B Luma UX usually lags badly.

Depends on where the bleeding is. Two patterns I see:

• Storefront slow, checkout OK → full Hyvä first. If PLP/PDP Lighthouse is < 50 and bounce rate is high, fix the entry pages first. Hyvä Checkout is a smaller win on top.
• Storefront OK-ish, checkout abandonment > 70% mobile → Hyvä Checkout first. Captures ~50% of the perf wins for ~25% of the migration cost. Lower risk, faster ROI. Then plan a full Hyvä migration in a later phase.

For heavily customised Luma stores where a full migration is genuinely $30k+, Hyvä Checkout alone is often the right answer for the first 12 months. The two aren’t mutually exclusive, they stack.

The Hyvä Compatibility Module is a separately-licensed wrapper that lets Luma-only extensions render their UI inside a Hyvä storefront without rewriting them. It does this by injecting a sandboxed Knockout/RequireJS environment for those specific extensions, while the rest of the page stays Hyvä-native.

What it covers:

• ~95% of paid Luma-only extensions from major vendors (Amasty, Mageplaza, Magefan, Aheadworks, etc.)
• Most Magento Marketplace storefront extensions that haven’t shipped native Hyvä support yet
• Custom Luma extensions written in-house (with some setup work)

What it doesn’t cover:

• Page-builder extensions that try to take over the whole page rendering pipeline
• Extensions that hard-code Luma-specific class names everywhere
• The performance wins, Compat Module re-introduces some Luma JS, so a Compat-heavy store loses 10-30% of the Hyvä perf win. Still way ahead of pure Luma.

Luma: $0 license, ships with Magento Open Source. The cost is in performance work afterwards, a Luma store usually needs $5-15k of optimisation to claw the Lighthouse score above 60.

Hyvä: $1,000, $2,000 one-time license per store (per major version), then you own the code forever, no per-seat, no SaaS fee. Migration dev runs $5-20k depending on customisation depth and extension count. Greenfield builds tend to be cheaper than migrations because there’s no porting work.

3-year TCO: Hyvä typically wins by $5-30k once you factor in the conversion lift (8-25%) and the avoided performance-tuning bills. Stores with strong organic traffic break even fastest because every second of LCP improvement compounds across millions of pageviews.

Probably yes, the answer depends on the extension category:

• Storefront-impacting paid extensions (Amasty, Mageplaza, Magefan, etc.): ~95% have native Hyvä support in 2026, or work via the Hyvä Compatibility Module.
• Marketplace storefront extensions (free): ~70% native or compat-supported. Some niche ones may need a port.
• Admin-only extensions (reporting, exports, RMA): 100%, they don’t touch the storefront so Hyvä doesn’t affect them.
• Heavy frontend customisation extensions (page builders, layered nav, configurators): 80-90% have Hyvä parity, but check each one before committing.

The audit step in any migration starts with a per-extension compat check, no surprises mid-build.

Yes, and mostly in your favour. The required skills:

• Tailwind CSS: mainstream front-end skill, huge talent pool, easy to hire
• Alpine.js: small, easy to learn, most React/Vue devs pick it up in a weekend
• Magewire (server-side reactivity): Hyvä-specific, but well-documented. 1-2 weeks to ramp
• Magento backend (PHP, GraphQL, modules, plugins): identical to Luma, same talent pool

Compare to Luma which needed:

• jQuery (still findable, but devs hate it now)
• RequireJS (legacy, fewer experts every year)
• KnockoutJS (effectively dead, almost nobody under 30 has used it)
• UI Components XML (Magento-specific arcana)

Hiring for Hyvä is genuinely easier than Luma in 2026, and the dev quality is higher because the talent pool overlaps with mainstream web dev.

Three rough sizes:

• Small (low customisation, < 10 extensions): 4-6 weeks, $5-10k. Mostly theme port + brand re-skin. Fastest payback.
• Medium (custom Luma child theme, 10-25 extensions, some B2B): 6-9 weeks, $12-20k. Most stores fall here.
• Large (multi-store, heavy custom modules, B2B-heavy, 25+ extensions): 10-16 weeks, $25-60k. Often phased, full Hyvä on B2C storefronts first, B2B portal in a later phase.

Side-by-side QA + soft cutover (10% traffic for 7 days, then full) is included in every estimate. Roll-back plan stays available for 14 days post-cutover.

Same Magento multi-store mechanism (websites, store views, store-scoped configs), Hyvä sits on top, doesn’t change the architecture. Per-store theme overrides, per-store-view translations, per-store catalogue all work identically.

Where it’s actually better than Luma:

• Tailwind config can be per-child-theme, so different brand looks share the parent Hyvä foundation without LESS-import gymnastics
• Alpine state is local to each Hyvä component, so store-view-specific UI tweaks don’t leak across views
• Faster builds, no `setup:static-content:deploy` per-locale RequireJS pipeline grinding through 8 store views

For 5+ store-view setups, Hyvä actually saves engineering time on top of the perf wins.

Yes, by an embarrassing margin. On a stock Magento Open Source 2.4.8 install with the default catalogue:

• Lighthouse mobile performance: Hyvä 95-99 vs Luma 25-45 (orange/red zone)
• JS bundle (gzipped, homepage): Hyvä ~70 KB vs Luma ~450 KB
• First Contentful Paint (4G mid-tier Android): Hyvä 0.4s vs Luma 1.8s
• Largest Contentful Paint: Hyvä 0.9s vs Luma 4.1s
• Time to Interactive: Hyvä < 1s vs Luma 4-8s
• Interaction to Next Paint: Hyvä ~60ms vs Luma ~380ms

These numbers are from production stores I’ve migrated, not synthetic benchmarks. The gap shrinks slightly under heavy customisation, but Hyvä still wins by 2-3x on every Core Web Vital.

Hyvä, by a clear margin. The reasoning:

• Active development: Hyvä ships a new version every 6-8 weeks. Luma ships security patches only.
• Adobe’s direction: Adobe Commerce + Hyvä is the strategic frontend stack for 2026-2030.
• Talent pool: Tailwind/Alpine devs are growing; jQuery/Knockout devs are aging out.
• Extension ecosystem: new extensions ship Hyvä-first from 2024 onwards. Luma compat is becoming a "legacy support" feature in marketplace listings.
• Hyvä team: Acquired by Vaimo in 2024, well-funded, growing engineering team. Not a side-project.

Realistic horizon: Luma will work for 5+ more years but stop being competitive in 2-3. Hyvä has 10+ years of clear runway. If you’re planning a build that’ll live 5+ years, Hyvä is the only sensible answer in 2026.

If done right, no. If done wrong, yes, but it’s preventable. The risk areas:

• URL structure changes: none, if you keep the same Magento URL rewrites. Hyvä is a theme layer, not a URL change.
• Schema markup: Hyvä emits product/breadcrumb/organization schema by default. Verify it matches your current structured data, port any custom JSON-LD.
• Meta tags + canonical: handled by Magento core, so Hyvä doesn’t change them. Verify after cutover with a crawl.
• Page speed (positive): Lighthouse 95+ improves Core Web Vitals, which improves Google rankings on competitive queries. The lift usually shows up 4-8 weeks post-cutover.

Standard playbook: full Screaming Frog crawl pre-cutover, same crawl post-cutover, diff every node. Submit updated sitemap. Rankings hold or improve within 2 months in 90%+ of cases.