Adobe Commerce End of Life: Upgrade, Move to Adobe's Cloud Service, or Replatform?

Adobe Commerce end of life is no longer a future planning issue for teams still on 2.4.6. Standard support for Adobe Commerce 2.4.6 ended on August 11, 2026. Adobe Commerce customers have a limited extended-support window, while Magento Open Source does not receive those extended-support security patches. For most enterprise teams, the practical choice is now between upgrading to a supported Adobe Commerce release, moving to Adobe Commerce as a Cloud Service, or using the deadline as a trigger to replatform.

The right path depends less on the version number than on your custom code, integration estate, operating model, growth plans and appetite for another major platform change.

What does Adobe Commerce end of life mean in 2026?

Adobe does not use one single end-of-life date for every Commerce deployment. It separates standard support, extended support and, for some release lines, a limited security-only period. That distinction matters because a store can still be running while its support model, patch coverage and dependency requirements have materially changed.

As of September 2026, Adobe's current lifecycle schedule shows the following support windows.

The important detail is that Adobe's extended-support security patches are available to Adobe Commerce customers only. They are not available for the Magento Open Source code base. So the phrase "Magento 2.4.6 end of life" has a sharper implication for Open Source users than for licensed Adobe Commerce customers. Magento Open Source 2.4.6 no longer has the same extended-support runway, while Magento 2.4.7 reaches the end of its regular support window on May 31, 2027.

For Adobe Commerce on Cloud customers, the core application is only part of the deadline. Adobe now requires supported versions of PHP, MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and other platform dependencies. For Cloud environments on 2.4.6 or 2.4.7, Adobe has published dependency deadlines during 2026 and 2027, plus a June 1, 2028 deadline to upgrade to a supported Commerce release or move to Adobe Commerce as a Cloud Service.

That means "we still have support" is not a complete operating plan. You need to know which Commerce release you run, which dependencies sit underneath it, which extensions depend on them, and what Adobe's enforcement dates mean for your specific hosting model.

Upgrade, Cloud Service or replatform: the decision in one view

There are three credible paths. None is automatically right for every enterprise estate.

A useful principle is to separate deadline pressure from architecture quality. An Adobe Commerce end-of-life event creates urgency, but it should not force a rushed platform decision. If you are going to invest significant budget anyway, compare the cost of preserving the current estate with the cost of changing it.

Option 1: Upgrade to a supported Adobe Commerce release

An upgrade is usually the most contained path when Adobe Commerce still matches your business model, your custom functionality creates real value, and your team is comfortable owning application upgrades and platform dependencies. For Adobe Commerce on Cloud customers on 2.4.6 or 2.4.7, Adobe currently points to 2.4.9 or the latest supported release as the upgrade path.

The commercial attraction is continuity. Your product catalogue, merchandising model, admin workflows, integrations and much of your existing application architecture can stay conceptually familiar. That can reduce organisational disruption compared with a full SaaS migration or replatform.

But a version upgrade should not be treated as a Composer update and a weekend deployment. The work sits in the surrounding estate. Custom modules can rely on deprecated APIs. Third-party extensions may lag behind the target release. PHP and database changes can expose old assumptions. Search, queues, caches, cron jobs, payment modules, tax services, ERP connections and custom checkout logic all need regression testing.

For Commerce on Cloud, Adobe's current security policy also makes dependency hygiene part of the upgrade conversation. Teams on older PHP, MariaDB, Elasticsearch, OpenSearch, Redis or RabbitMQ combinations have separate remediation deadlines. Adobe specifically notes that migrations such as Elasticsearch to OpenSearch and Redis to Valkey can require custom code or configuration changes.

When an upgrade is the sensible path

Upgrade when the platform remains strategically useful, the custom estate is understood, and the business does not want to absorb a broader operating-model change right now. It is particularly defensible when your storefront is performing well, your integrations are stable, and the cost of rebuilding equivalent enterprise functionality elsewhere would outweigh the savings from simplification.

The caution is simple: upgrading buys supported runway, not freedom from future lifecycle work. Adobe Commerce on Cloud remains a PaaS model with shared responsibility for application-level patches, custom code, extensions and supported platform services.

Option 2: Move to Adobe Commerce as a Cloud Service

Adobe Commerce as a Cloud Service is a different operating model, not simply the next hosting tier. It is Adobe's multi-tenant SaaS Commerce offering. Adobe manages the core application, infrastructure and updates, and the platform is versionless from the merchant's perspective. That removes recurring core-version upgrade projects, but it also changes how customisation is built.

Adobe's migration guidance is explicit that existing Commerce stores cannot be lifted and shifted unchanged. Customisations and extensions must be adapted, storefronts are rebuilt on Edge Delivery Services, data is moved into the SaaS tenant, and external integrations are re-established using supported SaaS patterns.

