De jaarlijkse releasecyclus van Adobe: Magento-upgrades plannen voor 2026–2029

Jarenlang planden Magento-teams rond een ritme van patchreleases per kwartaal en af en toe een minor versie. Dat ritme is voorbij. Adobe veranderde begin 2026 zijn releasemodel, en het nieuwe schema is eenvoudiger te plannen als je weet hoe de onderdelen samenhangen.

Deze gids legt het huidige model uit, zet de supportdata op een rij die ertoe doen voor de versielijnen 2.4.7, 2.4.8 en 2.4.9, en laat zien hoe je die omzet in een praktische upgradekalender en een budget voor 2026 tot en met 2029.

Het releasemodel van 2026 in drie lagen

Het releaseschema van Adobe bestaat nu uit drie afzonderlijke lagen. Elke laag vraagt aan jouw kant om een ander proces.

1. Eén featurerelease per jaar (mei)

Volgens het releaseschema van Adobe verschijnt elk jaar in mei een volledige release voor de 2.4.x-LTS-lijn, met een supportperiode van drie jaar. Magento Open Source en Adobe Commerce 2.4.9 volgden dat patroon en werden op 12 mei 2026 algemeen beschikbaar. Elke jaarlijkse release wordt voorafgegaan door één alfa en één bèta, zodat je extensies en maatwerkcode kunt testen vóór de algemene beschikbaarheid.

2. Volledige beveiligingspatchreleases (-pN)

Adobe belooft voor alle ondersteunde versielijnen minstens één keer per jaar volledige beveiligingspatches uit te brengen (de bekende 2.4.x-pN versies), met extra releases als dat nodig is. In 2026 verschenen patchreleases op 10 maart (bijvoorbeeld 2.4.8-p4 en 2.4.7-p9) en opnieuw op 12 mei, samen met 2.4.9 (2.4.8-p5, 2.4.7-p10). Verschillende partners verwachten rond november een tweede gebundeld venster, maar Adobe noemt extra releases voorwaardelijk, dus beschouw een datum in november als voorlopig totdat Adobe die bevestigt.

3. Maandelijkse geïsoleerde beveiligingspatches

Tussen volledige releases door publiceert Adobe op Patch Tuesday, de tweede dinsdag van elke maand, geïsoleerde beveiligingspatches voor Adobe Commerce on Cloud, on-premises Adobe Commerce en Magento Open Source. Volgens het beleid van Adobe zijn deze patches nauw afgebakende codediffs, ze zijn niet cumulatief, en ze moeten op volgorde worden geïnstalleerd, omdat elke patch ervan uitgaat dat de eerdere al geïnstalleerd zijn. Elke geïsoleerde fix wordt later opgenomen in de volgende volledige -pN release.

Cloud-klanten krijgen deze via Cloud Patches for Commerce. On-premises- en Open Source-webshops hebben een eigen proces nodig: bevestig je basisversie -p , installeer de patchbestanden op volgorde en controleer het resultaat.

Buiten het schema om komen er nog steeds hotfixes. In september 2026 bracht Adobe hotfix VULN-39341 uit voor CVE-2026-75650 (bulletin APSB26-146), een lek waarmee zonder inloggen code kan worden uitgevoerd in 2.4.4 tot en met 2.4.9, en waarvan Adobe bevestigde dat het in de praktijk werd misbruikt. De richtlijnen van Adobe gingen verder dan patchen: roteer de encryptiesleutel en alle bijbehorende inloggegevens. Je kalender moet ruimte hebben voor dit soort gebeurtenissen.

Supportdata voor 2.4.7, 2.4.8 en 2.4.9

Het lifecyclebeleid van Adobe geeft elke versielijn drie jaar standaardsupport vanaf de algemene beschikbaarheid. Versies 2.4.6 en 2.4.7 krijgen voor klanten van Adobe Commerce daarnaast één jaar extended support zonder extra kosten.

Twee punten vallen op. Ten eerste is de standaardsupport voor 2.4.6 al gestopt, dus elke webshop die nog op die lijn zit, moet nu een overstap plannen. Ten tweede vallen de einddata van de support voor nieuwere versielijnen op 31 mei, wat aansluit op de releasemaand mei. Dat maakt plannen makkelijker: elk voorjaar valt er één versielijn uit de standaardsupport en komt er een nieuwe bij.

Voor Adobe Commerce on Cloud voegt het security enforcement-beleid van Adobe harde deadlines toe. Upgrades van dependencies (PHP, MariaDB, OpenSearch, Redis of Valkey, RabbitMQ) moeten vanaf 30 oktober 2026 klaar zijn, met voor sommige dependencies een deadline van 31 mei 2027. De deadlines voor versie-upgrades zijn 1 juni 2027 voor 2.4.4 en 2.4.5, en 1 juni 2028 voor 2.4.6 en 2.4.7. Volgens Adobe kan bij omgevingen die deze deadlines missen het verkeer worden stilgelegd.

Wat 2.4.9 verandert voor je planning

2.4.9 is een zwaardere upgrade dan een gewone minor release. Volgens de release notes van Adobe voegt de versie ondersteuning voor PHP 8.5 toe en vervalt PHP 8.2, wordt Laminas MVC vervangen door een eigen implementatie, gaat de editor van TinyMCE naar HugeRTE, wordt Zend_Cache vervangen door Symfony Cache en worden dependencies geüpgraded naar Symfony 7.4 LTS. Ook komt er ondersteuning voor MariaDB 11.8 en 12.x, OpenSearch 3 en Valkey 9.

