Door het Kiwop-team · Digitaal Agentschap gespecialiseerd in Softwareontwikkeling en toegepaste Kunstmatige Intelligentie · Gepubliceerd op 7 mei 2026 · Laatst bijgewerkt: 7 mei 2026
TL;DR — Magento headless heeft in minder gevallen zin dan de industrie verkoopt. Als je GMV <€2M is, je team minder dan 3 developers heeft of je catalogus relatief standaard is, verlies je hoogstwaarschijnlijk geld en waardevolle maanden. Het echte alternatief voor 80% van de klassieke Magento-shops is Hyvä Themes plus infrastructuuroptimalisatie, of gedeeltelijk headless alleen voor mobiele apps of specifieke B2B-portals.
We krijgen al jaren dezelfde opdracht van klanten met klassieke Magento: "We moeten naar headless migreren omdat dat is wat de groten doen." Het gesprek volgt doorgaans hetzelfde script. De e-commerce manager komt terug van een conferentie, heeft een spectaculaire demo van PWA Studio of Next.js met GraphQL gezien, en heeft geconcludeerd dat de trage website de schuld is van de monolithische architectuur.
In 70% van de gevallen, wanneer we de echte stack auditeren, ligt de oorzaak van de traagheid elders: slecht geconfigureerde Varnish, ongecomprimeerde afbeeldingen, extensies die 400KB JavaScript laden in het kritieke renderpad, of simpelweg een hosting die niet geschikt is voor het verkeer. Headless lost geen van die problemen op. Het maakt ze duurder.
Dit artikel is niet anti-headless. Het is anti-headless-uit-mode. Er zijn gevallen waarbij een ontkoppelde architectuur voor Magento of Adobe Commerce een duidelijke business case heeft en aantoonbare ROI. Maar die gevallen zijn in de minderheid. Wat we hier gaan doen is je de echte criteria geven om te weten of je in die minderheid zit of in de andere 80%.
Wat Magento headless is (en wat NIET)
Voordat we de scenario's bespreken, moeten we de terminologie afstemmen. De term "headless" wordt zo breed gebruikt in het Magento-ecosysteem dat het aan precisie heeft ingeboet.
Headless is niet gelijk aan puur React
In de meest gangbare betekenis houdt Magento headless in dat de frontend van de backend wordt losgekoppeld: de commerce-motor (catalogus, prijzen, voorraad, checkout, ERP) leeft in Magento/Adobe Commerce, terwijl de gebruikersinterface wordt gebouwd in een onafhankelijk JavaScript-framework — Next.js, Nuxt.js, Remix of vergelijkbaar — dat de data verbruikt via de GraphQL API van Adobe Commerce. De frontend wordt onafhankelijk gedeployd, heeft zijn eigen build-pipeline en zijn eigen cachinglaag.
Het resultaat is een architectuur van twee repositories, twee potentiële teams, twee bewakingsoppervlakken en twee updatesystemen die gesynchroniseerd moeten blijven bij elke API-contractwijziging.
PWA Studio: de officiële gok van Adobe
Adobe lanceerde PWA Studio in 2018 als het officiële framework voor het bouwen van PWA-frontends op Magento 2. Het is gebouwd op React, gebruikt Peregrine (logica-hooks) en Venia UI (interfacecomponenten). In theorie is het de canonieke route voor headless met Magento.
In de praktijk is de adoptie gematigd geweest. De publieke GitHub-repository vermeldt versie 14.5.0 als de meest recente (gepubliceerd in februari 2026), met 2.700 commits op de develop-branch en 5 open pull requests. Het is een actief project, maar het extensie-ecosysteem van de Magento-marketplace is niet klaar voor PWA Studio: de overgrote meerderheid van extensies van derden is ontworpen voor de Luma-frontend en biedt geen native PWA-equivalent. Migreren naar PWA Studio impliceert elke extensie die je gebruikt te herschrijven of te vervangen.
Custom frontend (Next.js, Nuxt) met GraphQL
Het alternatief is PWA Studio te omzeilen en de frontend rechtstreeks te bouwen op een modern framework via de GraphQL API van Adobe Commerce. Meer architecturale flexibiliteit, minder mening van Adobe — en meer eigen werk. Projecten die we met deze architectuur hebben geauditeerd, besteden tussen 30% en 40% van de ontwikkeltijd aan het opnieuw uitvinden van functionaliteit die Magento al had opgelost: paginering van de catalogus, facetfilters, beheer van verzendadressen, complexe promoties. Niet omdat het moeilijk is, maar omdat het in de frontend van nul moet worden gedaan.
Waarom de grens tussen "headless" en "composable commerce" is vervaagd
De term composable commerce voegt een extra verwarring toe. Composable betekent dat elke capaciteit van de stack (zoeken, betalingen, CMS, PIM, checkout) een onafhankelijke en vervangbare service is. Headless is een voorwaarde voor composable zijn, maar headless impliceert niet composable. Een Magento met Next.js frontend kan perfect headless zijn maar toch monolithisch in de backend als het tegelijkertijd van Magento afhankelijk blijft voor zoeken, checkout, inhoudsbeheer en prijsregels.
Dit onderscheid is belangrijk omdat de kosten van een echt composable architectuur substantieel hoger zijn dan "headless met Next.js". Als iemand je "composable" verkoopt tegen de prijs van "eenvoudige headless", is er ergens een misverstand in het gesprek.
De 5 scenario's waarbij je NIET moet migreren
De industrie praat veel over wanneer headless de oplossing is. Wij, na tientallen audits en meerdere migratieprojecten, gaan je vertellen wanneer dat niet zo is.
1. GMV onder €2M per jaar
De echte kosten van een headless-migratie voor een mid-market Magento — discovery, architectuur, frontend-ontwikkeling, GraphQL-hardening, migratie en cutover — liggen tussen €105.000 en €210.000 voor een goed uitgevoerd project. We splitsen de details hieronder uit.
Met een GMV van €2M per jaar en een typische operationele e-commerce marge van 10% tot 20% ligt je jaarlijkse winst in de range €200.000-€400.000. Tussen 25% en 100% van de winst van een heel jaar besteden aan een architecturale migratie die geen directe inkomsten genereert, is een gok die zelden wordt terugverdiend binnen het tijdsbestek dat aandeelhouders of partners accepteren.
De wiskunde liegt niet: voor de investering zinvol te maken, moet de impact op conversie of operationele efficiëntie meetbaar en voorspelbaar zijn. Met een GMV onder €2M kloppen die cijfers bijna nooit. Headless verdubbelt je verkopen niet. Een betere gebruikerservaring kan de conversie wel verbeteren, maar daar zijn veel goedkopere manieren voor.
2. Technisch team van 1-2 developers
Headless vermenigvuldigt niet alleen de kosten van het initiële project: het vermenigvuldigt de permanente operationele kosten.
Een klassieke Magento met Luma of Hyvä frontend vereist een developer die PHP/Magento begrijpt, serverbeheer en CSS. Een Magento headless vereist tegelijkertijd: een backend-developer die de Magento-core onderhoudt en problemen met de GraphQL API oplost; een frontend-developer die het JavaScript-framework, de build-pipeline en de CDN-cachinglaag onderhoudt; en idealiter een DevOps-profiel dat de twee deploysystemen beheert, de twee staging-omgevingen, de aparte bewaking van frontend en backend, en de beveiligingsupdates van twee parallelle stacks.
Met een team van 1 of 2 developers is een van die drie rollen standaard ongedekt. En de eerste die wordt verwaarloosd — doorgaans de backend omdat de frontend "zichtbaar" is — stapelt technische schuld op, versieverschillen in Magento en uiteindelijk beveiligingskwetsbaarheden.
Een systeem dat niemand goed kan onderhouden is geen moderne architectuur. Het is een tijdbom.
3. Eenvoudige catalogus zonder complexe bedrijfsaanpassing
Als je Magento een relatief standaard catalogus heeft — eenvoudige of configureerbare producten, weinig complexe prijsregels, geen geavanceerde B2B-logica — is de breuk tussen "wat al werkt in Luma" en "wat in de nieuwe frontend herschreven moet worden" enorm.
Het extensie-ecosysteem van Magento bevat duizenden geteste oplossingen voor zoeken, catalogusfilters, reviews, vergelijkingstools, verlanglijstjes, loyaliteitsprogramma's, multi-currency en tientallen functionaliteiten die kopers verwachten. Wanneer je naar headless migreert, verlies je native toegang tot dat ecosysteem. Elke extensie moet een GraphQL-endpoint of een API-alternatief aanbieden — en de meeste doen dat niet, omdat 90% van de Magento-installaties nog steeds Luma zijn.
Volgens gegevens van BuiltWith heeft Magento meer dan 89.000 actieve sites. De overgrote meerderheid gebruikt de klassieke stack. Extensieproviders ontwikkelen eerst voor die stack. Als je naar headless gaat, word je de nicheklant die voor elke integratie maatwerk nodig heeft.
4. Sterk organisch SEO-verkeer dat je niet kunt riskeren
Dit is het scenario dat we het meest onderschatten toen we met de sector begonnen.
Slecht uitgevoerde headless-migraties zijn verwoestend voor SEO. De reden is niet dat headless inherent slecht is voor SEO — een goed geconfigureerde Next.js met server-side rendering kan perfect indexeerbaar zijn — maar de uitvoering is extreem gevoelig voor details: correcte 301-redirects, behoud van metadata, canonicals, hreflang, gestructureerde data, preloaden van LCP-afbeeldingen, caching van categoriepagina's, paginering met correcte rel=canonical.
We hebben e-commerce sites met geconsolideerd organisch verkeer gezien die in de eerste 3-6 maanden van een headless-migratie 30% tot 40% verloren waar de SEO-complexiteit werd onderschat. Dat terugkrijgen kost extra maanden. De kosten in gederfde verkopen tijdens die periode overschrijden doorgaans de kosten van het migratieproject zelf.
Als je organisch kanaal meer dan 30% van je verkopen genereert, heb je een SEO-migratieplan nodig dat net zo gedetailleerd en goed begroot is als het technische migratieplan. Als dat plan niet in het budget zit, mag het project niet beginnen.
5. Je hebt geen 6+ maanden en geen €100K+ runway
De eerlijke tijdlijn van een headless-migratie voor een mid-size Magento is als volgt: discovery en architectuurdefinitie (1 maand), ontwerp van componentsysteem en API-contract (1 maand), frontend-ontwikkeling (3-4 maanden), uitgebreide QA en prestatieoptimalisatie (1 maand), datamigratìe, redirects en cutover (1 maand). Totaal: 7 tot 9 maanden van kick-off tot de dag waarop de nieuwe frontend in productie is en de oude is uitgeschakeld.
Tijdens die maanden draait de klassieke Magento nog steeds in productie, ontvangt bestellingen en vereist onderhoud. Twee parallelle systemen, twee teams, twee concurrerende prioriteiten. Als er midden in het project een belangrijke verkoopscampagne is, wordt de nieuwe frontend gepauzeerd. Als er een beveiligingskwetsbaarheid in Magento is, hebben beide systemen een patch nodig. Als het project uitloopt (en dat zal het), raakt de runway uitgeput vóór de cutover.
Zonder minimaal 6 maanden operationele marge en een budget van €100K+ specifiek gereserveerd voor de migratie — niet voor "IT in het algemeen" — is de kans op succesvolle afronding klein. Projecten die starten met een krap budget eindigen altijd met een half-klare headless frontend die permanent naast de klassieke Magento bestaat, waarbij de onderhoudskosten van beide worden betaald zonder de voordelen van een van beide.
Echte kosten (cijfers, geen agencyschattingen)
De markt neigt de kosten van headless-migratie te presenteren in ranges zo breed dat ze nutteloos zijn voor beslissingen. We zijn concreet met de gegevens die we in echte projecten hanteren.
Uitsplitsing van een echte migratie (geanonimiseerde Kiwop-klant)
B2C-klant met €3,8M GMV per jaar, catalogus van 2.400 configureerbare producten, 15 actieve extensies, sterk organisch verkeer (40% van de omzet). Gekozen architectuur: Next.js 14 met App Router + Adobe Commerce GraphQL API + Algolia voor zoeken. Het geëvalueerde en verworpen headless-alternatief was PWA Studio vanwege de extensiekosten.
Het project duurde 8 maanden. De verbetering van de LCP was van 4,1s naar 1,8s. De conversie verbeterde met 14% in de 3 maanden na de cutover. Het organische SEO-verkeer verloor 18% impressies in maand 1, herstelde het basisniveau in maand 4 en overtrof de baseline in maand 7. Voor deze klant, met zijn GMV en technisch team van 5 personen, was de investering zinvol. Wat we betaalden was niet de headless: het was het SEO-herstel na de migratie.
Verborgen kosten: permanent dubbel onderhoud
Wat het initiële budget niet omvat zijn de permanente kosten van het exploiteren van twee systemen.
Een goed geëxploiteerde klassieke Magento kost tussen €500 en €1.500 per maand aan onderhoudstechniek (beveiligingsupdates, extensiepatches, prestatieoptimalisaties, monitoring). Een Magento headless voegt daar de onderhoudskosten van de frontend aan toe: Node.js en React-afhankelijkheden, framework-updates, CDN-beheer, monitoring van hydratiefouten, regressiewaarschuwingen voor Core Web Vitals bij elke deploy.
De totale operationele kosten van een mid-market Magento headless zakken zelden onder €2.500-4.000 per maand wanneer je echte engineering meeneemt. Tegenover de €1.000-1.500 van een goed geoptimaliseerde klassieke Magento. Het verschil is €18.000-30.000 extra per jaar dat voor onbepaalde tijd uit de bedrijfsmarge komt.
De kosten van over-engineering: twee repositories, twee pipelines, twee bewakingssystemen
Elke keer dat een teamdeveloper een wijziging in de frontend aanbrengt, moet hij verifiëren dat het GraphQL-contract niet is gewijzigd. Elke keer dat Magento zijn API bijwerkt — iets wat bij elke minor release kan gebeuren — moet worden gecontroleerd of de frontend breekt. Elke marketingcampagne die een nieuw type korting of een speciale prijsregel introduceert, vereist het apart coördineren van wijzigingen in backend en frontend.
E-commerce sites hebben zeer stressvolle kalenders: Black Friday, kerst, seizoensliquidaties. Een headless-architectuur is een architectuur die dubbele coördinatie vereist bij elke campagnesprint. Als je team al moeite heeft met één systeem, los je dat niet op door er nog één aan toe te voegen.
Wanneer migreren naar headless WEL zinvol is
We hebben de vijf scenario's gegeven waarbij je niet migreert. Om eerlijk te zijn: er zijn gevallen waar headless het juiste antwoord is.
Echt multi-channel met een enkele backend. Als je dezelfde catalogus-, prijs- en voorraadlogica moet bedienen aan een website, een iOS-app, een Android-app, een kiosk in een fysieke winkel en een B2B-portal voor distributeurs, heeft een Magento-backend met GraphQL API als enige databron een duidelijke architecturale logica. Een frontend per kanaal, een backend die ze allemaal voedt. De onderhoudskosten worden verdeeld over meerdere oppervlakken waarvoor voorheen aparte backends nodig waren.
Kritieke prestaties die de klassieke stack niet kan oplossen. Als je Magento consistent een LCP van meer dan 3 seconden heeft en je de optimalisaties van Varnish, Redis, afbeeldingscompressie en eliminatie van blokkerend JavaScript hebt uitgeput, en als je bedrijf het bewijs heeft dat elke tiende seconde LCP meetbaar impact heeft op de conversie, kan de investering in headless gerechtvaardigd zijn. Maar eerst moeten de alternatieven zijn uitgeput. De meeste Magento's met slechte LCP hebben we onder de 2 seconden gebracht zonder de architectuur aan te raken.
GMV boven €5M met een technisch team van meer dan 5 developers. De verdunning van de investerings- en onderhoudskosten over een groter volume verandert de wiskunde. Een team van 5+ devs kan gespecialiseerde rollen organiseren zonder gaten te laten. Een GMV van €5M+ genereert de marge om de extra operationele kosten op te vangen en de upside van prestaties en flexibiliteit te rechtvaardigen.
Echt composable, niet Magento als vermomde monoliet. Als de strategie is Magento te vervangen als zoekmachine (door Algolia of Elastic), als CMS (door Contentful of Sanity), als betaalsysteem (door Stripe of Adyen direct) en als checkout (door een gespecialiseerde headless checkout), waardoor Magento alleen overblijft als OMS en prijsmotor, dan is headless de logische consequentie van die composable strategie. Maar die strategie heeft zijn eigen kosten en complexiteit — ver voorbij een frontend-project.
De alternatieven die werken voor 80% van de klassieke Magento's
Als je niet in de "JA"-scenario's zit, zijn dit de alternatieven met echte ROI.
Alternatief 1: Hyvä Themes — de "lichte headless" die het niet is
Hyvä Themes is het meest pragmatische alternatief en, in onze ervaring, het meest onderbenut. Het is een frontend-thema voor Magento 2 dat de Luma-stack (KnockoutJS + RequireJS + jQuery, die meer dan 200 JS/CSS-resources laadt en meer dan 1,5MB aan assets overschrijdt) vervangt door een moderne stack gebaseerd op Tailwind CSS en Alpine.js, die slechts twee resources laadt met een totaal gewicht van circa 0,2MB.
Het resultaat in Core Web Vitals is significant. Volgens de benchmark-documentatie van Hyvä is het thema ontworpen om Core Web Vitals te halen vanaf de eerste deploy in standaardconfiguraties, met JavaScript-gewichtreducties van meer dan 85% ten opzichte van Luma. In productie gebruiken meer dan 7.000 winkels het al, waaronder merken als Audio-Technica en Nestlé.
Wat Hyvä niet is: het is niet headless. De frontend blijft deel van de Magento-monoliet, draaiend in hetzelfde PHP-proces. Je hebt geen aparte repository. Je hebt geen aparte deploy-pipeline. Je hebt geen React-developer nodig. Wat je hebt is een aanzienlijk snellere en beter onderhoudbare frontend, met volledige toegang tot het extensie-ecosysteem van Magento.
Kosten en tijdlijn: een migratieproject van Luma naar Hyvä voor een standaard mid-market Magento zit in de range €15.000-30.000 en wordt in 4-8 weken afgerond. Tien keer goedkoper dan headless, zonder de operationele complexiteit en met SEO intact.
De enige beperking van Hyvä is dat de extensies van derden die je gebruikt compatibiliteit met Hyvä moeten hebben. Het compatibiliteitsecosysteem is de afgelopen jaren sterk gegroeid, maar het blijft een noodzakelijke verificatie voordat je het project start.
Alternatief 2: volledig geoptimaliseerde klassieke Magento
Voordat je het hebt over architectuurwijzigingen, doe het werk dat de meeste Magento's niet correct hebben gedaan: infrastructuur- en renderingoptimalisatie.
De optimalisatiestack die 80% van de prestatieproblemen in klassieke Magento oplost:
- Correct geconfigureerde Varnish voor full-page caching, met granulaire purge per tag. Zonder Varnish of met slecht geconfigureerde Varnish kan Magento niet snel zijn.
- Redis voor sessie- en blokken-cache. Magento heeft twee interne caches naast de full-page cache; zonder Redis in beide lijdt de TTFB.
- Afbeeldingsoptimalisatie met ImageMagick, WebP- of AVIF-compressie en correct lazy loading. De meeste Magento's met slechte LCP hebben ongecomprimeerde afbeeldingen of het
loading="lazy"attribuut ontbreekt bij afbeeldingen buiten het initiële viewport. - Eliminatie van blokkerend JavaScript in het kritieke pad. De gemiddelde Magento-extensie voegt tussen 20KB en 80KB JavaScript toe dat het renderen blokkeert. Een JS-dekkingsaudit in Chrome DevTools onthult doorgaans 60% tot 80% ongebruikte code bij de eerste lading.
- CDN met edge caching voor statische assets. Cloudflare in het gratis plan lost al een groot deel van het probleem op voor internationale bezoekers.
Met deze goed geconfigureerde stack is het gebruikelijk Magento van een LCP van 4-5 seconden naar minder dan 2 seconden te brengen zonder de applicatiecode aan te raken. De kosten: tussen €5.000 en €15.000 aan engineeringwerk, plus de maandelijkse kosten van de juiste server.
Alternatief 3: gedeeltelijk headless alleen voor mobiele apps of B2B-portals
Als je een specifieke use case hebt waarbij headless zinvol is — een native mobiele app, een inkoopportal voor B2B-distributeurs met eigen prijslogica — kun je headless precies daar implementeren zonder de hoofdwebsite te migreren.
De Magento-backend stelt zijn GraphQL API beschikbaar aan de mobiele app of het B2B-portal. De hoofdwebsite blijft klassieke Magento (idealiter met Hyvä) en introduceert geen extra onderhoudscomplexiteit. Je krijgt het voordeel van headless waar het echt waarde toevoegt, zonder de kosten te betalen waar de klassieke stack goed werkt.
Dit patroon heeft een direct SEO-voordeel: de hoofdwebsite, die 90% van het organische verkeer concentreert, wordt niet aangeraakt. Het regressierisico is minimaal.
Alternatief 4: migreren naar Shopify Plus (ja, serieus)
Deze suggestie is ongemakkelijk voor veel mensen in het Magento-ecosysteem, maar het is het eerlijke antwoord voor een specifiek segment klanten: e-commerce sites met een GMV van €500K tot €2M, een standaard catalogus zonder kritieke bedrijfsaanpassingen, en zonder een eigen technisch team.
Shopify Plus heeft maandelijkse kosten van €2.300 tot €4.000 afhankelijk van het volume, maar elimineert vrijwel alle onderhoudskosten van infrastructuur, beveiligingsupdates, serverbeheer en opgebouwde technische schuld. Het app-ecosysteem van Shopify dekt de meeste functionaliteiten die Magento-extensies oplossen. De checkout van Shopify converteert beter dan elke aangepaste checkout door design.
De technische migratie van Magento naar Shopify heeft zijn eigen kosten en complexiteit, met name in de catalogus, bestelhistorie en SEO. Maar als het alternatief is €150K uitgeven aan een headless Magento voor een bedrijf met €1M GMV, kan Shopify op het totale eigendomskosten over 3 jaar goedkoper uitkomen.
Onze aanbeveling: de TCO-analyse (Total Cost of Ownership) over 3 jaar doen voordat je beslist tussen Magento behouden, headless doen of van platform wisselen.
Beslisschecklist: headless ja of nee?
Voordat je budget en maanden werk vastlegt, doorloop je deze vragen. Het zijn dezelfde die we in onze initiële audits stellen.
Als je 5 of meer indicatoren "tegen headless" hebt, moet het project worden herzien voordat je begint. Als je 6 of meer indicatoren "voor headless" hebt, is het gesprek over architectuur zinvol.
Echte case: toen we een klant NEE zeiden (en hoe het afliep)
Een B2B-klant in de industriële sector nam contact met ons op om zijn Magento 2 naar headless te migreren. GMV: €1,2M per jaar. Technisch team: 1 interne developer met Magento-profiel. Opgegeven reden voor headless: "de website is traag en de concurrentie heeft PWA".
We deden de audit voordat we het project accepteerden — een praktijk die we bij Kiwop altijd toepassen bij Magento-ontwikkeling projecten met architectuurwijziging. De resultaten:
- Gemiddelde LCP: 4,8s. Hoofdoorzaak: Varnish uitgeschakeld (geïnstalleerd maar de full-page cache werkte al 8 maanden niet door een niet-opgelost extensieconflict). Secundaire oorzaak: 14 extensies die JS laden in het kritieke pad zonder defer.
- CLS: 0,31. Oorzaak: slider-afbeeldingen zonder gedeclareerde dimensies.
- De catalogus had 340 producten met standaard prijsconfiguraties. Nul aangepaste B2B-logica.
Onze aanbeveling: migreren naar Hyvä Themes, Varnish correct activeren en configureren, lazy loading implementeren voor afbeeldingen en het JavaScript van de extensies uitstellen. Geen headless.
Resultaat: Core Web Vitals slagen in 3 weken. LCP: 1,6s. CLS: 0,02. Organisch verkeer zonder impact. Totale kosten: €22.000 tegenover de €135.000 begroot voor de headless. De interne developer van hun team kon het systeem onderhouden zonder extra opleiding.
Het moeilijke gesprek was de klant vertellen dat de headless die hij wilde niet de oplossing was. Het gemakkelijke gesprek was hem drie weken later de resultaten laten zien.
Veelgestelde vragen
Is klassieke Magento verouderd?
Nee. Adobe blijft versies van Adobe Commerce en Magento Open Source met actieve ondersteuning publiceren. De 2.4.x-branch is de huidige met regelmatige beveiligings- en compatibiliteitsupdates. Het extensie-ecosysteem blijft actief. Wat wél verouderd is, is de Luma-frontend in termen van prestaties — maar dat los je op met Hyvä Themes, niet per se met headless.
Gaat Adobe headless verplicht stellen in de toekomst?
Adobe heeft headless gepositioneerd als de strategische richting van Adobe Commerce, met name voor enterprise-klanten. Maar "strategische richting" betekent geen opgave van de klassieke stack op korte termijn. PWA Studio blijft updates ontvangen (v14.5.0 in februari 2026). Adobe handhaaft officiële ondersteuning voor monolithische installaties. Voor de meeste merchants zal de druk naar headless van de markt komen — niet van Adobe die de klassieke stack uitschakelt.
Is Hyvä Themes production-ready?
Ja. Met meer dan 7.000 winkels in productie, inclusief implementaties van grote merken, is Hyvä een volwassen project. Het ecosysteem van compatibele extensies is significant gegroeid. Voordat je een Hyvä-project start, moet je de compatibiliteit van de specifieke extensies die je gebruikt verifiëren — de officiële website en de Hyvä-compatibiliteitsmarketplace zijn de referentie.
Kan ik "gedeeltelijk headless" doen?
Ja, en dat is vaak de beste oplossing. De web-frontend in klassieke Magento (of Hyvä) houden en alleen de mobiele app of het B2B-portal bouwen tegen de GraphQL API is een geldige strategie die je het voordeel van headless geeft waar het echte waarde toevoegt zonder de operationele kosten van het migreren van de hoofdwebsite.
Hoelang duurt een goed uitgevoerde headless-migratie?
Voor een mid-market Magento (€1M-5M GMV, 1.000-10.000 SKUs, 10-20 actieve extensies) is de realistische tijdlijn 7-9 maanden van kick-off tot cutover in productie. Projecten die beloven in 3-4 maanden af te ronden, hebben hetzij een zeer beperkt bereik, hetzij gaan problemen krijgen bij QA en migratie. De lange tijdlijn is geen gebrek van het project: het is de consequentie van dingen goed doen.
En als ik direct van Magento naar Shopify wil migreren?
Het is een legitieme optie voor een specifiek segment. De technische migratie omvat catalogus, bestelhistorie, klantaccounts en SEO-redirects — er zijn gespecialiseerde tools voor. De migratiekosten zijn doorgaans lager dan een headless project in Magento. De beperking is de aanpasbaarheid: Shopify heeft limieten in de uitbreidbaarheid van de checkout en in zeer specifieke bedrijfslogica. Als je bedrijf complexe B2B-prijsregels, sterk aangepaste bundles of eigen ERP-integraties heeft, kan Shopify tekortschieten. Als dat niet zo is, kan het de meest verstandige optie zijn.
Als je een platformwissel overweegt, is het ook de moeite waard PrestaShop te overwegen voor bedrijven in de GMV-range €200K-1M, waar de TCO zelfs lager kan zijn dan Shopify Plus met een flexibelere stack.
Conclusie: mode moet jouw architectuur niet bepalen
Mislukte Magento headless-migraties hebben één ding gemeen: ze begonnen met de oplossing in gedachten voordat het probleem werd begrepen. Iemand zag een demo, las een succesverhaal van een e-commerce site van €50M en nam aan dat dezelfde architectuur naar beneden schaalde. Dat doet het niet.
De juiste architectuur is de architectuur die het specifieke probleem van je bedrijf oplost tegen de kosten die je kunt absorberen met het team dat je hebt. Voor de meeste klassieke Magento's betekent dat Hyvä Themes plus infrastructuuroptimalisatie, niet een project van 8 maanden en €150K dat de permanente operationele complexiteit verdubbelt.
Headless heeft zin wanneer: je echt multi-channel hebt, GMV >€5M, team >5 devs, de klassieke optimalisaties hebt uitgeput en de runway hebt om het goed te doen.
Het heeft geen zin wanneer: een van die voorwaarden ontbreekt.
Bij Kiwop — Digitaal Agentschap gespecialiseerd in Softwareontwikkeling en toegepaste Kunstmatige Intelligentie voor wereldwijde klanten in Europa en de VS — doen we technische audits voorafgaand aan elke architectuurbeslissing in e-commerce. Als je Magento prestatieproblemen heeft, laat ons het analyseren voordat je ervan uitgaat dat de oplossing headless is. De juiste diagnose kost een fractie van het verkeerde project.
Bekijk onze services voor Magento-ontwikkeling, composable commerce, PWA-ontwikkeling en webontwikkeling — of schrijf ons direct en we beoordelen samen of headless de juiste optie is voor jouw geval.