That architectural change is the point of the product. Merchants do not modify core application code. Extensions move out of process through APIs, Adobe Developer App Builder, webhooks, events, API Mesh and UI SDKs. For teams carrying years of PHP customisation, this can be a healthy reset, but it can also make migration more involved than the phrase "move to the cloud" suggests.

Where Cloud Service can improve the operating model

The strongest case is operational. Adobe manages the core Commerce application and the underlying SaaS infrastructure, while updates arrive continuously. For a retailer whose engineering capacity is repeatedly consumed by patching, dependency upgrades and release regression, that can shift effort toward customer experience, merchandising, experimentation and integration work.

It can also suit organisations already invested in Adobe Experience Cloud that want tighter alignment with Adobe's current commerce architecture.

Where Cloud Service needs deeper due diligence

SaaS reduces some forms of technical ownership, but it also narrows others. Adobe's own feature comparison shows meaningful differences between PaaS and SaaS around complete data-model customisation, custom storage, email customisation and native search customisation. Some capabilities require App Builder or third-party services rather than direct database or application-level changes.

Migration tooling is also still evolving. Adobe's bulk data migration tool was listed as Early Access in July 2026 and currently focuses on first-party core Commerce data. Custom data is not automatically migrated, and configuration settings need separate setup. That makes a detailed inventory of custom entities, historical order data, loyalty logic, B2B workflows and integration state essential before committing to a timeline.

For a heavily modified enterprise implementation, moving to Adobe Commerce as a Cloud Service is best viewed as commerce modernisation, not hosting migration.

Option 3: Use the deadline to replatform away from Magento or Adobe Commerce

Magento replatforming becomes relevant when the support deadline exposes a larger problem: the organisation is spending heavily to preserve an architecture that no longer matches how it wants to trade, expand or operate. In that case, upgrading can solve lifecycle risk while leaving the strategic mismatch untouched.

A replatform can make sense when teams want a simpler ownership model, faster release cycles, lower dependence on custom backend code, a different B2B or DTC operating model, or a cleaner base for multi-market expansion. The business case should be built around total operating effort and future capability, not licence cost alone.

The cost surface is broader than most platform comparisons suggest. Product and customer data, order history, promotions, search, subscriptions, loyalty, payments, tax, ERP, PIM, OMS, WMS, CRM, analytics and consent tooling may all be involved. URL structures, redirects, metadata and structured data also need a controlled SEO migration plan.

For teams evaluating this route, Autumn's enterprise commerce migration and replatforming work focuses on the wider ecosystem rather than the storefront alone. If Shopify Plus is one of the platforms under consideration, this Magento to Shopify Plus migration guide covers some of the migration questions that become especially relevant for UAE and GCC brands.

The key is not to replatform because Magento is "old" or because SaaS is fashionable. Replatform when the target operating model is materially better for the next three to five years.

How should an enterprise choose between the three paths?

Start with the estate you actually have, not the platform you think you have. Large Adobe Commerce builds often contain years of invisible business logic spread across extensions, integrations, middleware, scheduled jobs, data feeds and manual admin processes. A decision made from the storefront alone will miss the expensive parts.

Use this checklist before approving a path:

• Map the current Commerce version, hosting model, PHP, database, search, cache and queue dependencies.

• Inventory custom modules and classify each one as keep, replace, retire or redesign.

• List all third-party extensions and confirm target-version or SaaS compatibility.

• Map ERP, PIM, OMS, WMS, CRM, payment, tax, loyalty and customer-service integrations, including data direction and failure handling.

• Measure the current cost of upgrades, incidents, infrastructure, support, releases and technical debt, not only Adobe licensing.

• Identify the business capabilities required over the next three years, including B2B, DTC, internationalisation, Arabic, multi-currency, omnichannel and new storefronts.

• Model migration risk around peak trading periods, SEO, customer accounts, historical orders, analytics continuity and rollback.

Once that inventory exists, the choice becomes clearer. If most complexity is valuable and Adobe remains the right core, upgrade. If Adobe remains strategically right but platform maintenance is the problem, assess Cloud Service. If a large share of complexity exists only to work around the platform, a replatform deserves serious comparison.

Do not ignore the dependency clock

One of the easiest mistakes is to plan around the Adobe Commerce 2.4.6 end-of-support date while ignoring the software underneath it. Adobe's lifecycle policy explicitly states that third-party dependencies can reach end of life before the Commerce support window ends, and Adobe does not provide fixes for those third-party products.

This matters operationally and for compliance. Adobe notes that PHP 8.1 reached end of life on December 31, 2025, and that PHP 8.2 reaches end of life on December 31, 2026. For merchants still using affected combinations, Adobe warns that unsupported PHP can put PCI compliance at risk and recommends assessing the position with a qualified security assessor.

So a 2027 platform roadmap can still require action in 2026. The dependency layer can create earlier work than the headline Commerce date suggests.

