Als Adobe Commerce-support stopt
Adobe heeft verduidelijkt wat merchants verliezen wanneer een Adobe Commerce-release het einde van de support bereikt. De applicatie blijft draaien, maar beveiligingsupdates, productwijzigingen en opgeloste supportvragen stoppen. Daarmee wordt een versiedeadline een beslissing over infrastructuur en bedrijfscontinuïteit.
- Auteur
- Intercube
- Gepubliceerd
- Leestijd
- 9 min leestijd
01
Wat Adobe heeft verduidelijkt
Adobe heeft de uitleg over het einde van Commerce-support op 24 september 2026 bijgewerkt. Zodra een release de gepubliceerde einddatum bereikt, maakt Adobe geen functionele, kwaliteits-, beveiligings- of PCI-gerelateerde wijzigingen meer voor die release. Supportvragen die na de deadline worden ingediend, worden niet opgelost. Documentatie voor niet-ondersteunde versies kan uit de actuele documentatieset verdwijnen.
De webshop schakelt op die datum niet uit. De software blijft onder de geldende licentie draaien, maar de merchant wordt verantwoordelijk voor risico's en reparaties die de leverancier niet meer afdekt. Adobe waarschuwt ook dat niet-ondersteunde software gevolgen kan hebben voor beveiliging en PCI-verplichtingen. Beoordeel die gevolgen met de eigen beveiligings- en PCI-specialisten, in plaats van ze tot een vinkje te reduceren.
De deadline raakt ook de bredere runtime. PHP, databases, zoekdiensten en andere afhankelijkheden kunnen hun eigen supportvenster verlaten terwijl de Commerce-release nog in gebruik is. Een ondersteunde Commerce-versie op een niet-ondersteunde dependency is geen gezonde productiebasis. Versieplanning moet daarom de volledige applicatieomgeving omvatten.
02
Breng de echte supportbasis in kaart
Begin met de exacte Commerce-editie en het patchniveau in iedere omgeving. Voeg de PHP-versie, database-engine, zoekdienst, cache, message queue, het besturingssysteem en de extensies voor checkout, betaling, fulfilment en beheer toe. De inventarisatie moet voor ieder onderdeel de supportdeadline en eigenaar tonen.
Adobe biedt momenteel drie jaar standaardsupport per releaselijn. Sommige releases hebben een verlengde of security-only periode, maar die vensters zijn niet gelijk aan een volledig ondersteunde basis. Adobe noemt de security-only periode voor 2.4.4, 2.4.5 en 2.4.6 expliciet een eenmalige overgang, geen permanente supportvorm. Teams die daarvan gebruikmaken, horen al een upgrade uit te voeren.
Maak ook commerciële afhankelijkheden zichtbaar. Een betaalextensie die niet met de doelrelease werkt, kan belangrijker zijn dan de core-upgrade. Leg vast wie iedere integratie kan testen, welk bewijs voor release nodig is en welke leverancier moet handelen wanneer de extensie niet meer wordt onderhouden.
- Noteer de Commerce-editie, releaselijn en het exacte patchniveau per omgeving.
- Koppel de supportdata van PHP, databases, search, cache, queues en besturingssystemen.
- Identificeer extensies die checkout, betaling, fulfilment of klantgegevens raken.
- Wijs aan iedere blokkerende dependency een eigenaar en acceptatietest toe.
03
Maak van de upgrade een beheerwijziging
Een Commerce-upgrade is niet klaar wanneer de code compileert. Infrastructuur, build tooling, deploymentvolgorde, indexers, queues, cronjobs en caches bepalen mede het gedrag van de release. Bouw een productieachtige doelomgeving, herstel representatieve data op een veilige manier, repeteer de deployment en meet de paden die omzet bepalen voordat je een omschakelmoment kiest.
Ook de rollbackbeslissing vraagt voorbereiding. Bepaal welke fouten de release stoppen, welke databasewijzigingen omkeerbaar zijn en hoe orders tijdens de omschakeling beschermd blijven. Bewaar logging en monitoring uit beide omgevingen, zodat een regressie in checkout of integraties niet onder tijdsdruk op basis van aannames wordt onderzocht.
Wanneer het huidige hostingmodel van iedere upgrade een los infrastructuurproject maakt, kan het verplaatsen van de applicatie de betere beslissing zijn. Een migratie biedt ruimte om runtimeversies, diensten, deployments, toegang en monitoring als één onderhouden platform opnieuw in te richten. De deadline ligt daarna niet meer bij de persoon die toevallig de oude server het beste kent.
04
Gebruik de deadline voordat het een incident wordt
Supportdata horen in dezelfde planning als productreleases. Controleer ze minimaal ieder kwartaal, reserveer engineeringcapaciteit voor het laatste patchvenster en onderhoud een omgeving waarin de volgende ondersteunde stack getest kan worden. Wachten op een beveiligingsadvies laat minder ruimte om problemen met extensies en data veilig op te lossen.
Voor Adobe Commerce on Cloud publiceert Adobe afzonderlijke handhavingsdata en kan verkeer worden beperkt wanneer niet aan de eisen wordt voldaan. Merchants die Adobe Commerce elders draaien of Magento Open Source gebruiken, hebben een andere contractuele positie. Niet-ondersteunde software blijft echter een operationeel risico. Laat de hostingbeslissing volgen uit de werkelijke editie, het deploymentmodel en de dependencies.
Intercube kan de huidige shop beoordelen, het ondersteunde doel ontwerpen en de infrastructuur na de omschakeling beheren. Migratie naar Intercube managed hosting is inbegrepen zonder aparte migratiekosten. Applicatieontwikkeling, licenties en werk van derden blijven afzonderlijk, zodat vooraf duidelijk is waar inspanning en kosten liggen.
Wat je voor het einde van support doet
- Bevestig voor iedere omgeving de exacte Commerce-release en supportfase.
- Neem PHP, databases, search, queues, extensies en besturingssystemen op in het lifecycleplan.
- Gebruik security-only dekking als migratietijd, niet als stabiele langetermijnbasis.
- Repeteer de upgrade, omschakeling en rollback met productieachtige data en integraties.
- Kies een beheerpartner die verantwoordelijk blijft nadat het migratieproject is afgerond.