Adobe Commerce 2.4 end of support options

What the Adobe Commerce 2.4 end of support deadline means for your store

If your store runs a 2.4 release whose standard support has ended or is about to end, you have three real paths: stay on a supported 2.4 line, move to Adobe Commerce as a Cloud Service, or leave for Magento Open Source, Mage-OS or Shopware. The right choice depends on which release you run today, how much of your store depends on Adobe-only features, and how much change your team can absorb before the next deadline. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The end of regular support falls on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Confirm these dates against your own Adobe contract and order documents, since your entitlement and any extended terms may differ from the public policy.

Adobe Commerce, Magento Open Source and Mage-OS share one codebase, so an upgrade within the 2.4 line or a step down to Open Source keeps your existing modules, data model and theme layer in play. Adobe Commerce adds paid modules and services on top of that code, and Magento Open Source does not include them. Shopware is a different platform with its own data model, extension system and theme technology, so moving to it is a re-platforming project, not an upgrade. That distinction should drive the first internal question: do you need to stay on the Magento codebase, or are you willing to rebuild on another platform? Start by listing the Adobe-only modules and services your store uses, then check which release line each one supports.

Before you pick a path, confirm three things: your exact installed version, your Adobe contract terms for support after the policy date, and the system requirements for the target release, since PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions change between lines. Ask Adobe, your partner or your hosting provider which release line your current contract covers and what it includes. Record the answers in a written decision memo with a named owner, so the deadline is tracked alongside security patch cadence and budget cycles rather than discovered in an audit.

What staying supported requires from your stack

The end-of-support deadline is only the first constraint. Staying on any 2.4 release means keeping the platform, its patch cadence and its runtime components current together. Check each item below against your production versions before choosing between upgrade, Cloud Service or switch.

A supported release line

Each 2.4.x release gets three years of standard support from general availability. Standard support for 2.4.6 ends on August 11, 2026, 2.4.7 on May 31, 2027, 2.4.8 on May 31, 2028 and 2.4.9 on May 31, 2029. Confirm which release your store runs today and which end date applies to it. A store on 2.4.6 has the nearest deadline, so plan the target release before the date rather than after it.

Annual patch and security cycle

Adobe ships a full patch for the 2.4.x LTS line annually in May, and security patches at least once a year for every supported line. Patches arrive on a fixed calendar, so your team needs a staging environment and a test cycle ready to absorb them. Ask who in your organization owns applying patches, how long a patch takes to reach production, and whether your extensions are tested against each patch.

Pinned runtime component versions

The 2.4.9 requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so a mismatched database or search engine can fall outside support even if the application runs. Compare every component with your current versions and note any that need an upgrade before the platform does.

Varnish 8 or Fastly for caching

Self-managed installations use Varnish as the full-page cache accelerator, and the 2.4.8-p5 requirements list Varnish 8. Cloud-hosted Adobe Commerce uses Fastly instead, so the cache layer is not your responsibility there. If you run self-managed, confirm your Varnish version and its VCL configuration against the supported combination. Cache changes also affect how the storefront behaves under peak traffic, so test them on staging.

Content Security Policy restrict mode

Adobe Commerce and Magento Open Source support Content Security Policy headers from 2.3.5. From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages, so scripts and frames that worked before can be blocked. Review every third-party payment script, analytics tag and custom theme script on those pages. Ask your payment providers whether their embedded elements are listed in your policy.

Which option meets the deadline for your store

This table compares five paths against Adobe's 2.4 support dates and the release lines that remain supported. Read the middle column for how each option meets the requirement and the last column for what you give up or must confirm. The main takeaway is that an upgrade keeps your current codebase, while moving to Shopware is a re-platforming project.

