Hyvä Migration Cost Calculator

Hyvä Themes is a commercial licence sold per Magento installation (not per storefront, not per developer). Pricing as of 2026:

• Hyvä Theme: €1,000 per Magento installation (one-off, perpetual). That covers the storefront theme — the part the calculator on this page projects against.
• Hyvä Checkout: €1,000 per Magento installation (one-off). Separate licence, separate codebase — only needed if you’re replacing Magento’s default checkout (which you almost always should if you’re going Hyvä).
• Hyvä Compatibility Module: free, bundled with the theme. Bridges most non-Hyvä-aware extensions so they continue to work without a full port.

That’s roughly $1,100–$2,200 USD all-in for the licences. It’s a once-off; there’s no annual renewal. The calculator on this page projects the migration labour — you add the licence cost on top.

Worth it? A $5M GMV store typically pays the licence back in 6–10 weeks of post-migration conversion lift. A $500k DTC store closer to 5–7 months.

Depends on which checkout you’re running and which extension. Three cases:

• You’re replacing default Magento checkout with Hyvä Checkout (recommended). Hyvä Checkout has a defined plugin interface for shipping methods, payment methods, and custom fields. Klarna, Stripe, Adyen, Mollie, Affirm, PayPal Braintree, Authorize.net all have working Hyvä Checkout adaptors. Custom checkout extensions need re-implementing as Magewire components — the calculator’s 1.4x “custom checkout” multiplier funds this.
• You’re keeping default Magento Luma checkout and only porting the storefront to Hyvä. Works fine but you don’t get the perf lift on checkout pages (the biggest conversion-lift surface). I do this for ~10% of migrations — usually B2B stores with a one-off legacy checkout integration that’s too expensive to port.
• You’re running OneStepCheckout / Magezon Checkout / Aheadworks One Step Checkout. These don’t port to Hyvä Checkout — the extension vendor has to ship a Hyvä Checkout version (only OneStepCheckout has, as of mid-2026). Path forward: drop the third-party checkout extension and use Hyvä Checkout directly.

I audit your specific checkout shape in step 1 (Audit Luma). The audit output tells you which of the three buckets you’re in.

No. This is the #1 misconception about Hyvä. Three categories:

1. Extensions with an official Hyvä module (Amasty, Mageplaza, Yotpo, Klarna, Stripe, PayPal, Vertex, Klevu, Algolia, Mailchimp, BSS Commerce, Mirasvit, plus 50+ smaller vendors as of 2026). Drop in, configure, done. ~60% of typical extension stacks fall here. The calculator assumes ~0.2–0.5 weeks per extension in this bucket.
2. Extensions that work via the Hyvä Compatibility Module bridge. The compat module ships free with Hyvä Theme and renders the extension’s Luma frontend inside an iframe-like bridge. Works for: admin-only extensions (no storefront), email-only extensions, cron extensions, reporting extensions. ~25% of typical stacks. Zero porting work.
3. Extensions needing a full port. Storefront extensions with no Hyvä module and incompatible-with-bridge templates — usually custom mini-cart widgets, sticky-CTA bars, custom upsell components. ~15% of typical stacks. The calculator assumes 1–2 weeks per extension in this bucket.

The calculator’s third-party extensions count input applies an average over these three buckets weighted 60% / 25% / 15%, which matches what I’ve measured across 23 shipped migrations.

Measured across the 23 Hyvä migrations I’ve shipped (2023–2026), mobile Lighthouse performance score:

• Before (Luma, default config): median 28, range 12–52.
• Before (Luma, perf-tuned): median 41, range 28–68.
• After (stock Hyvä): median 92, range 84–98.
• After (Hyvä + perf-tuned): median 97, range 94–99.

The non-obvious wins beyond the score number:

• LCP: typically drops from 3.5–6s on Luma to 1.0–1.6s on Hyvä. Biggest single conversion-lift driver.
• INP: typically drops from 350–800ms (Luma + jQuery + Knockout) to 60–180ms (Hyvä + Alpine). Big on mobile checkout INP — passing the 200ms Core Web Vital threshold matters for both rankings and conversion.
• JS bundle size: Luma ships ~800KB–1.5MB of JS on first render. Hyvä ships 30–80KB (Alpine + your sprinkles). 10–30x reduction.

The 95+ floor is robust as long as your backend is healthy (server response time <500ms TTFB). If your hosting is undersized, Hyvä still helps but won’t alone get you to 95+.

Yes — and for stores above $10M GMV I usually recommend it. Two patterns:

