Checklist voor je Magento 2.4.x-update: vóór, tijdens en na

Een veilige Magento 2.4.x-update kent drie fases. Vóór: controleer welke releaselijn nog ondersteund wordt, bevestig welke PHP-, OpenSearch- en databaseversies de doelrelease nodig heeft, en toets elke extensie en maatwerkmodule daaraan. Tijdens: update op een stagingkopie met productiedata en voer daarna regressietests uit op de checkout en elke koppeling. Na: release op een gepland moment met een geteste rollback, en houd de eerste dagen fouten, orders en performance in de gaten. Hieronder staat de checklist die we bij elke update doorlopen, geschreven voor webshopeigenaren en voor bureaus die updates aan ons uitbesteden.

De versies en data hieronder zijn in november 2026 gecontroleerd aan de hand van de officiële documentatie van Adobe. Adobe werkt deze pagina’s regelmatig bij, dus controleer ze opnieuw als je gaat plannen.

Vóór de update

1. Weet waar je versie staat

Adobe geeft elke 2.4.x-releaselijn drie jaar standaardsupport vanaf de releasedatum, met kwaliteitsfixes en securitypatches. Sommige oudere lijnen krijgen extra tijd. Releases van Magento Open Source volgen dezelfde 2.4.x-releaselijnen en hetzelfde patchschema als Adobe Commerce; de lifecycledata publiceert Adobe voor Adobe Commerce.

Wat dit in de praktijk betekent:

• Op 2.4.4 of 2.4.5: je krijgt alleen losse securityfixes, geen kwaliteitsfixes, en die periode wordt niet verlengd. Plan nu een minor update.
• Op 2.4.6: de standaardsupport is afgelopen. Je hebt nog tijd, maar niet veel.
• Op 2.4.7 of 2.4.8: voer elke securitypatch door (de -pN releases) en plan de volgende minor update in alle rust.
• Op Adobe Commerce Cloud: vanaf 1 juni 2027 onderhoudt Adobe geen Cloud-omgevingen meer die op niet-ondersteunde versies draaien.

Controleer ook of je op de nieuwste patch van je lijn zit. De losse securitypatchbestanden van Adobe kunnen alleen daarbovenop worden toegepast, dus een webshop die meerdere patches achterloopt, kan een noodfix niet snel doorvoeren.

De 2.4.10-lijn is op het moment van schrijven in alpha. Plan geen productie-update op een alpha- of bètarelease.

2. Controleer de platformvereisten

Een groot deel van het risico van een update zit buiten Magento zelf: PHP, de zoekmachine, de database en de cache. De systeemvereisten van Adobe voor de nieuwste patch van elke lijn (self-hosted):

Punten waar teams vaak op vastlopen:

• PHP-sprongen. Van 2.4.6 naar 2.4.9 betekent van PHP 8.1/8.2 naar 8.5. Elke maatwerkmodule en extensie moet op de nieuwe PHP-versie draaien, niet alleen de Magento-core. PHP 8.2 zelf krijgt nog maar tot 31 december 2026 securityfixes.
• Zoekmachine. Elasticsearch 7.17 is op 15 januari 2026 uit support gegaan, en 2.4.9 noemt alleen OpenSearch 3. Draai je nog Elasticsearch, dan hoort de migratie van de zoekfunctie bij het project. Reken op herindexering en op het toetsen van elke zoekextensie aan OpenSearch.
• Database. MySQL 8.0 is op 30 april 2026 uit support gegaan. Controleer welke MySQL- of MariaDB-versies je doelrelease ondersteunt voordat je de code aanraakt.
• Cache. Recente patches noemen Valkey in plaats van Redis. Je hosting of Cloud-setup moet de versie bieden die de doelrelease verwacht.
• Commerce Cloud heeft een eigen tabel met vereisten die afwijkt van die voor self-hosted. Zit je op Cloud, gebruik dan de Cloud-waarden.

3. Stel een compatibiliteitsmatrix van extensies op

