Magento 2.4.x upgrade als dienst: altijd vóór de deadline

Op 7 september 2026 kwam de patch voor StyleSmuggler, een kritieke Magento-kwetsbaarheid met een CVSS-score van 10.0. Shops die al dagen eerder waren binnengedrongen, bleven kwetsbaar tot iemand de hotfix daadwerkelijk installeerde. De patch bestond. Het probleem was dat niemand hem erin zette.

Dat is het patroon dat we steeds terugzien. Niet het ontbreken van een fix, maar het ontbreken van een proces om fixes te installeren. Een Magento upgrade als dienst lost precies dat op: je shop staat structureel op een ondersteunde 2.4.x-versie, zonder dat jij elke paar maanden zelf moet uitzoeken wat er moet gebeuren.

Waarom een Magento 2.4-upgrade niet uitstelbaar is

Adobe's eigen Software Lifecycle Policy is duidelijk: elke Adobe Commerce-release vanaf 2.4.4 krijgt doorgaans drie jaar quality- en securityfixes na de releasedatum. Daarna stopt Adobe met patchen van die specifieke versie, punt. Magento Open Source kent een eigen onderhoudsbeleid met andere einddata per release. Welke versie precies wanneer stopt, zetten we uit in Magento 2.4 versies en end-of-support.

Wat dit concreet betekent:

• Geen securityfixes meer na de einddatum, ook niet bij een kritieke kwetsbaarheid zoals StyleSmuggler.
• Extensie-compatibiliteit droogt op. Vendors testen hun modules op actuele versies, niet op een release van drie jaar oud.
• PCI-compliance komt in gevaar. Een shop die creditcardgegevens verwerkt op een ongepatchte versie, voldoet niet meer aan de eisen van je payment provider.
• Hosting-eisen lopen uit de pas. PHP-versies die Hypernode en andere hosts nog ondersteunen, sluiten niet meer aan op een verouderde Magento-core.

De eerlijke versie: één upgrade is geen eindpunt. Magento brengt elke paar maanden een nieuwe patch-release uit. Blijf je op 2.4.6 staan terwijl Adobe al bij 2.4.9 is, dan is de volgende upgrade geen kwartaaltje werk meer, maar een project.

Wat een Magento 2.4.x upgrade als dienst inhoudt

Een upgrade als dienst betekent dat wij je shop op een vaste cyclus bijhouden, in plaats van dat je zelf achteraf een brand moet blussen. Geen los project per keer, maar een doorlopende afspraak.

Concreet bestaat dat uit vier onderdelen:

1. Monitoring van releases. Zodra Adobe een patch-release of securitybulletin publiceert, checken we of die relevant is voor jouw shop en extensies.
2. Staging-upgrade en regressietest. Elke upgrade testen we eerst op een kopie van je shop: checkout, betaalmethodes, custom modules, Hyvä-theme. Pas na een groen licht gaat het naar productie.
3. Zero- of lage-downtime deployment. Hoe we dat technisch doen, staat uitgewerkt in security patches installeren zonder downtime. Dezelfde aanpak gebruiken we voor reguliere upgrades.
4. Rollback-plan per upgrade. Gaat er iets mis, dan draaien we terug naar de vorige werkende staat, niet naar een gokje.

Dit is geen vervanging van development. Het is de laag eronder: zorgen dat de fundering waarop je shop draait, ondersteund blijft.

Hoe wij een Magento upgrade aanpakken

We zijn een klein team senior developers. Geen projectmanager die tussen jou en de uitvoering zit, geen junior die voor het eerst een upgrade draait op jouw productieomgeving. Dat is geen marketingzin, het is de reden dat we überhaupt kunnen beloven dat een upgrade binnen een geplande window klaar is.

In de praktijk ziet een traject zo uit:

• Intake. We inventariseren welke extensies, custom modules en integraties je shop heeft. Dit is het stuk werk dat de meeste shops overslaan, en waar het daarna misgaat.
• Compatibiliteitscheck. Niet elke extensie werkt zonder aanpassing op een nieuwere 2.4.x-versie. Draai je Hyvä, dan checken we ook of je theme en compat-modules meegaan.
• Upgrade op staging. Composer-dependencies, database-schema's, indexers. We draaien de volledige testsuite die bij jouw shop past, niet alleen de happy flow.
• Go/no-go met jou. Je krijgt een concreet overzicht: wat is getest, wat is het risico, wanneer gaat het live.
• Monitoring na livegang. Via RUMvision houden we real user monitoring aan na elke upgrade, zodat een regressie in performance of fouten meteen zichtbaar is, niet pas bij een klacht van een klant.

Wat niemand je vertelt: de upgrade zelf is zelden het duurste deel. Het testen van custom code en extensies die niet voor de nieuwe versie zijn gebouwd, is dat wel. Een shop met vijf custom modules en een stapel extensies kost structureel meer tijd dan een shop die dicht bij de Magento-standaard is gebleven.

Wat kost een Magento 2.4 upgrade als dienst?