Option	How it meets the support requirement	Trade-offs and what to confirm
Upgrade to Adobe Commerce or Magento Open Source 2.4.9	Moves the store to a release line with standard support until May 31, 2029, per Adobe's lifecycle policy.	Requires PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3 and other listed versions. Test extensions on staging first.
Adobe Commerce as a Cloud Service	Adobe hosts and updates the platform, which removes most self-managed upgrade work.	Fastly replaces self-managed Varnish. Confirm the support window, update schedule, storefront options and pricing with Adobe in writing.
Mage-OS 3.6.0, based on Magento Open Source 2.4.9	Community distribution on the 2.4.9 codebase. Security patches are ported from Adobe bulletins, such as APSB26-153.	Independent nonprofit, not associated with Adobe, so Adobe support does not apply. Confirm extension compatibility and who supports you.
Magento Open Source 2.4.9 on your own infrastructure	Same 2.4.9 codebase under OSL-3.0, with no Adobe commercial license and no Adobe-hosted cloud.	Adobe Commerce-only modules must be removed or replaced by extensions. Confirm Adobe's security patch coverage for Open Source before you rely on it.
Shopware, MIT licensed	Moves the store to a different platform, so the Adobe 2.4 deadline no longer applies to it.	Free Community Edition applies below 1 million euros gross merchandise value over 365 days. Community Edition support is community only.

What upgrading to 2.4.9 changes in your environment

Staying on the 2.4 line means moving to 2.4.9, or to 2.4.8-p5 if the store cannot yet make the larger jump, and rebuilding the runtime around the versions Adobe lists for that release. The system requirements for 2.4.9 name PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64, and Adobe supports only those listed combinations. Compare each item against your current stack in a staging environment, and confirm with Adobe which combinations apply to your hosting model before you order infrastructure changes. Do not assume that a server image that ran 2.4.6 will carry over unchanged.

Extensions, themes and custom modules are the largest unknown. Each third-party package and in-house module needs to be checked against the new PHP and framework versions, and against any core changes in the 2.4.9 release notes, which are linked from the Adobe release pages. Ask each extension vendor for written confirmation of 2.4.9 support, and keep a list of modules that have no vendor answer. Adobe does not guarantee that custom code runs without change, so budget test time for checkout, B2B flows and admin workflows on staging. If you run on Adobe's cloud, the move from Varnish to Fastly as the full-page cache changes how cache rules and purge logic are written, and self-managed stores keep Varnish, so confirm which applies to you.

Content Security Policy also changes behavior. From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages, so inline scripts and third-party payment or analytics tags that were allowed before may now be blocked. Review your policy headers and payment integrations early, and test each payment method end to end. Magento Open Source 2.4.9 also adds the clearCart GraphQL mutation, which previously belonged only to Adobe Commerce. If your headless storefront or custom integration works around that gap, you may be able to simplify it, but confirm the mutation's behavior in your own test cart flows before relying on it.

Comparing the three exit paths by who runs the platform

Staying on Adobe keeps the platform, hosting and patch schedule with Adobe, either by upgrading self-managed 2.4 installations to a supported release or by moving to Adobe Commerce as a Cloud Service. Adobe's lifecycle policy gives 2.4.8 standard support until May 31, 2028 and 2.4.9 until May 31, 2029, and each 2.4.x line receives security patches at least annually. Your team still owns the store's code, extensions, data and the customizations built on top.

Patching: Adobe publishes security patches for supported lines, but on self-managed installations your team or partner applies them and tests them against your extensions.
Upgrade effort: The 2.4.9 requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3 and Redis or Valkey 9. Each change to that stack can affect extensions, so plan testing for each component.
Cloud Service ownership: Adobe runs the hosting and applies updates. Confirm which code changes you can make, how custom modules are reviewed and which storefront options are available.
Cost drivers: License and hosting fees recur every year. Ask for renewal terms, the support tier and the price of additional environments in writing.
Exit path: Catalog, order and customer data remain on Adobe's stack. Ask how you would export them if you leave later.

Before committing, ask Adobe or a partner to confirm which edition, hosting option and support level match your extensions and storefront.

