Magento upgrade service: get current without breaking checkout.

Which Magento versions are still supported?#

As of October 16, 2026, Adobe's lifecycle policy puts 2.4.7, 2.4.8 and 2.4.9 in standard support, 2.4.6 in extended support, and 2.4.4 and 2.4.5 in a security-only period that ends May 31, 2027. Releases older than 2.4.4 are not in Adobe's table at all.

The PHP, search and database columns come from Adobe's on-premises system requirements for the newest release listed in each line that day, 2.4.4-p18 through 2.4.9, and Adobe "supports only the system requirement combinations listed." On Adobe Commerce on Cloud, Adobe lists OpenSearch only and no MySQL.

Extended support, in Adobe's words, means "quality and security patches for the core application," offered "at no additional cost for Adobe Commerce customers." The security-only period "provides limited isolated security fixes only (no quality fixes)" and is "a one-time exception" that "will not be extended beyond the published dates."

Three catches sit under those dates:

Update or upgrade: what the work involves#

An update moves you to a newer patch inside your release line. An upgrade moves you to a new release line. Magento 1 to 2 is a migration, covered further down. Each step drags in more of the stack.

Security patch release (2.4.x-pN), for example 2.4.7-p9 to 2.4.7-p10. Adobe ships these at least once a year for every supported line (2026's came on March 10 and May 12), and its upgrade guide is blunt: "To remain PCI-compliant, merchants must be on the latest patch or security patch." Between those releases come monthly isolated security patches, "tested exclusively against" the newest -p release of each line and applied "cumulatively, in release order." As of October 16, 2026, the CVE-2026-75650 hotfix isn't in the October file and must be applied separately. So 2.4.7-p10 on its own, or a plain 2.4.9, is not fully patched.

The -p releases aren't small anymore. Adobe's on-premises requirements for 2.4.7-p9 list MySQL 8.0 and Redis 7.2; for 2.4.7-p10, both read "Not supported," which leaves MariaDB 10.11 or 11.8 and Valkey 8.1. On the 2.4.6 line, p15 drops Elasticsearch 7.17 and lists only OpenSearch 2.19 or 3. Adobe gives its reasons on the same page: MySQL 8.0 reached end of support on April 30, 2026, and Elasticsearch 7.17 on January 15, 2026.

Release-line upgrade, for example 2.4.6 to 2.4.8. On-premises, PHP and the database always move: PHP from 8.1 or 8.2 to 8.3 or 8.4, the database to MariaDB 11.4 or 11.8 or MySQL 8.4. Search and cache move too unless you're already on 2.4.6-p15's OpenSearch 3 and Valkey 8.1. Every extension and theme override built against the old core has to follow.

Smaller than both: Adobe's Quality Patches Tool "delivers individual patches developed by Adobe and the Magento Open Source community." One fix, no version change.

How we run a Magento 2 upgrade without breaking extensions#

Extensions and themes survive an upgrade when every one of them is checked against the target release before anyone runs Composer. Our method, in order:

1. Audit. Every module in composer.json and app/code, every core override (preferences, plugins, copied templates), and the PHP, search, database and cache versions on each environment. You get the findings in writing.
2. Compatibility scan. On Adobe Commerce we run Adobe's Upgrade Compatibility Tool, which checks a customized instance "against a specific version by analyzing all modules and core code installed in it." Adobe makes it "available for Adobe Commerce instances only," so on Magento Open Source we cover the same ground with public tools: the Magento Coding Standard and its PHP compatibility rules, static analysis run against the target version's core code, a diff of the core changes against every override, and a full compile on the target version.
3. Vendor checks. For each third-party module, a release that supports the target line and PHP version, confirmed from the vendor's changelog or Composer constraints. No release? We replace the module, or port it as part of our Magento development work.
4. Staging upgrade. A copy of production (code, database and media) upgraded with Composer on the target PHP, search engine, database and cache, then every isolated security patch and hotfix released for the target version, applied in order, then bin/magento setup:upgrade, setup:di:compile and setup:static-content:deploy, with every PHP deprecation logged.
5. Regression tests. Checkout first: every payment and shipping method you use, guest and logged in, with coupons and tax. Then the integrations (ERP, shipping, tax and marketplaces), cron, queue consumers, search, and the admin flows your team relies on.
6. Deploy with rollback. The patched code compiles and static content builds before the switch, the database is backed up at cutover, and the rollback plan is written before the release, not during it.

Once the new stack is live, we profile it: an upgrade changes the PHP, database and cache under every page. Our receipt for that kind of work: server response times cut from seconds to milliseconds.

Patch now, upgrade later#

You can stay on your version while the known holes get closed. We backport the security fixes Adobe no longer ships for your release, then upgrade you on your schedule. It lowers the risk. It doesn't remove it, and it doesn't fix an end-of-life PHP.

As of October 16, 2026, five Adobe Commerce and Magento bugs are in CISA's catalog of known exploited vulnerabilities, two of them added in September 2026. Three of them:

The NVD records for CosmicSting and SessionReaper end their lists of affected versions with "and earlier." For SessionReaper, Adobe's hotfix covers Adobe Commerce from 2.4.4 and Magento Open Source from 2.4.5. For anything older, its only advice is to "upgrade to the latest security patch."

That's the job. We backport the fix to your exact version, test it on a copy of your store, deploy it with a rollback plan, and harden around it: admin access locked down, WAF rules against known exploit patterns as a stopgap, and, when the bug can leak the encryption key, the key and every credential it protects rotated as part of the fix, sign of entry or not. The standard we hold it to: pen-test findings closed and retested against every bypass variant we could throw at them.

Fixes first. Upgrade second.

TodayUnsupported versionNo Adobe fixes for your release line

backport

Phase oneSame version, patchedFixes backported, tested on a copy of your store

upgrade

Phase twoSupported 2.4.xUpgraded when you're ready

Backports that help more than one store will be published on our free Magento security patches page, each listing only the exact versions it was tested on. If someone got in before the fix did: Store hacked or down?

Stuck on an old version? We'll patch you now and upgrade you when you're ready.

What breaks in an upgrade, and how we catch it#

The usual suspects, and the check that catches each one on staging:

Upgrading from Magento 1#

Yes, but it's a migration, not an upgrade: Magento 2 is a different codebase, so nothing installs over the top. Adobe's Data Migration Tool is "a command-line interface (CLI) tool used for transferring data from Magento 1 to Magento 2." Your theme and custom code stay behind; in Adobe's words, "developers must make changes to their themes and customizations." Extensions need Magento 2 versions or replacements. We run it as a replatform: data mapped, theme rebuilt, and the full redirect map built before cutover.

Why Magento upgrade quotes vary so much#

There's no honest number before an audit. Seven things drive the work, and two quotes for the same store can cover very different amounts of each:

• The version gap. 2.4.7-p9 to 2.4.7-p10 is a patch, even if it moves your database. 2.3.x to 2.4.8 crosses PHP, search, database and cache.
• Extension count and quality. Each one needs a compatible release, a replacement or a port.
• Custom modules. Each one gets checked against the new PHP and the new core.
• The theme. Luma with overrides, Hyvä, or fully custom.
• Integrations. ERP, shipping, tax and marketplace connections each need a regression run.
• Hosting. Who controls the PHP, database and search versions, and whether Adobe's Cloud deadlines apply.
• Test coverage. Automated tests shrink the regression work. None means writing the checklist first.

Ask every bidder which target versions, which compatibility scan and which regression list their quote covers. If the answers differ, so will the numbers. For what the market typically charges, with sources, see our guide to Magento costs.

Upgrade or migrate?#

If Magento still fits the business, an upgrade is usually the cheaper honest answer: it keeps your data model, B2B features, integrations and URLs. It stops being the honest answer when the store needs a rebuild anyway, say custom code nobody can maintain on a line Adobe has dropped, or when the catalog and checkout are simple enough that a hosted platform takes platform patching off your plate. If that's you, compare both properly: upgrade or move to Shopify. We build both, so we can tell you which wins.