Dat hangt af van de staat van je shop, niet van een vast tarief per upgrade. Een shop die elke patch-release heeft meegenomen, kost per upgrade een fractie van een shop die drie versies achterloopt.

De rekenstap die we aanhouden:

Een exacte prijsindicatie voor jouw situatie, inclusief hosting en onderhoudskosten, vind je op onze pricing-pagina. Wat we daar niet beloven: een vast bedrag zonder je shop gezien te hebben. Dat is giswerk, en giswerk betaal jij achteraf terug in meerwerk.

Wat levert structureel bijhouden op? De rekenstap

Stel: je shop draait 2 miljoen euro omzet per jaar en ligt gemiddeld 8 uur plat bij een noodupgrade na een kritieke kwetsbaarheid, inclusief de tijd om eerst uit te zoeken wat er precies moet gebeuren. Bij een gelijkmatige omzetverdeling is dat ruim 1.800 euro aan gemiste omzet per incident, exclusief reputatieschade en exclusief de uren die je development-capaciteit daar ongepland aan kwijt is. Dit is een rekenvoorbeeld, geen klantcase — reken het voor je eigen omzet en risicoprofiel door.

Een shop die elke patch-release binnen enkele weken verwerkt, heeft die noodstop zelden nodig. De upgrade gebeurt dan buiten kantooruren, op staging getest, met een vooraf geplande deployment. Het verschil zit niet in of je ooit een kritieke kwetsbaarheid treft — die treft iedereen een keer — maar in of je er bij de aankondiging al op voorbereid bent of pas dan begint te zoeken wie het kan oplossen.

Hyvä-shops: let op compat-modules bij elke upgrade

Draai je Hyvä boven op Magento, dan is een upgrade nooit alleen een Magento-vraagstuk. Hyvä zelf, je compat-modules voor extensies die niet standaard Hyvä-compatibel zijn, en je eigen theme-aanpassingen moeten alle drie meegaan. Een Magento 2.4.x-upgrade die slaagt maar je Hyvä-checkout breekt, is voor een klant geen geslaagde upgrade. We testen daarom de volledige frontend-flow, niet alleen of de Magento-core zonder fouten draait.

Wanneer is upgraden als dienst niet de juiste keuze?

Als je shop binnen een jaar toch naar een ander platform gaat, of als je een eenmalige upgrade nodig hebt en daarna zelf beheer voert, is een doorlopende dienst overkill. Dan is een losse upgrade-opdracht logischer. We vertellen je dat liever eerlijk dan dat we je in een abonnement praten dat niet past.

Samengevat

• Adobe's eigen lifecycle-beleid geeft Adobe Commerce-releases doorgaans drie jaar support na release. Magento Open Source heeft een eigen, afwijkend schema.
• Na die periode stoppen securityfixes, ook bij kritieke kwetsbaarheden zoals StyleSmuggler (CVE-2026-75650).
• Een upgrade als dienst bestaat uit release-monitoring, staging-tests, zero-downtime deployment en een rollback-plan.
• Hoe verder je achterloopt, hoe duurder en risicovoller de volgende upgrade.
• Niet elke shop heeft een doorlopende dienst nodig — een eenmalige upgrade kan voldoende zijn.

Veelgestelde vragen

Hoe vaak moet ik Magento 2.4.x upgraden?

Adobe brengt meerdere keren per jaar patch-releases uit. Wij adviseren om elke relevante patch-release binnen enkele weken te verwerken, zodat je nooit meer dan één versie achterloopt. Dat houdt elke upgrade klein.

Wat is het verschil tussen een security patch en een volledige upgrade?

Een security patch dicht een specifiek lek in je huidige versie, vaak via een hotfix. Een upgrade brengt je naar een nieuwere 2.4.x-release met bugfixes, nieuwe features en langere supportduur. Beide kun je nodig hebben: een patch is spoed, een upgrade is onderhoud.

Wat kost een Magento 2.4 upgrade als dienst?

Dat verschilt per shop en hangt af van het aantal custom modules, extensies en hoeveel versies je achterloopt. Een indicatie op basis van jouw situatie staat op onze pricing-pagina.

Kan ik Magento Open Source blijven draaien zonder te upgraden?

Technisch kan dat, maar zonder securityfixes bouw je risico op. Elke maand zonder patches is een maand waarin bekende kwetsbaarheden, zoals StyleSmuggler, een open deur blijven voor aanvallers die precies weten welke versies ze moeten scannen.

Wat gebeurt er als mijn shop al voorbij end-of-support is?

Dan is de eerste stap geen reguliere upgrade, maar een inhaaltraject: compatibiliteit checken, custom code testen en in stappen naar een ondersteunde versie. Hoe verder je achterloopt, hoe meer dat traject lijkt op een gedeeltelijke rebuild in plaats van een upgrade.

Twijfel je of je shop nog binnen de supporttermijn valt, of wil je een vaste upgrade-cyclus afspreken? Neem contact op, dan kijken we samen naar je huidige versie en risico's.