How to plan the move before the next deadline

This sequence turns the end of support dates into a dated, tested migration path, so each option (upgrade, Cloud Service or switch) is judged on the same inventory and staging evidence before any production change.

Inventory the current release and stack
Record the installed Adobe Commerce or Magento release, the PHP version, the database (MySQL or MariaDB), the search engine (OpenSearch), the cache (Redis or Valkey, plus Varnish or Fastly if used), the message queue (RabbitMQ) and the Composer version. Compare each item against the system requirements for the release you plan to target, because Adobe supports only the listed combinations. The deliverable is a version matrix signed off by the platform owner, with any gaps flagged.
List Commerce-only modules and extensions
Export the list of enabled modules and every third-party extension, then mark which ones depend on Adobe Commerce features such as B2B, staging, or Commerce-only GraphQL mutations. Check each extension against the vendor's compatibility statement for the target release. Ask the vendors in writing which versions they support. The deliverable is a register with one row per module showing its owner, its license, its target replacement or retirement decision, and the vendor's written answer.
Choose the target line and confirm its support date
Pick the destination: a supported 2.4 release, Adobe Commerce as a Cloud Service, Magento Open Source, Mage-OS or Shopware. Confirm the end of support date for the chosen release in Adobe's lifecycle policy or in the vendor's own published policy, rather than relying on memory or secondhand notes. Note which patches are provided and who issues them. The deliverable is a decision record naming the target, its support end date and the owner of security patching after cutover.
Build a staging environment on the target stack
Provision a staging environment that matches the production topology: web nodes, database, search, cache, queue and the CDN or full-page cache layer. Use the exact versions from the target system requirements. Load a sanitized copy of production data and confirm that the storefront, admin and checkout respond. The deliverable is a staging environment with a build record that lists every version and a smoke test result.
Run the chosen migration path in staging
For a Mage-OS move, first update to the latest Magento Open Source release, then run the Mage-OS migration script in staging, which swaps the Magento product packages for Mage-OS packages. Then run setup:upgrade, compilation, static content deployment and reindexing, in that order. For an upgrade within 2.4 or a move to Adobe Commerce as a Cloud Service, follow the matching upgrade guide instead. Record each command and its output. The deliverable is a runbook with the exact commands, the duration measured on staging, and any errors with their fixes.
Test extensions and themes on staging
Run functional tests for checkout, pricing, tax, customer accounts, catalog search and any integrations (ERP, payment, shipping, tax). Compare the output of key pages and API calls with production. Check Content Security Policy behavior on payment pages, since restrict mode is the default from 2.4.7. Treat the migration guide's statement that extensions should work with little or no change as a hypothesis to verify, not a guarantee. The deliverable is a signed test report with each failure logged, assigned and retested.
Keep the documented rollback ready
Before cutover, take a full database and file backup of production, and confirm that a restore works on a separate host. If you are moving to Mage-OS, document the rollback path: restore the database and files from backup, then point Composer back to magento/product-community-edition. Assign who can start the rollback and the criteria for starting it. The deliverable is a tested rollback procedure with a recorded restore, ready before the production change window opens.

How the patch cadence changes your security work

The patch cadence you can expect depends on which release line you run, and that decides how much of the security work falls on your team. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, while security patches are released at least annually for all supported release lines. Read those two statements as a floor, not a schedule. Between full patches, a 2.4.x store relies on security fixes that arrive on their own timing, so an annual full patch alone will not tell you when a vulnerability is closed. Confirm the exact delivery terms for your contract or licence with Adobe, and whether out-of-cycle hotfixes are included, before you plan a maintenance window.