1. Sub-domain split test. Hyvä on hyva.yourstore.com, Luma on www.yourstore.com, send 10–25% of traffic to the Hyvä sub-domain via a paid traffic source (Meta / Google Ads) for 2–4 weeks. Measure conversion, AOV, bounce, INP, error rate. If Hyvä outperforms (it usually does, +8–25%), do the full cutover. Cost: ~$2k–$5k of paid traffic for a clean signal.
2. Geo split. Cut over one country / region first (typically the smallest by GMV), watch 4–6 weeks, then cut the others. Lower-risk pattern for multi-region brands. No extra licence cost.

Things to know:

• A/B testing Luma vs Hyvä on the same URL via Optimizely / VWO doesn’t work cleanly — the two themes have completely different DOM + CSS so the A/B tool flickers visibly.
• You need analytics consistent across both: same GA4 / Matomo setup, same conversion definitions, same UTM handling. I set this up as part of step 4 (Build).
• The split-test “Hyvä loses” outcome is rare but real — usually means a specific Magento extension didn’t port cleanly and broke a critical flow. Diagnose, fix, re-test.

The Magento B2B backend (Companies, quotes, segment pricing, approval flows, requisition lists, shared catalogs) doesn’t change at all in a Hyvä migration — the data model stays identical. What changes is the storefront and checkout surfaces.

Time for the B2B-specific Hyvä work, on top of the base migration:

• Company-user role wiring: 4–8 hours. Hyvä handles company-user context natively if you wire it through correctly.
• Quote workflow (request quote → admin approve → convert to order): 16–32 hours. Quote request UI on storefront, quote dashboard for company admin, quote-to-order conversion via Hyvä Checkout.
• Segment pricing display on PDP + category: 12–20 hours. Logged-in company users see their pricing tier, guests see list price.
• Approval flows: 8–16 hours. Mostly UI on Hyvä side; the approval logic stays in the Magento B2B module.
• Requisition lists: 16–24 hours. Re-implements list management as Magewire components.
• Shared catalogs: usually 0 hours — works through stock category access.

Total B2B-on-top: ~1 dedicated sprint week per major B2B surface. The calculator’s “B2B checkout” 1.7x multiplier already bakes in this overhead.

Zero, with the blue-green cutover I default to. Here’s the actual playbook:

1. Pre-warm. The Hyvä storefront runs on a parallel pre-warmed instance (same database, same media, same backend — just a different frontend theme). Cache pre-warmed by replaying recent traffic. Lighthouse re-verified.
2. Content freeze. 24 hours before cutover, content / catalog edits pause so the two instances stay in sync. Order/customer data keeps flowing — both instances write to the same database.
3. Final sync + smoke test. Sync media + URL rewrites + cache warmer. Run a smoke-test suite on the pre-warmed Hyvä instance.
4. Flip. Change the load-balancer / DNS / Cloudflare to route to the Hyvä instance. DNS propagation tail is <30 seconds for sites on managed DNS (Cloudflare / Route 53 / Fastly).
5. Watch. Dashboards monitored for 4 hours: error rate, conversion rate, AOV, support volume. Rollback button stays armed for 72 hours — if anything tanks, route back to Luma in one command.

Result: customers experience zero downtime, no maintenance page, no broken sessions. The only people who notice the cutover are admins who paused content edits.

The alternative (in-place cutover) is cheaper but has a 30–120 minute maintenance window. Only worth it for sub-$500k GMV stores where the blue-green hosting cost overhead isn’t justified.

Yes — Hyvä supports both Magento Open Source and Adobe Commerce. Behaviour is identical for the storefront layer. The differences are:

• Adobe Commerce B2B features (Companies, quotes, segment pricing, approval flows, requisition lists, shared catalogs) all work on Hyvä. The B2B sprint week the calculator allocates covers them on both.
• Page Builder content (Adobe Commerce + paid Open Source extension) renders inside the Hyvä Compatibility Module bridge. No porting work, but you don’t get the Hyvä perf gain on Page Builder pages. Worth migrating heavy-traffic Page Builder content to native Hyvä blocks during the migration.
• Adobe Commerce admin / staging features (Content Staging, Customer Segmentation rules at preview time) are unchanged.
• Adobe Commerce Cloud deployment workflow is unchanged. Hyvä builds with the same setup:static-content:deploy pipeline. CI / CD doesn’t need rework.

Cost of the migration is the same whether you’re on Open Source or Adobe Commerce — the calculator output applies to both. The Hyvä licence cost is also the same.

The one extra consideration on Adobe Commerce: your Magento support contract / SLA may need notifying that you’ve adopted Hyvä for the storefront. Adobe support continues to cover the backend regardless.

Different scope, different decision.

• /magento-upgrade-cost-calculator — projects a Magento version upgrade (e.g. 2.4.6 → 2.4.9). Your theme stays whatever it is (Luma or already-Hyvä). Inputs: current version, target version, SKU count, custom modules, extensions, B2B, multi-store, custom checkout, ERP. Output: cost + timeline for the upgrade itself.
• /hyva-migration-cost-calculator (this page) — projects a Luma → Hyvä theme migration. Your Magento version stays whatever it is (2.4.6+). Inputs: Luma complexity, custom modules, extensions, PDP complexity, checkout complexity. Output: cost + timeline + sprint plan + risk factors + gantt for the Hyvä migration.

