The Chicago Magento Agency's Guide to Hyvä Theme Migration

We've been a Magento agency in Chicago since 2008. When Hyvä Themes hit the ecosystem, we were skeptical—another theme promise. Then we measured Core Web Vitals on client stores and the case became obvious: Hyvä is the most practical path to a fast Magento storefront without a full replatform.

This is the migration framework we use at Towering Media for US and Canadian merchants moving off Luma (or aged custom frontends) onto Hyvä.

Why Hyvä now (not next year)

Google's CWV thresholds affect ad quality and organic visibility. Luma checkout and catalog pages often ship 1.5–2+ MB of JavaScript before you add analytics, chat, and personalization.

Hyvä replaces Knockout/RequireJS on the storefront with Alpine.js and Tailwind. Typical results on our projects:

• 50–70% less frontend JS on category and product pages
• LCP improvements of 1–3 seconds on mobile field data (highly variable by hosting and images)
• Lower maintenance — fewer JS conflicts between theme and extensions

Delaying migration means paying for performance twice: once in emergency fixes, again in the eventual theme project.

Phase 1: Discovery (1–2 weeks)

Extension audit

List every module that touches the frontend:

bin/magento module:status | grep -v "Module is disabled"

Flag anything with view/frontend, RequireJS, or Knockout in:

• Layered navigation and search
• Checkout and cart
• Page Builder widgets
• Blog and CMS enhancements

Hyvä maintains a compatibility module ecosystem; unsupported extensions need replacements or custom Hyvä templates. Towering Media includes extension compatibility mapping in every Hyvä migration engagement.

CWV baseline

Capture before metrics from:

• Google PageSpeed Insights (origin-level)
• Chrome UX Report for key templates: home, category, product, cart
• Real-user monitoring if the client has it (GA4, SpeedCurve, etc.)

Store screenshots. Stakeholders forget how slow the old site felt.

Business constraints

Document:

• Peak seasons (do not launch in November without war room staffing)
• B2B features (quick order, company credit) tied to Luma
• Integrations: ERP, OMS, personalization, reviews

Phase 2: Planning (1 week)

Choose checkout strategy

Hyvä Theme does not include checkout. Pick one:

1. Hyvä Checkout — best default for standard B2C
2. React Checkout Pro — custom steps, complex B2B, multi-gateway UX (our implementation)
3. Luma fallback checkout — temporary only; kills CWV on the funnel's last mile

We rarely recommend option 3 beyond a short transition window.

Template mapping

Build a spreadsheet: Luma layout handles → Hyvä layout XML + Tailwind components. Prioritize revenue paths first (PLP, PDP, cart, checkout).

Content and merchandising freeze

Freeze major CMS and category changes during the final two weeks pre-launch. Merge conflicts in Page Builder content are painful.

Phase 3: Build (4–10 weeks)

Development environment

We use DDEV locally with production-anonymous data snapshots. Developers get:

• Hyvä default theme + child theme for brand tokens
• composer path repos for client custom modules
• CI running phpstan, phpcs, and frontend lint

Custom module pattern

For each custom Luma template override:

1. Port layout XML to Hyvä-compatible handles
2. Rewrite .phtml + Knockout as Alpine components or ViewModels
3. Delete RequireJS mixins that no longer apply

Example: a product badge module becomes a ViewModel + small Alpine snippet instead of a Knockout component.

Image and asset pass

Hyvä does not fix 4000px hero images. Run WebP/AVIF conversion and responsive srcset as part of migration, not as a follow-up ticket.

Phase 4: QA and performance verification (2 weeks)

Functional matrix

Test on real devices: iPhone Safari, mid-range Android, desktop Chrome.

• Configurable products, swatches, tier prices
• Cart rules, coupons, gift cards
• Multi-address checkout if enabled
• Customer account: orders, returns, address book

CWV acceptance criteria

We set go/no-go thresholds per client, typically:

• LCP < 2.5s (lab, mobile) on PDP and home
• CLS < 0.1 on PLP with active promotions
• INP < 200ms on search filter interactions

If INP fails, profile JavaScript before launch—usually a leftover third-party script.

Load testing

Hit cart and checkout APIs with k6 or JMeter at 2–3× expected peak traffic. Hyvä reduces frontend load; backend PHP-FPM limits still matter.

Phase 5: Launch and stabilize (1 week + 30-day watch)

Cutover playbook

1. Maintenance mode on
2. Deploy theme + Hyvä modules + checkout solution
3. bin/magento setup:upgrade, compile, deploy static content
4. Warm Varnish/FPC for top categories
5. Smoke test payments in production (real $1 auth)
6. Maintenance off; monitor logs and CrUX

Post-launch monitoring

Week 1 daily standup on:

• var/log/exception.log
• Payment gateway failures
• Shipping rate errors (often unrelated to Hyvä but blamed on the launch)

Weeks 2–4: compare conversion rate, bounce on PDP, and organic traffic to pre-migration baselines.

Client results framework (anonymized)

We report outcomes in four buckets:

Bucket	Example metrics
Speed	LCP, INP, total JS KB
Conversion	Checkout completion, mobile add-to-cart
Operations	Ticket volume, deploy time
SEO	Crawl stats, ranking stability (lagging indicator)

A recent mid-market retail client (US, ~$8M GMV):

• Mobile LCP improved from 4.2s → 2.0s (field, 28-day)
• Category page JS reduced ~62%
• Checkout completion up 9% (90-day, multi-factor)

Your mileage varies. We never sell Hyvä as a magic ranking boost—it is a sustainable performance floor for Magento.

Chicago perspective

Chicago merchants compete nationally. Site speed affects not just SEO but wholesale buyers evaluating suppliers on tablets in warehouses and consumers buying during commutes on the L.

Local agencies know the market, but Hyvä skill is scarce. Whether you work with us or another team, verify:

• Hyvä partner or demonstrable Hyvä project count
• Checkout strategy beyond "we'll keep Luma checkout for now"
• Extension compatibility plan in writing

Common mistakes we see

1. Underestimating extension rewrites — budget 30–40% of project time for third-party gaps
2. Skipping checkout — fast catalog + slow checkout is wasted effort
3. No rollback plan — keep Luma theme package tagged in Git for emergency revert
4. Launching before payment regression — test every gateway with 3DS and wallet buttons

Summary

Hyvä migration is a structured performance project, not a theme swap. Audit extensions, fix checkout in the same program, measure CWV before and after, and launch with a real war room.

If you are evaluating Hyvä for a Magento 2 or Adobe Commerce store, start with an extension compatibility audit and a CWV baseline this month—not after the next slow holiday season.

---

About the author: Branden Thomas is cofounder of Towering Media, a Chicago Magento and Adobe Commerce agency since 2008 and Hyvä Bronze Partner. Services include Hyvä theme development, performance optimization, and React Checkout Pro for Magento 2.