Mage-OS shows what a community distribution looks like in practice. Its 3.5.0 release on September 8, 2026 was an emergency security release that ported Adobe's hotfix for CVE-2026-75650, and mage-os.org advised that patching alone was not enough and pointed to remediation steps. Its 3.6.0 security release, dated October 14, 2026, is based on Magento Open Source 2.4.9 and ports Adobe's October isolated patch, security bulletin APSB26-153. Those dates show that a distribution depends on upstream Adobe fixes and then has to port them. Ask the Mage-OS Association, through its Mage-OS release notes, how long the porting takes and who is notified when a hotfix lands.

Build the patch process before you choose the platform. Assign an owner for watching Adobe bulletins and Mage-OS releases, write a rule for when an emergency patch goes to production without a full regression run, and keep a staging environment that mirrors your payment and Content Security Policy settings. Confirm with your vendor or community the typical lag between an upstream fix and a downloadable patch, whether security notices come by email or feed, and which party carries the cost of out-of-cycle work. If you run your own infrastructure, those costs are yours to budget.

Evidence to keep for the upgrade and patch record

A security or compliance reviewer will ask for the same core set of records after any end-of-support move, whether the store is upgraded in place, moved to the Cloud Service or switched to another platform. The cards below cover what each record should contain and what to check before it is filed. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any attestation.

Component version inventory

Record the PHP, database, search, cache, message queue, Composer, web server and Varnish versions before and after the move, and the Magento or Adobe Commerce release on each side. Compare them against the system requirements for the target release, since Adobe supports only the listed combinations. Keep the inventory with the Composer lock file and the exact image or package hashes used in each environment, so a reviewer can rebuild the state at any date.

Staging test results for extensions

Keep a dated test log for every third-party extension, theme change and custom module, run on staging against the target release. Include payment flows, tax, shipping, checkout, order emails and admin tasks, with pass or fail results and the tester's name. Extensions that are abandoned or lack a supported version for the new PHP release should be flagged here as open risks with an owner and a decision date.

CSP configuration and test results

Document the Content Security Policy headers the store sends, the policy mode on storefront and admin payment pages, and every exception added for a payment provider or analytics tag. Record the browser test results for checkout and admin pages before and after the move. Adobe's developer documentation states that restrict mode is the default from 2.4.7, so a reviewer will expect to see who approved each relaxation.

Backup and rollback test record

Keep the date, scope and result of a restore test that rebuilds the database and file system from backup into a separate environment. Show that the rollback path works, including the Composer change back to the original package, and record the time taken and the data checks run afterward. A backup that has never been restored is not evidence for a reviewer, so store the restore log alongside the backup job configuration.

Patch and change log tied to bulletins

Maintain one change log that links each patch to the vendor security bulletin or release note it addresses, the environment where it was tested and the production deployment date. For Adobe Commerce, this means the bulletin identifiers and the patch versions published for each release line. For community distributions, record the upstream release each patch was ported from, so the chain back to the original advisory stays visible.

Cutover sign-off record

Capture the signed approval for the cutover from the business owner, the engineering lead, the security owner and the person accountable for payment and personal data. Attach the go or no-go checklist, the final test summary and the list of known issues accepted at cutover, each with an owner and a review date. Confirm with your own auditor which signatures and retention period your framework expects.

What does an Adobe Commerce end-of-support upgrade cost and take?

What drives the cost of moving to 2.4.9, the Cloud Service or a self-hosted distribution?

The biggest cost difference comes from who pays for hosting and licensing, and who carries the upgrade work. Staying on Adobe Commerce means an Adobe license and, if you use Adobe's cloud, hosting fees set by Adobe. Moving to Magento Open Source or Mage-OS removes the license line, but you pay for your own infrastructure, security patching and the developers who maintain the store. Moving to Adobe Commerce as a Cloud Service changes the hosting model and the upgrade model together. Ask each vendor for its own written pricing and do not compare totals until every option is quoted on the same scope, extension list and traffic assumptions.

How long does an end-of-support upgrade take and what sets the duration?