The two projects are independent but often run sequentially:

1. If you’re on 2.4.4 or older: upgrade to 2.4.6+ first (use the upgrade calculator), then migrate to Hyvä (use this calculator).
2. If you’re on 2.4.6+: jump straight to the Hyvä migration (use this calculator).
3. If you want to combine both: the combined project is roughly 10–15% cheaper than running them sequentially but adds 4–6 calendar weeks. Worth it if both are already on your roadmap.

Some clients run both calculators and send me a combined-project enquiry — I quote a single fixed price covering the upgrade + Hyvä migration as one engagement.

Yes if your team has shipped a Hyvä migration before. No if they haven’t. Specifically:

• You have a senior Magento dev who’s done at least one Hyvä migration: DIY works. You’ll spend ~70% of the calculator number in cash and 1.3–1.5x in calendar time. Best if perfectionism matters more than schedule.
• Your team is strong on Magento backend but new to Hyvä: Hyvä has an official 12-hour video training (free) and the docs are excellent. A senior dev can self-train in 1–2 weeks, then DIY. Expect 2x the calculator number in calendar time because of the learning curve mistakes.
• Your team is mid-level Magento or all-frontend with no Magento experience: Avoid DIY. Magento backend has too many sharp edges — integrating Hyvä Checkout with B2B, debugging Magewire performance, getting the cache-tag invalidation right. I’ve cleaned up 6+ “DIY Hyvä gone wrong” projects — usually ends up costing 1.5–2x what the calculator quoted.
• You want to learn: Hire me for steps 1–3 (Audit + Compute + Sprint plan), then have your team execute steps 4–5 with me on Slack as a fallback. Costs ~30% of the full engagement and your team owns the codebase.

The Hyvä community is generous on Slack — even DIY teams can usually get unstuck quickly. Not a substitute for shipped experience, but a real safety net.

Three honest cases where I’d push back on the migration:

1. You’re on the verge of replatforming. If you’re seriously evaluating Shopify Plus / BigCommerce / commercetools in the next 12 months, skip the Hyvä migration. The Hyvä storefront work has no portability to a different backend. Spend the $20k–$50k on the platform decision instead.
2. Your conversion bottleneck isn’t storefront performance. Hyvä lifts conversion mostly because of perf and INP. If your bottleneck is checkout friction (too many fields, no Apple Pay, no guest checkout), or product discovery (bad search, weak filters), or trust (no reviews, no clear shipping policy), Hyvä won’t fix those. Diagnose the bottleneck before migrating.
3. Tiny store (<$200k GMV). The Hyvä migration cost ($6k–$12k for default DTC) needs ~6–12 months of post-migration conversion lift to pay back at $200k GMV. If you’re in this band, the time + cost is better spent on traffic acquisition. Revisit when GMV crosses $500k.

Edge case where Hyvä might not be worth it but I’d still consider it: B2B-only store where 80%+ of traffic is logged-in repeat buyers with predictable carts. The Lighthouse / INP wins don’t matter as much for repeat-purchase intent. But even there, the developer-experience win (faster builds, simpler frontend) usually pays off in long-term maintenance cost.

Almost all major gateways have working Hyvä Checkout adaptors as of mid-2026. The current state:

• Klarna: official Hyvä Checkout module shipped by Klarna directly. Works for all Klarna products (Pay Now, Pay Later, Slice It). Free.
• Stripe: official Hyvä-compatible Stripe module from the Stripe team. Apple Pay, Google Pay, ACH, BNPL options all work.
• Adyen: official Adyen Hyvä Checkout adaptor. Drop-in supports all 100+ Adyen payment methods.
• PayPal Braintree: works via Hyvä Compatibility Module bridge + Magewire wrapper. Smooth integration.
• Mollie: community Hyvä Checkout module, well-maintained. Covers iDEAL, Bancontact, Sofort, SEPA.
• Affirm: community port available, used in production on 3 of my US-based migrations.
• Authorize.net: works through Hyvä Compatibility bridge. Stable on legacy implementations.
• Amazon Pay: official Hyvä module.
• Apple Pay direct (not via Stripe / Adyen): works through Magento Vault module + Hyvä Magewire wrapper.

The gateways that are not well-supported yet: a handful of regional payment providers (some Latin American + APAC processors), some legacy fraud-screening extensions, and a few exotic enterprise integrations. I check your specific gateway list in step 1 (Audit Luma) and flag any that need a custom port. Add 1–3 weeks per non-supported gateway.