Waarom upgraden niet optioneel is
Adobe brengt per kwartaal security patches uit voor Magento 2. Een patch op versie 2.4.6-p14 dicht bijvoorbeeld bekende kwetsbaarheden in de admin en checkout. Een shop die op 2.4.4 of 2.4.5 blijft draaien, mist die patches en staat bloot aan bekende exploits die actief worden gebruikt.
- ▸2.4.4 end-of-life: geen security patches meer na april 2026. Elke dag na die datum is een ongedekte kwetsbaarheid.
- ▸PHP-versie EOL: PHP 8.1 ontvangt geen security updates meer. Magento 2.4.7 vereist PHP 8.2 of 8.3. De PHP-upgrade zit bijna altijd in hetzelfde traject.
- ▸Vendor-modules: extensies van derden volgen hun eigen releaseschema. Een module die compatibel is met 2.4.5 werkt soms niet meer op 2.4.7 zonder update of patch.
- ▸Adobe Commerce roadmap: nieuwe functies zoals de verbeterde checkout en GraphQL-verbeteringen komen alleen beschikbaar in recente versies. Op een verouderde versie blijven zitten betekent achterblijven op functionaliteit.
- ▸Composer-dependencies: een verouderde versie trekt een keten van outdated packages mee. Hoe langer je wacht, hoe groter de delta bij de volgende upgrade.
Het risico van niet upgraden groeit met de tijd. Van 2.4.6 naar 2.4.7 is een beheerste stap. Van 2.4.4 naar 2.4.8 is een veel grotere delta met meer conflicten.
Hoe ik een upgrade aanpak
Een upgrade op een productie-Magento-shop vereist voorbereiding. Ik werk altijd met een dev-clone van de productieshop voordat er iets op productie verandert.
- ▸Dev-clone opzetten: productie-database exporteren, importeren op staging, .env aanpassen. Alles wat ik doe, test ik eerst hier.
- ▸Composer resolve: de core upgrade uitvoeren via composer require en vervolgens de conflicten per extensie doorlopen. Met 328 modules op CarCare24 betekent dit soms 15 tot 20 handmatige conflicten uitzoeken.
- ▸Vendor-module updates: elke extensie die een nieuwe versie vereist voor compatibility, update ik afzonderlijk. Soms is een composer-patch de tijdelijke oplossing als de extensieleverancier nog geen compatibele release heeft.
- ▸di:compile + static-content:deploy: na elke significante wijziging een volledige compile- en deploy-cyclus. Zonder static-content:deploy staat de shop op HTTP 500 met 'Unable to retrieve deployment version'.
- ▸Smoke-test op 6 routes: homepage, categoriepagina, productpagina, zoekresultaten, checkout, bevestigingspagina. Dit zijn de kritieke paden. Alles moet werken voor ik de stap naar productie overweeg.
- ▸Rollback-strategie: voor elke productie-upgrade zet ik een database-snapshot klaar en noteer ik de exacte composer.lock staat. Als er binnen 24 uur een P1 issue is, kan ik terug.
Op productie werk ik bij voorkeur buiten piekuren. De cache-flush na deploy geeft een korte periode met hogere load door cache-warming. Dat is normaal en acceptabel. Een daadwerkelijke downtime is niet acceptabel.
De 4 deploy stappen die altijd moeten
Na elke code-wijziging op een Magento 2-installatie in production-mode zijn deze 4 stappen verplicht, in deze volgorde:
- 1.
bin/magento setup:upgradeDatabase-schema bijwerken, nieuwe module-configuraties registreren. - 2.
bin/magento setup:di:compileDependency injection-code regenereren. Mist een class, dan volgt een 500 op runtime. - 3.
bin/magento setup:static-content:deploy -fRegenereert deployed_version.txt. Zonder deze stap krijgt elke pagina HTTP 500 met 'Unable to retrieve deployment version'. Dit is de stap die het vaakst vergeten wordt. - 4.
bin/magento cache:flushCache leegmaken zodat de nieuwe code actief wordt voor bezoekers.
Bij shops met een SRI-hashes module: stap 3 uitvoeren met --jobs=1. Parallel jobs geven een race-condition die de sri-hashes.json corrumpeert.
Risico's die ik ken en aanpak
Niet elke upgrade verloopt soepel. Dit zijn de problemen die ik op een productieomgeving met 328 modules heb tegengekomen en weet op te lossen:
- ▸Knockout.js compatibility breaks: Magento 2.4.7 bevat updates aan de KO-componenten voor checkout en mini-cart. Custom templates die KO-bindings gebruiken moeten gecontroleerd worden op deprecated syntax.
- ▸Third-party module breaks: een extensie die niet is bijgehouden, kan na een core-upgrade stoppen met werken. Ik controleer elke extensie op de Magento Marketplace compatibility-matrix en zoek de juiste patch of update.
- ▸Custom theme JavaScript regressies: custom JS die interfereert met RequireJS-modules of met de nieuwe checkout-flow. Ik test alle aangepaste front-end code op de upgrade-versie.
- ▸SRI-hashes race conditions: de sri-hashes module genereert een manifest bij static-content:deploy. Bij parallelle jobs kan het manifest corrupt raken, wat frontend-resources blokkeert. Dit heb ik op Wave-9 live meegemaakt.
- ▸MagePack rollback: na een upgrade kan een bestaande MagePack-bundeling verouderd zijn en grotere bundles geven dan de standaard RequireJS-loading. Dan gooi ik de bundle-configuratie terug en herbouw.
- ▸Plumrocket cookie-blocking regressions: cookie-consent modules die de consent-flow opnieuw blokkeren na een upgrade omdat scripts opnieuw render-blocking zijn geworden door volgorde-wijzigingen in layout-XML.
Deze problemen zijn oplosbaar. Het verschil is dat ik ze herken voordat ze op productie tot een P1 worden.
-- Upgrade-casus
CarCare24: patch p14 naar p15 met MagePack rollback
CarCare24 draait Magento 2.4.6 op Hypernode met Cloudflare. Het productie-platform heeft 328 modules waaronder M2EPro voor marketplace-sync, Plumrocket cookie-consent en een custom SRI-hashes module. Op 15 mei 2026 voerde ik de patch-upgrade van p14 naar p15 uit.
Na de patch-deploy draaide de front-end aanvankelijk stabiel. Na 2 uur bleek MagePack een stale bundle-configuratie te hebben geladen die grotere JS-bundles produceerde dan voor de patch. De LCP op mobiel steeg direct meetbaar. Ik rolde MagePack terug naar de standaard RequireJS-bundeling en voerde een herinstallatie van de bundle-configuratie uit. Plumrocket had daarnaast een cookie-blocking regressie waarbij scripts opnieuw render-blocking werden. Die fix vergde een aanpassing in de layout-XML.
Na de MagePack-rollback en de Plumrocket-fix stond de shop weer op het prestatie-niveau van voor de patch. De totale impact voor bezoekers was beperkt tot de 2-uurs periode. Rollback-strategie en monitoring zijn geen overbodige luxe bij shops met dit aantal modules.
Wat ik niet doe
Er zijn trajecten die ik afraden en niet zelf uitvoer:
- ✕Major Adobe Commerce upgrade zonder licentie-check: een upgrade naar Adobe Commerce Enterprise vereist een licentie. Ik voer die upgrade niet uit zonder dat de licentiesituatie helder is.
- ✕Theme-versies upgraden zonder custom-mod assessment: een theme-update overschrijft custom aanpassingen. Ik breng altijd eerst in kaart welke custom wijzigingen in de theme-bestanden zitten voor ik een theme-update aanraad.
- ✕Vendor-modules vervangen zonder feature-parity check: als een extensie wordt vervangen door een alternatief, controleer ik eerst of alle functionaliteit die de shop gebruikt ook beschikbaar is in het alternatief.
- ✕Upgrade op productie zonder staging-test: geen enkele code-change op productie zonder dat het eerst op staging heeft gedraaid. Dit is geen aanbeveling, het is een harde regel.
- ✕Major versie-upgrade overslaan: van 2.4.4 direct naar 2.4.8 is technisch mogelijk maar vergroot het risico op onverwachte conflicten aanzienlijk. Ik adviseer stapsgewijze upgrades via tussenliggende minor-versies.
Scope en prijs
De prijs van een upgrade-traject hangt af van het aantal modules, de aanwezigheid van custom modules of custom theme-aanpassingen, de grootte van de PHP-versie-sprong en of er een staging-omgeving beschikbaar is.
Ik werk niet met vaste upgrade-pakketten. Een shop met 20 standaard Marketplace-extensies op Hypernode heeft een andere scope dan een shop met 328 modules waarvan een deel custom is. Prijzen zijn altijd op aanvraag, na een korte inventarisatie van de huidige stack.