How to Implement Hyvä Theme on an Existing Magento 2 Store

Your Magento 2 store works. But if it is still running on Luma, it is almost certainly slower than it should be, and that slowness is costing you in search rankings, mobile conversions, and developer time every time something needs updating.

Hyvä is the fix most Magento developers have moved to. It replaces Luma’s heavy JavaScript stack with a modern, lightweight frontend built on Tailwind CSS and Alpine.js. The result is Lighthouse scores above 90, faster page loads, and a codebase that is significantly easier to maintain.

In November 2025, the core Hyvä theme became free and open source, removing the previous per-store licensing cost that had been the main barrier to adoption. As of early 2026, over 6,400 Magento stores are running on Hyvä in production. If you are still on Luma, this is the right time to start planning the move.

This guide is written for Magento store owners and eCommerce managers, not just developers. It covers what the implementation actually involves, what to check before you start, what can go wrong, and how a certified Hyvä development team approaches the project on an existing live store.

Before getting into the steps, it helps to understand what is being removed and why it matters.

The default Luma theme in Magento 2 relies on a set of older JavaScript technologies, RequireJS, KnockoutJS, and jQuery, plus LESS for styling. These were standard when Magento 2 was built, but they create a heavy frontend that browsers have to download, parse, and execute before a page becomes usable. A typical Luma product page ships around 0.9 MB of data to the browser.

Hyvä replaces all of that with Tailwind CSS for styling and Alpine.js for interactivity. A comparable Hyvä product page ships around 0.15 MB. That is roughly a 6x reduction in page weight. The practical effect is pages that load faster, Core Web Vitals scores that move into the green, and Google PageSpeed scores that go from the 20–40 range typical of Luma into the 90+ range that Hyvä stores regularly achieve.

For your store, this means better organic search performance, lower bounce rates on mobile, and a faster shopping experience for customers. For your development team, it means a frontend that is considerably easier to work in Hyvä’s codebase cuts a typical Luma frontend of 230+ files down to roughly 5.

What Hyvä does not change is the Magento backend. Your products, orders, customers, admin panel, pricing rules, and integrations all remain exactly as they are. This is a frontend replacement, not a replatforming project.

Implementing Hyvä on an existing Magento 2 store is not a simple theme swap. The Hyvä frontend is architecturally different from Luma, which means code written for Luma does not automatically carry over. A proper implementation starts with a compatibility audit before any development begins.

Server and Magento version requirements

Hyvä requires Magento 2.4.4 or higher. PHP 8.1 is the minimum, with PHP 8.4 recommended for stores on Magento 2.4.9. Node.js is required for Tailwind CSS compilation during the build process. Your hosting environment needs to be on a stack that supports these requirements before any installation work begins.

If your store is on an older version of Magento 2.4.3 or below, a version upgrade needs to happen before Hyvä can be implemented. This is worth planning as part of the same project rather than treating them as separate workstreams.

Extension compatibility audit

This is the part that most often surprises merchants. Magento stores typically run a mix of first-party and third-party extensions. Most of these were built for the Luma frontend, using Luma’s JavaScript and template patterns. Hyvä’s architecture does not automatically support them.

Each extension in your store needs to be assessed before the migration begins. Many popular extensions already have Hyvä-compatible versions either from the original vendor or through community-built compatibility modules. Others need custom bridging work. Some may need to be replaced entirely.

The extension audit determines the actual scope and timeline of your Hyvä implementation. Skipping it, or discovering compatibility issues mid-project, is one of the most common reasons Hyvä migrations run over time and budget. A certified Hyvä development team will run this audit before agreeing a fixed scope.

Custom theme and layout work

If your current Luma store has significant custom design work, bespoke layouts, custom templates, or overridden Luma blocks, these cannot be directly ported to Hyvä. The templating system is different. Design work will need to be rebuilt in Hyvä’s template structure using Tailwind CSS.

For stores with a relatively standard Luma theme with minor customisations, this is manageable. For stores with heavily bespoke frontends, the design rebuild represents a meaningful portion of the project scope.

A Hyvä implementation on an existing live store follows a structured process. Here is how our team at KiwiCommerce approaches it.

Stage 1 Discovery and audit

Before any development work begins, the existing store is audited fully. This covers: current Magento version and PHP version; all installed extensions and their Hyvä compatibility status; custom theme files and layout overrides; third-party integrations (ERP, PIM, payment gateways, marketing tools); and current Core Web Vitals baseline scores.

The audit output is a clear project brief: what needs rebuilding, what extensions need compatibility work, what the staging and deployment approach will be, and a realistic timeline. For a mid-sized store with a moderate extension stack, this stage typically takes one to two weeks. Our consulting and discovery services can run this audit independently if you want an honest assessment before committing to a full project.

Stage 2 Staging environment setup

All Hyvä work happens on a staging environment that mirrors production data and integrations. No development work touches the live store during the implementation. This is non-negotiable. Hyvä changes the entire frontend architecture, and running implementation work on a live store creates unnecessary risk.

The staging environment is set up with the current store’s database, all extensions, and the same server configuration as production. This gives developers a realistic picture of how Hyvä will behave in your specific store before anything goes live.

Stage 3 Hyvä installation and base setup

With staging in place, the Hyvä theme is installed via Composer. Since the core theme went open source in November 2025, installation requires registering a free Packagist key from the Hyvä portal at hyva.io, a straightforward process. The Composer command pulls in the theme and its required modules, followed by the standard Magento setup commands to register the new theme.

