Migrating Magento to Hyvä: The Process

Moving a live Magento store to Hyvä is not a rip and replace. Done right, it is a controlled swap of the frontend layer while the catalog, orders and customers stay exactly where they are. Done wrong, it takes the store down for a weekend and scrambles your SEO. Here is what the process actually looks like, what breaks, how long it takes, and what the performance numbers really mean.

What migrating to Hyvä actually means

Hyvä replaces the theme, the part of Magento that renders every page. Knockout, RequireJS, jQuery and LESS go out. Alpine.js and Tailwind come in. Your Magento backend, your data, your integrations and your admin all stay in place.

That is the whole reason the move is safer than a full replatform. You are not changing where your business runs, only how fast it draws the screen. Your order history does not move. Your ERP connector does not care. Your customers keep their accounts and their passwords.

One thing that changed recently and is worth knowing before you budget: since November 2025 the Hyvä theme itself is free and open source, licensed under OSL-3.0 and AFL-3.0. A licence line that used to sit in every proposal is gone. Hyvä Checkout, Hyvä UI and the Commerce and Enterprise tiers remain commercial, and Checkout in particular deserves its own line in the budget.

The staging-first sequence

A clean migration never happens on the live store. We build the Hyvä storefront on a staging copy, keep the old theme serving customers the entire time, and cut over only once. In practice the work falls into seven stages.

Discovery and audit. Inventory every module, separate backend from frontend, count the custom templates, and check both Hyvä trackers. This produces the scope. Skipping it is why projects double in length.
Environment and build pipeline. Node on the build machines, a Tailwind compile stage in deployment, Magento’s own JavaScript and CSS minification and bundling switched off, and the legacy Magento captcha disabled. Small, unglamorous, and blocking if left late.
Theme build. The longest stage. Templates and custom blocks are ported section by section onto the Tailwind base, not copied across.
Extension compatibility. Install the compatibility modules that exist, port the ones that do not, and decide what gets dropped.
Content migration. CMS pages, blocks, widgets and Page Builder content. Routinely underestimated, see below.
QA and performance validation. Feature-for-feature against the live store, then real measurements, not a single score.
Cutover. The customer-facing downtime is measured in minutes, in a low-traffic window, not across a weekend.

How long it actually takes

Hyvä’s own published position is that projects run from six weeks up to eight months. That is a wide range and it is honest, but it is not useful for planning on its own.

Their public case study index is more informative. Of roughly 130 case studies, only eleven state a duration at all. The ones that do cluster tightly: eight weeks for a Luma to Hyvä move with zero downtime, two months for a single-brand retailer, two and a half to three months for larger European stores, three months for a multi-brand multi-language B2B build, four months for a perfume chain. The longest stated duration on the whole index is twenty weeks, and that project carried four international store views plus a full rebrand.

The only audited effort figure published anywhere is Hyvä’s own: 277 hours on a twelve-week build, of which 242 were development and 193 of those came from a single frontend developer. Treat that as the shape of a clean project, not a quote.

What actually moves the number, in the order it usually bites:

The number of frontend extensions. The single most cited driver. Backend-only extensions cost nothing. Storefront ones each need a compatibility module found, installed, or written.
The volume of custom Luma code. Every overridden template, every RequireJS module, every Knockout component is an hour or several. This is the line that separates a six-week project from a sixteen-week one.
B2B. Company accounts, requisition lists, quotes and negotiable pricing are frontend-heavy and generally need real development rather than a module swap.
Store views and languages. Rarely quantified by anyone, and consistently underestimated. The longest published project on Hyvä’s index is a four-store-view build.
Checkout. A separate project with a separate licence. Scope it separately or it will eat the timeline.
A Magento version upgrade. If you are on 2.3.x you are doing two projects, and every published source adds two to four weeks for it.

One honest gap: nobody publishes a credible figure for Page Builder content migration effort. We have looked. If a proposal treats a large Page Builder catalogue as a rounding error, that is a question worth asking, because rebuilding content is the stage that most often runs long.

What breaks, and how we handle it

Custom theme code. It has to be rebuilt on Hyvä’s Tailwind base rather than copied over. There is no shortcut and no converter.

