By the Kiwop team · Digital Agency specialized in Software Development and Applied Artificial Intelligence · Published May 7, 2026 · Last updated: May 7, 2026
TL;DR — Magento headless makes sense in fewer cases than the industry sells. If your GMV is under €2M, your team has fewer than 3 devs or your catalog is relatively standard, you'll most likely waste money and valuable months. The real alternative for 80% of classic Magento stores is Hyvä Themes plus infrastructure optimization, or partial headless only for mobile apps or specific B2B portals.
For years we've been getting the same brief from clients running classic Magento: "We need to migrate to headless because that's what the big players do." The conversation usually follows the same script. The e-commerce manager comes back from a conference, has seen a spectacular demo of PWA Studio or Next.js with GraphQL, and has concluded that their slow website is the fault of monolithic architecture.
70% of the time, when we audit the real stack, the cause of the slowness is something else: misconfigured Varnish, uncompressed images, extensions loading 400KB of JavaScript in the critical rendering path, or simply hosting inadequate for the traffic. Headless doesn't fix any of those problems. It makes them more expensive.
This article isn't anti-headless. It's anti-headless-as-a-trend. There are cases where a decoupled architecture for Magento or Adobe Commerce has a clear business case and demonstrable ROI. But those cases are a minority. What we're going to do here is give you the real criteria for knowing whether you're in that minority or in the other 80%.
What Magento Headless Is (and What It's NOT)
Before the scenarios, we need to align on terminology. The term "headless" is used so broadly in the Magento ecosystem that it has lost precision.
Headless Is Not the Same as Pure React
In the most common meaning, Magento headless means separating the frontend from the backend: the commerce engine (catalog, pricing, inventory, checkout, ERP) lives in Magento/Adobe Commerce, while the user interface is built in an independent JavaScript framework — Next.js, Nuxt.js, Remix or similar — that consumes data through the Adobe Commerce GraphQL API. The frontend is deployed independently, has its own build pipeline and its own CDN cache layer.
The result is a two-repository architecture, two potential teams, two monitoring surfaces and two update systems that must remain synchronized with every API contract change.
PWA Studio: Adobe's Official Bet
Adobe launched PWA Studio in 2018 as the official framework for building PWA frontends on top of Magento 2. It's built on React, uses Peregrine (logic hooks) and Venia UI (interface components). In theory, it's the canonical route for headless with Magento.
In practice, adoption has been moderate. The public repository on GitHub records version 14.5.0 as the most recent (published in February 2026), with 2,700 commits on the develop branch and 5 open pull requests. It's an active project, but the Magento marketplace extension ecosystem is not ready for PWA Studio: the vast majority of third-party extensions were designed for the Luma frontend and don't offer a native PWA equivalent. Migrating to PWA Studio means rewriting or replacing every extension you use.
Custom Frontend (Next.js, Nuxt) with GraphQL
The alternative is to bypass PWA Studio and build the frontend directly on a modern framework using the Adobe Commerce GraphQL API. More architectural flexibility, less Adobe opinion — and more of your own work. The projects we've audited with this architecture dedicate between 30% and 40% of development time to reinventing functionality that Magento already had solved: catalog pagination, facet filters, shipping address management, complex promotions. Not because it's hard, but because it has to be built from scratch on the frontend.
Why the Line Between "Headless" and "Composable Commerce" Has Blurred
The term composable commerce adds another layer of confusion. Composable means that every stack capability (search, payments, CMS, PIM, checkout) is an independent and replaceable service. Headless is a precondition for being composable, but headless doesn't imply composable. A Magento with a Next.js frontend can be perfectly headless but remain monolithic on the backend if it still depends on Magento for search, checkout, content management and pricing rules simultaneously.
This distinction matters because the cost of a truly composable architecture is substantially greater than "headless with Next.js." If someone is selling you "composable" at the price of "simple headless," there's a misunderstanding somewhere in the conversation.
The 5 Scenarios Where You Should NOT Migrate
The industry talks a lot about when headless is the solution. We, after dozens of audits and several migration projects, are going to tell you when it isn't.
1. Annual GMV Below €2M
The real cost of a headless migration for a mid-market Magento — discovery, architecture, frontend development, GraphQL hardening, migration and cutover — ranges between €105,000 and €210,000 for a well-executed project. We break down the details below.
With a GMV of €2M annually and a typical e-commerce operating margin of 10–20%, your annual profit is in the range of €200,000–€400,000. Dedicating between 25% and 100% of a full year's profit to an architectural migration that generates no direct revenue is a bet that rarely pays back within the timeframe shareholders or partners accept.
The math doesn't lie: for the investment to make sense, the impact on conversion or operational efficiency must be measurable and foreseeable. With a GMV below €2M, those numbers almost never add up. Headless doesn't double your sales. A better user experience can move conversion, but there are much cheaper ways to achieve it.
2. Technical Team of 1–2 Developers
Headless doesn't just multiply the initial project cost: it multiplies the permanent operational cost.
A classic Magento with a Luma or Hyvä frontend requires a developer who understands PHP/Magento, server administration and CSS. A headless Magento simultaneously requires: a backend developer who maintains the Magento core and resolves issues with the GraphQL API; a frontend developer who maintains the JavaScript framework, the build pipeline and the CDN cache layer; and ideally a DevOps profile who manages two deployment systems, two staging environments, separate frontend and backend monitoring, and security updates for two parallel stacks.
With a team of 1 or 2 developers, one of those three roles is uncovered by default. And the first one neglected — usually the backend because the frontend is the "visible" part — accumulates technical debt, version gaps in Magento and, eventually, security vulnerabilities.
A system nobody can maintain properly is not a modern architecture. It's a problem waiting to explode.
3. Simple Catalog Without Complex Business Customization
If your Magento has a relatively standard catalog — simple or configurable products, few complex pricing rules, no advanced B2B logic — the gap between "what already works in Luma" and "what needs to be rewritten in the new frontend" is enormous.
The Magento extension ecosystem contains thousands of tested solutions for search, catalog filters, reviews, comparison tools, wishlists, loyalty programs, multi-currency and dozens of features that shoppers expect. When you migrate to headless, you lose native access to that ecosystem. Every extension needs to offer a GraphQL endpoint or an API alternative — and most don't, because 90% of Magento installations are still Luma.
According to BuiltWith data, Magento has more than 89,000 active sites. The overwhelming majority uses the classic stack. Extension providers develop for that stack first. If you go headless, you become the niche client who needs custom work for every integration.
4. Strong Organic SEO You Can't Risk
This is the scenario we most underestimated when we started in the sector.
Poorly executed headless migrations are devastating for SEO. The reason isn't that headless is inherently bad for SEO — a well-configured Next.js with server-side rendering can be perfectly indexable — but that execution is extremely sensitive to details: correct 301 redirects, metadata preservation, canonicals, hreflang, structured data, LCP image preload, category page caching, pagination with correct rel=canonical.
We've seen e-commerce stores with established organic traffic lose between 30% and 40% during the first 3–6 months of a headless migration where SEO complexity was underestimated. Recovering that takes additional months. The cost in lost sales during that period typically exceeds the migration project cost itself.
If your organic channel generates more than 30% of your sales, you need an SEO migration plan as detailed and well-budgeted as the technical migration plan. If that plan isn't in the budget, the project shouldn't start.
5. You Don't Have 6+ Months or €100K+ of Runway
The honest timeline for a headless migration for a mid-sized Magento is as follows: discovery and architecture definition (1 month), component system design and API contract (1 month), frontend development (3–4 months), thorough QA and performance optimization (1 month), data migration, redirects and cutover (1 month). Total: between 7 and 9 months from kick-off to the day the new frontend is in production and the old one is deactivated.
During those months, the classic Magento remains in production, receiving orders and requiring maintenance. Two systems in parallel, two teams, two competing priorities. If there's a major sales campaign mid-project, the new frontend gets paused. If there's a security vulnerability in Magento, both systems need patching. If the project overruns (and it will), the runway runs out before cutover.
Without at least 6 months of operational runway and a budget of €100K+ reserved specifically for the migration — not for "IT in general" — the probability that the project completes successfully is low. Projects that start with tight runway invariably end with a half-baked headless frontend that permanently coexists with the classic Magento, paying the maintenance cost of both without the benefit of either.
Real Costs (Numbers, Not Agency Estimates)
The market tends to present headless migration costs in ranges so wide they're useless for making decisions. We're going to be concrete with the data we handle in real projects.
Breakdown of a Real Migration (Anonymized Kiwop Client)
B2C client with €3.8M annual GMV, catalog of 2,400 configurable products, 15 active extensions, strong organic traffic (40% of revenue). Decided architecture: Next.js 14 with App Router + Adobe Commerce GraphQL API + Algolia for search. The headless alternative evaluated and discarded was PWA Studio due to extension costs.
The project lasted 8 months. LCP improvement went from 4.1s to 1.8s. Conversion improved 14% in the 3 months following cutover. Organic SEO lost 18% of impressions in month 1, recovered the baseline in month 4 and exceeded the baseline in month 7. For this client, with their GMV and technical team of 5 people, the investment made sense. What we paid for wasn't headless: it was post-migration SEO recovery.
Hidden Cost: Permanent Dual Maintenance
What the initial budget doesn't capture is the permanent cost of operating two systems.
A well-operated classic Magento costs between €500 and €1,500 per month in maintenance engineering (security updates, extension patches, performance optimizations, monitoring). A headless Magento adds to that cost the frontend maintenance: Node.js and React dependencies, framework updates, CDN management, hydration error monitoring, Core Web Vitals regression alerts on every deploy.
The total operational cost of a mid-market headless Magento rarely drops below €2,500–4,000 per month when you include real engineering. Compared to €1,000–1,500 for a well-optimized classic Magento. The difference is €18,000–30,000 in additional annual costs that come out of business margins indefinitely.
The Cost of Over-Engineering: Two Repos, Two Pipelines, Two Monitoring Systems
Every time a team developer introduces a change to the frontend, they need to verify the GraphQL contract hasn't changed. Every time Magento updates its API — which happens with every minor release — you need to audit whether the frontend breaks. Every marketing campaign that introduces a new discount type or special pricing rule requires coordinating changes in backend and frontend separately.
E-commerce stores have very stressful calendars: Black Friday, Christmas, seasonal clearances. A headless architecture is an architecture that requires double coordination on every campaign sprint. If your team is already struggling with one system, you don't solve it by adding another.
When It DOES Make Sense to Go Headless
We've given the five scenarios for when not to migrate. To be fair, there are cases where headless is the right answer.
Real multi-channel with a single backend. If you need to serve the same catalog logic, pricing and inventory to a website, an iOS app, an Android app, a physical store kiosk and a B2B portal for distributors, a Magento backend with GraphQL API as a single data source makes clear architectural sense. One frontend per channel, one backend feeding them all. Maintenance costs are distributed across multiple surfaces that previously required separate backends.
Critical performance that the classic stack cannot resolve. If your Magento has an LCP consistently above 3 seconds and you've exhausted Varnish, Redis, image compression and blocking JavaScript elimination optimizations, and if your business has evidence that every tenth of a second of LCP measurably impacts conversion, investing in headless may be justified. But you must first have exhausted the alternatives. Most Magento stores with poor LCP we've brought below 2 seconds without touching the architecture.
GMV above €5M with a technical team of more than 5 developers. Diluting investment and maintenance costs over a larger volume changes the math. A team of 5+ devs can organize specialized roles without gaps. A GMV of €5M+ generates the margin to absorb the additional operational cost and justify the performance and flexibility upside.
Real composable, not Magento as a disguised monolith. If the strategy is to replace Magento as the search system (with Algolia or Elastic), as the content CMS (with Contentful or Sanity), as the payments system (with Stripe or Adyen directly) and as checkout (with a specialized headless checkout), leaving Magento only as OMS and pricing engine, then headless is the logical consequence of that composable strategy. But that strategy has its own cost and complexity — far beyond a frontend project.
The Alternatives That Work for 80% of Classic Magento Stores
If you're not in the "YES" scenarios, these are the alternatives with real ROI.
Alternative 1: Hyvä Themes — The "Light Headless" That Isn't
Hyvä Themes is the most pragmatic alternative and, in our experience, the most underused. It's a frontend theme for Magento 2 that replaces the Luma stack (KnockoutJS + RequireJS + jQuery, which loads more than 200 JS/CSS resources and exceeds 1.5MB of assets) with a modern stack based on Tailwind CSS and Alpine.js, which loads just two resources with a total weight of approximately 0.2MB.
The result in Core Web Vitals is significant. According to Hyvä's benchmark documentation, the theme is designed to pass Core Web Vitals from the first deploy in standard configurations, with JavaScript weight reductions of over 85% compared to Luma. In production, more than 7,000 stores already use it, including brands like Audio-Technica and Nestlé.
What Hyvä is not: it's not headless. The frontend remains part of the Magento monolith, running in the same PHP process. You don't have a separate repository. You don't have a separate deploy pipeline. You don't need a React developer. What you have is a considerably faster and more maintainable frontend, with full access to the Magento extension ecosystem.
Cost and timeline: a Luma-to-Hyvä migration project for a standard mid-market Magento is in the range of €15,000–30,000 and completes in 4–8 weeks. Ten times cheaper than headless, without the operational complexities and with SEO intact.
Hyvä's only limitation is that it requires the third-party extensions you use to have Hyvä compatibility. The compatibility ecosystem has grown significantly in recent years, but it's still a necessary check before starting the project.
Alternative 2: Classic Magento Thoroughly Optimized
Before talking about architecture changes, do the work that most Magento stores haven't done correctly: infrastructure and rendering optimization.
The optimization stack that resolves 80% of performance problems in classic Magento:
- Varnish correctly configured for full-page caching, with granular tag-based purging. Without Varnish or with misconfigured Varnish, Magento cannot be fast.
- Redis for session and block caching. Magento has two internal caches in addition to the full-page cache; without Redis on both, TTFB suffers.
- Image optimization with ImageMagick, WebP or AVIF compression and correct lazy loading. Most Magento stores with poor LCP have uncompressed images or lack the
loading="lazy"attribute on images below the initial viewport. - Elimination of blocking JavaScript in the critical path. The average Magento extension adds between 20KB and 80KB of JavaScript that blocks rendering. A JS coverage audit in Chrome DevTools typically reveals between 60% and 80% unused code on first load.
- CDN with edge caching for static assets. Cloudflare on the free plan already resolves much of the problem for international visitors.
With this stack properly configured, it's common to bring Magento from a 4–5 second LCP down below 2 seconds without touching the application code. The cost: between €5,000 and €15,000 in engineering work, plus the monthly cost of the right server.
Alternative 3: Partial Headless Only for Mobile Apps or B2B Portals
If you have a specific use case where headless makes sense — a native mobile app, a purchasing portal for B2B distributors with their own pricing logic — you can implement headless exactly there, without migrating the main website.
The Magento backend exposes its GraphQL API to the mobile app or the B2B portal. The main website remains classic Magento (ideally with Hyvä) and doesn't introduce additional maintenance complexity. You get the benefit of headless where it actually adds value, without paying the cost in the part where the classic stack works well.
This pattern has a direct SEO advantage: the main website, which concentrates 90% of organic traffic, is not touched. The regression risk is minimal.
Alternative 4: Migrate to Shopify Plus (Yes, Seriously)
This suggestion makes many people in the Magento ecosystem uncomfortable, but it's the honest answer for a specific segment of clients: e-commerce stores with GMV between €500K and €2M, standard catalog without critical business customizations, and without an in-house technical team.
Shopify Plus has a monthly cost of between €2,300 and €4,000 depending on volume, but eliminates virtually all infrastructure maintenance costs, security updates, server management and accumulated technical debt. The Shopify app ecosystem covers most functionality that Magento extensions solve. Shopify's checkout converts better than any custom checkout by design.
The technical migration from Magento to Shopify has its own cost and complexity, especially in the catalog, order history and SEO areas. But if the alternative is spending €150K on a headless Magento for a €1M GMV business, Shopify may work out cheaper in total cost of ownership over 3 years.
Our recommendation: run a TCO (Total Cost of Ownership) analysis for 3 years before deciding between maintaining Magento, going headless or migrating platforms.
Decision Checklist: Headless Yes or No?
Before committing budget and months of work, run through these questions. They're the same ones we ask in our initial audits.
If you have 5 or more "against headless" indicators, the project needs to be reconsidered before starting. If you have 6 or more "for headless" indicators, the architecture conversation makes sense.
Real Case: When We Said NO to a Client (and How It Turned Out)
A B2B client in the industrial sector contacted us to migrate their Magento 2 to headless. GMV: €1.2M annually. Technical team: 1 internal developer with a Magento background. Stated reason for headless: "the website is slow and the competition has a PWA."
We conducted the audit before accepting the project — it's a practice we apply at Kiwop in every Magento development project involving an architecture change. The results:
- Average LCP: 4.8s. Main cause: Varnish disabled (it was installed but full-page caching had been broken for 8 months due to an unresolved extension conflict). Secondary cause: 14 extensions loading JS in the critical path without defer.
- CLS: 0.31. Cause: hero slider images without declared dimensions.
- The catalog had 340 products with standard price configurations. Zero custom B2B logic.
Our recommendation: migrate to Hyvä Themes, properly activate and configure Varnish, implement lazy loading on images and defer extension JavaScript. No headless.
Result: Core Web Vitals passing in 3 weeks. LCP: 1.6s. CLS: 0.02. Organic traffic unaffected. Total cost: €22,000 vs. the €135,000 budgeted for headless. The client's internal developer was able to maintain the system without additional training.
The difficult conversation was telling the client that the headless they wanted wasn't the solution. The easy conversation was showing them the results three weeks later.
Frequently Asked Questions
Is classic Magento obsolete?
No. Adobe continues to publish Adobe Commerce and Magento Open Source versions with active support. Version 2.4.x is the current branch, with regular security and compatibility updates. The extension ecosystem remains active. What is obsolete is the Luma frontend in terms of performance — but that's resolved with Hyvä Themes, not necessarily with headless.
Will Adobe force headless in the future?
Adobe has positioned headless as the strategic direction for Adobe Commerce, especially for enterprise clients. But "strategic direction" doesn't mean abandoning the classic stack in the short term. PWA Studio continues to receive updates (v14.5.0 in February 2026). Adobe maintains official support for monolithic installations. For most merchants, the pressure toward headless will come from the market — not from Adobe deactivating the classic stack.
Is Hyvä Themes production-ready?
Yes. With more than 7,000 stores in production, including major brand implementations, Hyvä is a mature project. The ecosystem of compatible extensions has grown significantly. Before any Hyvä project, you need to verify compatibility with the specific extensions you use — the official Hyvä website and compatibility marketplace are the reference.
Can I do "partial headless"?
Yes, and it's frequently the best solution. Keeping the web frontend on classic Magento (or Hyvä) and building only the mobile app or B2B portal against the GraphQL API is a valid strategy that gives you the benefit of headless where it truly adds value without the operational costs of migrating the main website.
How long does a well-done headless migration take?
For a mid-market Magento (€1M–5M GMV, 1,000–10,000 SKUs, 10–20 active extensions), the realistic timeline is 7–9 months from kick-off to production cutover. Projects that promise completion in 3–4 months either have a very limited scope or are going to have problems in QA and migration. The long timeline isn't a project defect: it's the consequence of doing things properly.
What if I want to migrate from Magento to Shopify directly?
It's a legitimate option for a specific segment. The technical migration includes catalog, order history, customer accounts and SEO redirects — there are specialized tools for this. The migration cost is usually lower than a headless Magento project. The limitation is customization: Shopify has limits on checkout extensibility and very specific business logic. If your business has complex B2B pricing rules, highly customized bundles or proprietary ERP integrations, Shopify may fall short. If not, it may be the most sensible option.
If you're evaluating a platform change, it's also worth considering PrestaShop for businesses in the €200K–1M GMV range, where TCO can be even lower than Shopify Plus with a more flexible stack.
Conclusion: Trends Should Not Decide Your Architecture
Failed Magento headless migrations have one thing in common: they started with the solution in mind before understanding the problem. Someone saw a demo, read a success story from a €50M e-commerce and assumed the same architecture scaled downward. It doesn't.
The right architecture is the one that solves your specific business problem at the cost you can absorb with the team you have. For most classic Magento stores, that means Hyvä Themes plus infrastructure optimization, not an 8-month, €150K project that permanently doubles operational complexity.
Headless makes sense when: you have real multi-channel, GMV >€5M, team >5 devs, you've exhausted classic optimizations and you have the runway to do it properly.
It doesn't make sense when: any of those conditions is missing.
At Kiwop — Digital Agency specialized in Software Development and Applied Artificial Intelligence for global clients in Europe and the US — we conduct technical audits before any architectural decision in e-commerce. If your Magento has performance problems, before assuming the solution is headless, let us analyze it. The right diagnosis costs a fraction of the wrong project.
Check out our services for Magento development, composable commerce, PWA development and software development — or write to us directly and we'll evaluate together whether headless is the right choice for your case.