Zet elke module van derden uit composer.json en app/code op een rij en vul per extensie één regel in:

• geïnstalleerde versie en leverancier;
• de versie die je Magento-doelrelease en PHP-versie ondersteunt (uit de changelog van de leverancier, niet alleen op basis van de badge in de marketplace);
• licentie- of supportstatus, want sommige updates vereisen een betaalde verlenging;
• of de module überhaupt nog gebruikt wordt.

Markeer elke regel als updaten, vervangen, zelf patchen of verwijderen. Verlaten modules zijn een veelvoorkomende reden dat inschattingen voor een update oplopen. Modules verwijderen die niemand gebruikt, is vaak de goedkoopste oplossing.

4. Controleer maatwerkcode en deprecated API’s

• Aanpassingen aan de core. Zoek naar wijzigingen in vendor/, overschreven core-classes en Composer-patches. Elk daarvan moet opnieuw tegen de nieuwe release worden gecontroleerd.
• Plugins en preferences op core-classes breken als methodesignaturen veranderen.
• Wijzigingen die niet backward compatible zijn. Adobe publiceert per release een lijst. Zo stapt 2.4.9 over op Symfony 7.4 LTS, waardoor eigen classes die Symfony-core-classes uitbreiden bijgewerkte typedeclaraties en methodesignaturen nodig hebben. Ook weigert 2.4.9 orders die via de API zonder factuuradres worden aangemaakt; dat is belangrijk als een ERP- of marketplace-connector orders aanmaakt.
• Op Adobe Commerce draai je de Upgrade Compatibility Tool van Adobe tegen de doelversie. Die rapporteert kritieke problemen, fouten en waarschuwingen in je modules en core-code. Voor Magento Open Source is de tool niet beschikbaar; daar gebeurt dezelfde controle met de hand en met statische analyse.

5. Bereid staging en back-ups voor

• Een stagingomgeving die overeenkomt met productie: dezelfde PHP-, zoekmachine-, database- en cacheversies als het doel, niet als vandaag.
• Een recente kopie van de productiedata, geanonimiseerd als de stagingomgeving minder goed beveiligd is dan productie.
• Back-ups die je minstens één keer hebt teruggezet: databasedump, media/, app/etc/env.php en de uitgerolde code (of het release-artefact). Een back-up die je nooit hebt teruggezet, is een hoop, geen back-up.
• Een code freeze of op zijn minst een duidelijke branchstrategie, zodat features die tijdens de update worden ontwikkeld er niet mee botsen.

Tijdens de update

6. Update in kleine, controleerbare stappen

1. Update eerst de infrastructuur op staging: PHP, zoekmachine, database en cache.
2. Update Magento en de extensies via Composer, groep voor groep, en commit na elke stap.
3. Draai setup:upgrade, compileer DI en deploy de statische content, en los elke fout en deprecation-waarschuwing op. Onderdruk ze niet.
4. Pas Composer-patches opnieuw toe of verwijder ze; sommige worden na een update overbodig.
5. Bouw de frontend-assets opnieuw en controleer het theme, vooral als het core-templates overschrijft.

7. Test wat geld oplevert op regressies

Geautomatiseerde tests helpen, maar een schriftelijk testplan dat de echte bedrijfsprocessen dekt, is het minimum:

• Checkout: als gast en ingelogd, elke betaalmethode (inclusief 3-D Secure en wallets), elke verzendmethode, kortingscodes, cadeaubonnen, btw en valuta per store view.
• Klantaccount: registratie, inloggen, wachtwoord resetten, bestelgeschiedenis, opnieuw bestellen.
• Catalogus en zoeken: categoriepagina’s, gelaagde navigatie, zoekresultaten en autocomplete na herindexering, configureerbare en bundelproducten, prijzen per klantgroep.
• Koppelingen: ERP- en voorraadsynchronisatie, orderexport, webhooks voor betalingen en verzending, marketplace-feeds, e-mail- en marketingtools, analytics- en tagmanager-events. Test beide richtingen, met echte (sandbox-)credentials.
• Beheer en operations: orders aanmaken en factureren, creditnota’s, imports, cronjobs, queue consumers en transactionele e-mails.
• B2B-functies op Adobe Commerce: bedrijfsaccounts, gedeelde catalogi, offertes, bestellijsten.