Extensions that inject frontend markup. These need a Hyvä-compatible version or a compatibility module. It is worth auditing before you commit, and we cover it in detail in our guide to Hyvä extension compatibility.

Checkout. Third-party one-page checkout extensions do not port. They are Knockout rewrites of Magento’s checkout, and Hyvä Checkout is a different checkout entirely. Payment gateways survive because the integration is server side, but every payment form, iframe and redirect has to be re-integrated.

Anything hard-coded into the old theme. Tracking scripts, third-party widgets, A/B test snippets, consent banners. These have to be re-added deliberately or they disappear silently and nobody notices until a monthly report looks wrong.

Dynamically generated CSS classes. Tailwind scans source files for class names and cannot evaluate PHP. A class assembled at runtime produces no CSS at all, and the failure is silent: the page renders, the style is just missing. Same problem for Tailwind classes typed into CMS content, which is why Hyvä ships a browser-side compiler for that case.

Extensions that sniff for Hyvä the old way. Some third-party modules detect Hyvä by walking up the theme chain looking for a Hyva prefix. Newer Hyvä versions generate layout resets differently, so that check silently fails. Those modules need to use Hyvä’s own theme service instead. It is an obscure failure mode and a genuinely confusing one to debug.

The partial migration nobody offers you

Hyvä publishes a theme fallback module that lets specific routes keep rendering in Luma. That makes a staged migration possible, and it is a legitimate strategy. One published case study moved only category and product pages to Hyvä and left the rest, taking the category page from 85 to 99 on PageSpeed.

The trade-off is documented by Hyvä themselves. On a fallback route the Hyvä theme is not active at all. Neither Tailwind nor Alpine loads, RequireJS and the full Luma dependency chain load instead, and styling for those pages has to be built the old way. You keep the page working, you lose the performance win on that route, and you maintain two frontends until you finish.

Used deliberately on a handful of routes with a date to remove them, this is good engineering. Used to avoid the extension audit, it is how a Hyvä store ends up not being fast.

Protecting your rankings through the move

A rebuild is where stores quietly lose SEO. URLs, titles, meta descriptions, structured data and internal links all have to carry over unchanged, and every redirect has to be tested before cutover, not after.

Structured data deserves particular attention because it is invisible until it is gone. Product markup, breadcrumbs, review and rating markup, shipping and return policy markup: all of it lives in templates, and templates are exactly what gets rewritten. A store that loses its Product markup in a migration loses rich results in Search and can lose its Merchant Center automatic item updates at the same time, because those read the same on-page markup.

Get this right and Google sees a faster version of the same store, which it rewards. Get it wrong and you spend three months clawing rankings back. We treat the URL and metadata map as a release checklist item, not an afterthought.

The uncomfortable truth about the numbers

Hyvä is a frontend fix. It cannot repair a slow backend, and the published evidence is clearer about this than most agency marketing.

In an article on Hyvä’s own site, a real-user monitoring specialist states that about half of the websites using Hyvä still struggle with Core Web Vitals. One of Hyvä’s own case studies describes an eight-week Luma to Hyvä migration that moved mobile PageSpeed from 12 to 53. Not 100. That is a real project, published by Hyvä, and it is the most useful number on the whole index precisely because it is unimpressive.

Our own Vitacom rescue makes the same point from the other direction. Vitacom came to us already on Magento 2 with Hyvä, and still scored PageSpeed 12 with server response climbing toward 16 seconds. Same catalog, same Magento, same Hyvä. What changed was the work underneath: roughly 180 modules removed, the custom code rebuilt, the server right-sized. PageSpeed went from 12 to 100, server response from 15,814ms to 12ms, hardware from 64 cores and 256GB of RAM to 8 cores and 32GB. Read the full Vitacom case study.

So if your server response time is measured in seconds, migrating the theme will make your store look better and will not make it fast. Find out which problem you have before you buy the wrong fix. And if the concern is that Hyvä will flatten your brand, that is a separate question with a better answer than you would expect: we wrote about design freedom on Hyvä separately.

Book a free strategy call

If you are weighing a move to Hyvä, we will map the process to your store: what carries over, what needs rebuilding, whether your bottleneck is actually the frontend, and a realistic timeline. Book a free strategy call and we will walk you through it.