When Adobe Commerce support ends
Adobe has clarified what merchants lose when an Adobe Commerce release reaches end of support. The application keeps running, but security fixes, product changes and resolved support cases stop. That turns a version deadline into an infrastructure and business-continuity decision.
- Author
- Intercube
- Published
- Reading time
- 9 min read
01
What Adobe clarified
Adobe updated its Commerce end-of-support guidance on 24 September 2026. Once a release reaches its published deadline, Adobe no longer produces functional, quality, security or PCI-related changes for that release. Support cases filed after the deadline will not be resolved, and documentation for unsupported versions can disappear from the current documentation set.
The store does not switch off on that date. It continues to run under the applicable licence, but the merchant assumes responsibility for risks and fixes that the vendor no longer covers. Adobe also warns that unsupported software can affect security and PCI obligations. The practical consequence should be assessed with the organisation's own security and PCI specialists, rather than reduced to a checkbox.
The deadline also applies to the wider runtime. PHP, databases, search services and other dependencies can leave their own support windows while the Commerce release remains in use. A nominally supported Commerce version on an unsupported dependency is not a healthy production baseline. Version planning therefore has to include the complete application environment.
02
Build the real support inventory
Start with the exact Commerce edition and patch level in every environment. Add the PHP version, database engine, search service, cache, message queue, operating system and the extensions that participate in checkout, payment, fulfilment and administration. The resulting inventory should show the support deadline and owner for every component that can block an upgrade.
Adobe currently provides three years of standard support for a release line. Some releases have extended or security-only periods, but those windows are not equivalent to a fully supported baseline. Adobe explicitly describes the security-only period for 2.4.4, 2.4.5 and 2.4.6 as a one-time transition, not a permanent support tier. Teams using it should already have an upgrade route in execution.
The inventory should also expose commercial dependencies. A payment extension that is incompatible with the target release can be more important than the core upgrade itself. Record who can test each integration, what evidence is required before release and which supplier must act when the extension is no longer maintained.
- Record the Commerce edition, release line and exact patch level per environment.
- Map PHP, database, search, cache, queue and operating-system support dates.
- Identify extensions that affect checkout, payment, fulfilment or customer data.
- Assign an owner and an evidence-based acceptance test to every blocking dependency.
03
Make the upgrade an operating change
A Commerce upgrade is not complete when the code compiles. Infrastructure, build tooling, deployment order, indexers, queues, cron jobs and caches all change the behaviour of the release. Create a production-like target, restore representative data safely, rehearse the deployment and measure the paths that determine revenue before choosing a cutover date.
The rollback decision needs the same preparation. Define which failures stop the release, which database changes can be reversed and how orders created during a cutover are protected. Preserve logs and monitoring from both environments so that a checkout or integration regression can be diagnosed without guessing under time pressure.
When the present hosting model makes every upgrade a bespoke infrastructure project, moving the application can be the cleaner decision. A migration creates the opportunity to rebuild runtime versions, services, deployment automation, access and monitoring as one maintained platform. It also removes the deadline from the person who happens to know the old server best.
04
Use the deadline before it becomes an incident
Support dates should enter the same planning cycle as product releases. Review them at least quarterly, reserve engineering capacity before the final patch window and keep an environment where the next supported stack can be tested. Waiting for a security advisory leaves less room to resolve extension and data problems safely.
For Adobe Commerce on Cloud, Adobe publishes separate enforcement dates and may restrict traffic when requirements are not met. Merchants running Adobe Commerce elsewhere or Magento Open Source have a different contractual position, but unsupported software still creates an operational exposure. The hosting decision should follow the actual edition, deployment model and dependencies.
Intercube can assess the current store, design the supported target and operate its infrastructure after cutover. Migration to Intercube managed hosting is included without a separate migration fee. Application redevelopment, licences and third-party work remain distinct, so the migration plan can show exactly where effort and cost sit before delivery starts.
What to do before support ends
- Confirm the exact Commerce release and support phase for every environment.
- Include PHP, databases, search, queues, extensions and operating systems in the lifecycle plan.
- Treat security-only coverage as migration time, not a stable long-term baseline.
- Rehearse the upgrade, cutover and rollback with production-like data and integrations.
- Choose an operating owner who remains responsible after the migration project closes.