Doe ook een snelle performancecheck: hitrate van de full-page cache, serverresponstijd op belangrijke pagina’s en Core Web Vitals op templates die je hebt aangepast.

8. Plan het releasemoment en de rollback

• Kies een moment met weinig verkeer, buiten campagnes, sales en andere seizoenspieken.
• Schrijf het release-runbook: stappen, wie wat doet, verwachte duur en het beslismoment voor een rollback.
• Leg rollbackcriteria vast vóór de release (bijvoorbeeld: checkout kapot, mislukte betalingen, koppelingsfouten die je binnen het releasemoment niet kunt oplossen).
• Houd de vorige release en een verse databaseback-up klaar, en weet hoe lang terugzetten duurt. Zodra er na de database-update nieuwe orders binnenkomen, betekent het terugdraaien van de database dat je die kwijtraakt; het venster voor een rollback is dus kort.
• Zet de webshop alleen in onderhoudsmodus voor de stappen die het nodig hebben, en informeer support en marketing vooraf over de planning.

Na de update

9. Houd de eerste dagen alles nauwlettend in de gaten

• Fouten: PHP- en exceptionlogs, mislukte cronjobs, vastgelopen queue consumers.
• Orders: vergelijk het ordervolume en het percentage mislukte betalingen met een normale week. Een stille daling is vaak het eerste teken van een probleem met betalingen of de checkout.
• Koppelingen: controleer of orders in het ERP aankomen, voorraadniveaus terugkomen en webhooks slagen.
• Zoeken en indexering: indexers geldig, zoekresultaten logisch, geen groeiende achterstand in herindexering.
• Performance: responstijden, cache-hitrate en Core Web Vitals vergeleken met vóór de update.

10. Rond het af

• Verwijder de modules en patches die je hebt vervangen, en ruim oude deployment-artefacten op.
• Werk de documentatie bij: versies, de extensiematrix, het runbook.
• Zet de volgende securitypatch in de agenda. Wie op de nieuwste patch van zijn lijn blijft, houdt de volgende minor update klein.

Patch, minor of upgrade vanaf een oudere versie: wat je kunt verwachten

• Patch-update (bijvoorbeeld van 2.4.8-p4 naar 2.4.8-p5): kleine scope, vooral testen. Dit hoort routine te zijn.
• Minor update (bijvoorbeeld van 2.4.7 naar 2.4.8 of 2.4.9): nieuwe PHP- en serviceversies, bijgewerkte extensies en fixes in maatwerkcode. Dit is een project, geen taak.
• Upgrade vanaf 2.3 of ouder: reken op meer werk, omdat er meerdere PHP-versies en veel verouderde componenten tussen zitten.

Denk je er ook over om Luma te vervangen, lees dan eerst Wanneer is Hyvä het waard? Een Hyvä-migratie kan gecombineerd worden met een minor update; op een niet-ondersteunde versie komt de update eerst.

Hulp bij je update

Wil je een extra paar ogen voordat je begint, dan bieden we een gratis express-audit: versies, patchniveau, performance en basisbeveiliging, met een kort rapport en een call van 20 minuten. Voor de update zelf beginnen onze pakketten met een vaste prijs bij € 300 voor een patch-update en € 1.000 voor een minor 2.4.x-update inclusief de PHP-update. De definitieve prijs volgt na de audit. Om de webshop daarna gepatcht te houden, zie Magento onderhoudscontracten.

Bronnen: Adobe Experience League: Lifecycle policy, System requirements, Released versions, Release schedule, Magento Open Source 2.4.9 release notes, Upgrade Compatibility Tool; Adobe Developer: Backward-incompatible changes; PHP supported versions.