What changes for UAE, Saudi and GCC commerce teams?

The platform decision is global, but GCC implementations often carry regional complexity that deserves its own discovery pass. A migration can affect Arabic and English storefront behaviour, local payment methods, regional gateways, tax configuration, multi-currency pricing, ERP and warehouse integrations, store pickup, marketplace feeds and customer-service workflows.

For brands operating across the UAE, Saudi Arabia and other GCC markets, the danger is treating those capabilities as post-migration configuration. They are architecture requirements. Payment authorisation flows, catalogue segmentation, fulfilment logic and Arabic customer journeys should be validated before the target platform is selected, not after contracts are signed.

This is also where a platform deadline can become useful. It creates a natural point to remove old extensions, collapse duplicate integrations and redesign processes that have accumulated through years of regional expansion.

A practical 90-day response to Adobe Commerce end of life

The first 30 days should be discovery. Confirm the exact release and patch level, map dependencies, run compatibility analysis, catalogue custom modules and extensions, and document integrations. At the same time, identify business changes already planned for the next 18 to 36 months. A platform decision without the growth roadmap is incomplete.

Days 31 to 60 should compare architectures and costs. Build one scenario for an Adobe Commerce upgrade, one for Adobe Commerce as a Cloud Service, and one replatform scenario only if the business case is credible. Compare delivery effort, annual operating effort, migration risk, feature fit, internal skills and time to value. Avoid comparing a one-off upgrade quote with a five-year SaaS transformation model. Use the same time horizon.

Days 61 to 90 should turn the preferred direction into a migration plan with environments, data strategy, extension replacement, integration sequencing, test coverage, SEO controls, cutover approach and rollback. If peak season is close, separate immediate security work from the larger transformation so urgency does not force a bad launch window.

FAQs

Is Adobe Commerce 2.4.6 end of support already here?

Yes, standard support for Adobe Commerce 2.4.6 ended on August 11, 2026. Adobe Commerce customers have extended support through August 31, 2027, followed by a limited security-only period through May 31, 2028. Those extended-support patches are not available to Magento Open Source. If you are on Adobe Commerce on Cloud, you also need to meet Adobe's separate dependency and version-enforcement deadlines rather than relying only on the extended-support date.

When is Magento 2.4.7 end of life?

Adobe's current lifecycle schedule lists May 31, 2027 as the end of standard support for the 2.4.7 release line. Adobe Commerce customers receive extended support through May 31, 2028. Magento Open Source does not receive Adobe's extended-support security patches, so Open Source teams should plan around the regular support window and move to a supported release before that protection ends.

Is Adobe Commerce as a Cloud Service the same as Adobe Commerce on Cloud?

No. Adobe Commerce on Cloud is Adobe's PaaS model, where Adobe manages the hosted platform but the merchant still owns application updates, custom code, extensions and many platform-service responsibilities. Adobe Commerce as a Cloud Service is SaaS. Adobe manages the core application and updates, and merchants extend the platform through APIs and out-of-process tools rather than modifying core code.

Can we move our existing Adobe Commerce site directly to Cloud Service?

Not as a lift-and-shift migration. Adobe says a migration to its SaaS offering requires adaptation across the application, data, storefront and integrations. Existing customisations are typically reworked into App Builder or other supported extension patterns, the storefront is rebuilt on Edge Delivery Services, and integrations are re-established. The effort depends heavily on how customised your current implementation is.

Should we upgrade to 2.4.9 or replatform now?

Choose based on strategic fit, not the deadline alone. If Adobe Commerce still supports your operating model and the custom estate creates useful differentiation, upgrading to a supported release can be the lower-change path. If the organisation is using repeated upgrades to preserve workarounds, expensive customisations or an operating model it no longer wants, compare a replatform on a multi-year cost and capability basis before committing.

Does Adobe Commerce 2.4.6 extended support remove the urgency?

No. It gives licensed Adobe Commerce customers more planning time, but it does not remove dependency, security or transformation work. Platform components can have earlier end-of-life dates, and Adobe Commerce on Cloud customers face separate enforcement deadlines for supported dependencies and supported Commerce versions. Treat extended support as runway for a controlled transition, not a reason to defer discovery.

Plan the transition around the business, not the deadline

Adobe Commerce end of life should trigger a decision, but not dictate one. The better question is what commerce architecture will support the next phase of growth with the least unnecessary operating drag.

Autumn is an AI-first commerce transformation company. It helps growth-stage and enterprise brands modernise commerce operations, improve revenue performance, build scalable commerce ecosystems and expand across GCC and global markets.

If your team is deciding between an Adobe Commerce upgrade, Adobe Commerce as a Cloud Service and a wider replatform, a migration-readiness assessment or commerce architecture review can surface the real cost and risk before you commit to a delivery path.