Elk van deze wijzigingen raakt maatwerkmodules en extensies van derden. Controleer op de officiële pagina met systeemvereisten welke PHP- en databaseversies precies worden ondersteund voor jouw upgradepad, en budgetteer extra regressietests voor alles wat de WYSIWYG-editor in de admin, de cachinglaag of de MVC-internals uitbreidt.

Zo bouw je een upgradekalender voor 2026–2029

De eenvoudigste aanpak is het jaar als een vaste cyclus te behandelen. De tabel hieronder is een sjabloon; alleen de data die Adobe al heeft gepubliceerd, liggen vast.

Je doelversie kiezen

Je hoeft niet elk jaar te upgraden. Een praktische vuistregel: blijf hooguit één release line achter op de nieuwste en laat je versie nooit uit de standaardondersteuning vallen. Toegepast op de huidige data betekent dat:

• Op 2.4.6 of ouder: stap zo snel mogelijk direct over naar 2.4.8 of 2.4.9. De standaardondersteuning voor 2.4.6 is op 11 augustus 2026 geëindigd.
• Op 2.4.7: plan je overstap vóór 31 mei 2027. Zie de verlengde ondersteuning tot mei 2028 alleen als vangnet.
• Op 2.4.8: je hebt tot 31 mei 2028. Upgrade je in een rustige periode in 2027 naar 2.4.9, dan loop je ruim voor.
• Op 2.4.9: de ondersteuning loopt tot 31 mei 2029. Focus op maandelijks patchen en plan je volgende release line zodra de feature release van 2027 een paar maanden beschikbaar is.

Een ritme dat werkt voor de meeste middelgrote webshops

1. Wijs een patchverantwoordelijke aan en kies een vast maandelijks onderhoudsvenster.
2. Houd je stagingomgeving gelijk aan productie, zodat je losse patches in uren in plaats van dagen kunt testen.
3. Upgrade elke één tot twee jaar naar een nieuwe release line, altijd in de periode juni tot september.
4. Voer vóór elke upgrade een extensie-audit uit en verwijder modules die je niet meer gebruikt.
5. Leg je incidentproces voor spoedhotfixes vast, inclusief het roteren van inloggegevens.

Leg vóór elke upgrade een schone uitgangssituatie vast van wat er geïnstalleerd is:

bin/magento --version
composer show --direct
bin/magento module:status --enabled
php -v

De cyclus budgetteren

We kunnen je geen standaardprijs geven, want de kosten hangen af van het aantal maatwerkmodules, externe extensies en integraties en van de staat van je testdekking. Wat je wel kunt doen, is het budget opsplitsen in voorspelbare posten:

• Maandelijks patchcontract: een vast aantal uren per maand om losse patches te beoordelen, testen en uitrollen.
• Jaarlijkse security patch release: elk jaar in mei een klein project om de -pN voor je release line te installeren.
• Upgrade naar een nieuwe release line: elke één tot twee jaar een groter project. Baseer de schatting op een audit van maatwerkcode en extensies, niet op een vast tarief.
• Infrastructuur: upgrades van PHP, database, zoekmachine en cache komen vaak mee met een nieuwe release line. Op Adobe Commerce Cloud gelden daarvoor ook eigen deadlines.
• Onvoorzien: houd een reserve aan voor spoedhotfixes en incidentrespons, zoals de kwetsbaarheid van september 2026 liet zien.

Het nieuwe model beloont gestage investeringen. Teams die maandelijks patchen en volgens planning upgraden, geven in totaal minder uit dan teams die wachten tot de ondersteuning afloopt en dan onder tijdsdruk twee versies tegelijk proberen over te slaan.

Veelgestelde vragen

Brengt Adobe nog steeds elk kwartaal patches uit?

Nee. Sinds januari 2026 werkt Adobe met maandelijkse losse beveiligingspatches, minstens één volledige security patch release per jaar en één feature release in mei. Extra volledige patchreleases kunnen verschijnen als dat nodig is.

Zijn de maandelijkse losse patches cumulatief?

Nee. Volgens het beleid van Adobe bevatten ze alleen de specifieke fixes en moeten ze op volgorde worden geïnstalleerd. Later worden ze opgenomen in de volgende volledige -pN release.

Wanneer eindigt de ondersteuning voor 2.4.7?

De standaardondersteuning eindigt op 31 mei 2027. Klanten van Adobe Commerce krijgen verlengde ondersteuning tot 31 mei 2028.

Gelden deze data ook voor Magento Open Source?

Het lifecyclebeleid geldt voor de 2.4.x-release lines, en losse patches verschijnen ook voor Magento Open Source. Verlengde ondersteuning wordt beschreven als voordeel van Adobe Commerce, dus Open Source-gebruikers doen er goed aan uit te gaan van de standaard ondersteuningsdata.

Bronnen

• Adobe: Software lifecycle policy
• Adobe: Release schedule
• Adobe: Monthly isolated security patching policy
• Adobe: Released versions
• Adobe: Adobe Commerce 2.4.9 release notes
• Adobe: systeemvereisten
• Adobe: vereiste acties en deadlines om Commerce-omgevingen te beveiligen
• Adobe: Critical security update APSB26-146