The duration depends on the number of custom modules, third-party extensions, theme work, integrations and the amount of data to test, not on the version number alone. Adobe publishes release dates, so the deadline is fixed, but the work to reach a supported line varies by store. For example, a store with a small set of well-maintained extensions usually needs less testing than one with custom checkout code and many ERP integrations (illustrative). Ask the vendor or DeployOpen for a timeline that lists each phase, the environments used and the dependencies that must be resolved before work starts.

What does the upgrade need from our own team?

You need named people who own the business rules, the catalog, the payment and tax setup, and each integration. Your engineers must be able to provide staging environments that match production, access to code repositories, and a list of cron jobs, queues and third-party services. Someone from operations must approve the hosting changes, and someone from finance or merchandising must sign off on test orders and pricing. Confirm these responsibilities in the written scope so that testing does not stall while people are reassigned.

Can a store owner or small in-house team do the upgrade without outside help?

A capable in-house team can do an upgrade on a simple store, but the risk rises with custom code, payment integrations and the number of extensions that have not been updated for the target release. Adobe's system requirements for 2.4.9 list specific PHP, database, search, cache and queue versions, and Adobe supports only the listed combinations, so the environment work is a real technical task. Mage-OS also requires a specific Composer version and a staging rehearsal before cutover. Decide early whether your team has the time, the skills and the rollback plan to carry the work alone.

What should we ask for in a written quote?

Ask for a written scope that lists each deliverable, the target platform and version, every extension and custom module in scope, the environments to be built, the testing approach and the acceptance criteria. The quote should separate one-time work, such as the upgrade, data migration and testing, from recurring costs, such as hosting, extension licenses, security patching and support retainers. Ask what is excluded, who signs off on cutover, and how change requests are priced. Request the same scope from each option you are considering so the numbers can be compared fairly.

How is an engagement scoped with DeployOpen?

Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work starts. The scope usually covers the target platform, the components to be planned, implemented, integrated, hardened and documented, the backup and rollback approach and the testing. Where the upgrade depends on security testing or compliance readiness, those items are listed separately so their cost is visible. Ask DeployOpen to show how the scope maps to your extension inventory and your environments before you sign.

What happens after cutover, and what recurs?

After cutover, the store needs ongoing patching, monitoring, backups and periodic upgrades, and these costs recur for as long as you run the platform. Adobe publishes a yearly full patch for the 2.4.x LTS line and security patches at least annually, so budget for regular patch windows. Ongoing support, upgrades and continuous testing can be bought as a retainer from DeployOpen, and the retainer scope should state response expectations and what happens when an extension breaks after a patch. Ask for the handover documentation and a post-cutover support plan as part of the written scope.

How DeployOpen plans and deploys an end-of-support move

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an end-of-support decision can be made on a written scope rather than a sales pitch. We start by confirming which Adobe Commerce 2.4 release you run, which Commerce-only features you depend on, and whether the next step is an upgrade, a move to Adobe Commerce as a Cloud Service or a switch to Magento Open Source, Mage-OS or Shopware.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We inventory your installed 2.4 release, PHP and database versions, extensions and Commerce-only modules against Adobe's published requirements.
We confirm which deadline applies to your release, using the dates in Adobe's lifecycle policy, and record the options under review.

How we build

We rebuild the target environment in a staging copy of your store, matching your hosting, search, cache and queue services.
We test extensions and customizations on staging, including checkout, payment callbacks, customer accounts and admin workflows.
We review Content Security Policy, cache configuration and patch levels as part of hardening before any cutover.

How we hand over

You receive documentation of the deployed architecture, configuration, data migration steps and the tested rollback path.
Cutover is rehearsed on staging with a dated checklist, and the rollback procedure is walked through with your team.
We deliver evidence of controls and test results to support your own compliance assessment, which independent auditors perform.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
A retainer can cover applying vendor and community security patches to your chosen platform on a schedule you approve.
Ask any provider, including us, to confirm response times, patch windows and who is responsible for each layer in writing.

Adobe Commerce 2.4 end of support: upgrade, move to the Cloud Service or switch