At this point, Hyvä is installed, but the store looks unbranded. The default Hyvä theme applies, extensions are not yet bridged, and custom design work has not been applied. This is the foundation stage.

Stage 4 Child theme creation and design build

Rather than modifying the core Hyvä theme directly, all customisation happens in a child theme. This protects the implementation from being broken by future Hyvä updates; when Hyvä releases a new version, the child theme inherits the update cleanly.

The child theme is where your brand design is applied: colours, typography, layout, custom components, and any bespoke page templates your store requires. This work is built using Tailwind CSS, which means the styling approach is different from Luma’s LESS-based system. Developers familiar with Luma need to adapt to Tailwind’s utility-first methodology, which is one of the reasons Hyvä-experienced developers complete this stage faster than those doing their first Hyvä project.

For more detail on child theme structure, our guide on creating a Hyvä child theme covers the technical setup step by step.

Stage 5 Extension compatibility work

Each extension that requires Hyvä compatibility work is addressed at this stage. Where a vendor-supplied Hyvä module exists, it is installed and configured. Where no compatibility module is available, the bridging work is built custom. Where an extension cannot be made compatible in a reasonable scope, alternatives are evaluated.

This stage is where the pre-project audit pays for itself. Extensions that were identified as requiring custom work have already been scoped and budgeted. There are no surprises mid-project.

For a thorough breakdown of how to handle individual extensions, our guide on making Magento 2 extensions compatible with the Hyvä theme covers the technical approach in detail.

Stage 6 Testing

Testing on a Hyvä migration covers several areas. Functional testing covers the full customer journey: product browsing, search, add to cart, checkout, account creation, and order management. Payment gateway behaviour is tested explicitly, particularly if your checkout uses custom payment UI elements. Mobile responsiveness is checked across device sizes.

Performance testing measures the Core Web Vitals scores achieved on Hyvä before the migration goes live. This gives a baseline to compare against the production results after launch and confirms the implementation is actually delivering the speed improvements Hyvä is capable of.

Extension-specific testing validates that every module in your stack behaves correctly on the Hyvä frontend, not just that it is installed, but that it works as your customers will experience it.

Stage 7 Go-live

Once testing is signed off, the staging build is deployed to production. Hyvä is set as the active theme in the Magento admin under Content > Design > Configuration. A full cache flush completes the switch.

Post-launch monitoring covers the first 24 to 48 hours specifically. Core Web Vitals are measured on the live store. Any edge cases that appear in production but did not surface in staging are addressed immediately.

The performance gains from a properly implemented Hyvä migration are consistent and measurable. Google Lighthouse scores above 90 are standard. Core Web Vitals in the green are achievable on most stores. Page load times drop significantly compared to Luma.

These are not cosmetic improvements. Faster pages rank better in Google. They convert better on mobile. They hold visitors longer. The connection between page speed and revenue is well established, and Hyvä is the most practical way to achieve it on a Magento store without moving to a headless architecture.

After launch, ongoing Magento performance optimisation keeps the store healthy as Magento versions, extensions, and Hyvä itself are updated over time. Our guide on how to optimise a Hyvä website covers the key post-implementation steps worth building into your maintenance routine.

For stores that want to go further after the Hyvä migration, Magento 2 SEO strategies and deeper Magento 2 performance optimisation work build on the improved frontend foundation.

The timeline depends almost entirely on store complexity.

A store with a standard Luma theme, modest extension stack (10–15 extensions), and limited custom design work can be implemented in four to seven weeks.

A store with significant bespoke design, a large extension stack (20+ modules), complex B2B workflows, or custom checkout functionality typically takes three to five months.

These estimates assume a properly scoped project with a staging environment and thorough testing. Rushed implementations that skip the audit and testing stages may complete faster on paper but create problems post-launch that end up taking longer to resolve.

KiwiCommerce is a Hyvä Bronze Partner, meaning the team’s Hyvä delivery capability has been verified by the Hyvä team directly, not self-declared. The 30+ certified developers have implemented Hyvä on Magento Open Source and Adobe Commerce stores across a range of sectors and complexity levels.

Every Hyvä project starts with a full compatibility audit before scope or timeline is agreed. Nothing goes to staging without a clear picture of what the extension stack requires. Every build uses a child theme, protecting the implementation from future Hyvä updates. Every go-live is followed by active post-launch monitoring.

For agencies and design studios looking to offer Hyvä development to their clients, our white label Hyvä development service provides certified delivery under your brand.

Whether you need a dedicated Hyvä developer for a single project or a full implementation team with ongoing Magento support and maintenance built in, the KiwiCommerce team can scope the right arrangement. Get in touch with our team to discuss your Hyvä implementation.

• Hyvä replaces Magento’s Luma frontend with a Tailwind CSS and Alpine.js stack, reducing typical page weight by around 6x and pushing Lighthouse scores above 90
• The core Hyvä theme became free and open source in November 2025, removing the previous per-store licence cost
• A proper Hyvä implementation on an existing Magento 2 store requires an extension compatibility audit before any development begins; this determines the real scope and timeline
• Custom Luma design work cannot be directly ported to Hyvä it must be rebuilt in Tailwind CSS in a child theme
• A straightforward store typically takes 4–7 weeks; a complex store with heavy customisation can take 3–5 months
• Hyvä does not change the Magento backend; orders, products, admin, and integrations all remain unchanged