Adobe Commerce Upgrade Planning: Support Windows, Timelines, and the August 2026 Deadline

If your store runs Adobe Commerce 2.4.6 or 2.4.5, you have a hard date on the calendar: August 11, 2026. On that day, both release lines stop receiving security and quality fixes, per Adobe’s published lifecycle policy. That is not a soft nudge to upgrade eventually. It is the day your platform stops getting patched while attackers keep working.

We plan and run these upgrades for mid-market merchants, and the pattern we see is always the same. Teams that treat the version calendar as a maintenance schedule do quiet two-week upgrades. Teams that ignore it end up doing expensive rescue projects with a deadline on their neck. This piece lays out the actual dates, what an upgrade takes, and how to get on the calm side of that line.

Which Adobe Commerce versions are still supported in 2026?

As of July 2026, three release lines have regular support: 2.4.9, 2.4.8, and 2.4.7, with 2.4.6 hanging on until August 11. Adobe supports each release line for three years from its general availability date, and the current windows are all listed on Adobe’s released versions page:

Two details in that table deserve attention. First, 2.4.9 shipped on May 12, 2026, so there is now a release line with support into 2029, which changes the math on where an upgrade should land. Second, 2.4.5 only reaches August 2026 because Adobe granted it a free one-year extension, and that extension applies to Adobe Commerce customers only, not Magento Open Source. If you run Open Source on an old line, your real end-of-support date already passed.

What actually happens when your version loses support?

Nothing breaks on day one. What changes is that new vulnerabilities stop getting fixed for your line, and that gap compounds every month you stay. Adobe ships security patches on a steady cadence, five times in the last fourteen months for the 2.4.6 line alone, ending at 2.4.6-p15 in May 2026, according to the same Adobe release history. After August 11, that line goes silent while 2.4.7, 2.4.8, and 2.4.9 keep receiving fixes for the same newly discovered holes. Attackers read patch notes too. Every fix published for supported lines is a map of what remains open on yours.

The CosmicSting vulnerability is the case study worth remembering. It scored a 9.8 out of 10 on the CVSS severity scale, and more than 4,000 stores were breached through it, including brands the size of Ray-Ban, National Geographic, and Segway. Security firm Sansec, which tracked the campaigns, put the toll at 5 percent of all Adobe Commerce and Magento stores. The uncomfortable part: those breaches happened after a patch existed. Sansec’s earlier research found that a week after Adobe shipped the fix, roughly three quarters of stores still had not applied it. That was the damage on stores that could patch and simply had not yet. A store on an unsupported line does not even get the patch.

There is a second, quieter cost. Adobe does not provide fixes for the third-party stack underneath your store, and old Commerce lines pin you to old dependencies. The 2.4.6 line runs on PHP 8.1 and 8.2, while 2.4.8 runs on PHP 8.3 and 8.4, per the same lifecycle table. Stay behind long enough and your PHP version, your database, and half your extension vendors leave you before Adobe does. We wrote about how that end state plays out for the stores still running Magento 1 after its patches stopped, and it is not a story you want to repeat.

How long does an Adobe Commerce upgrade take?

In our engagements, a clean minor upgrade on a well-maintained store runs two to four weeks from kickoff to production, and a neglected store doing a multi-version jump runs six to ten. The official upgrade process is composer-driven and looks small on paper. The calendar time goes somewhere else entirely: extension compatibility, custom code, and testing.

The honest breakdown from stores we have upgraded, mid-market catalogs with 20 to 40 third-party extensions:

The upgrade commands are the cheap part. The expensive part is that some of your extension vendors will not have a compatible release ready, and each of those becomes a decision: update, patch, replace, or delete. Even core composer dependencies have tripped stores during version transitions, a failure mode the Magento community has documented in public GitHub issues more than once. This is why we scope the audit before quoting the upgrade, never the other way around.

Why do stores fall behind in the first place?

Because upgrades get budgeted as projects instead of operations. A project needs a sponsor, a quote, and a slot on the roadmap, so it slips behind revenue work every quarter until a deadline or an incident forces it. The stores that stay current treat version moves the way they treat patching: a standing line item that happens on a schedule, with a partner or an internal owner accountable for it. We make the same argument about monthly patching in how often you should patch Adobe Commerce, and the upgrade cadence is the annual version of that discipline.

The three-year support window gives you the planning rhythm for free. A new line ships each spring. Support ends three years later. If you upgrade once a year, every upgrade is a small hop with current vendor support and light regression load. If you upgrade every three years, you are always doing the biggest possible jump under the worst possible time pressure, and paying for the difference. When merchants ask us to price both patterns, the annual cadence wins on total cost every time, which is consistent with everything else we have found modeling the real cost of owning Adobe Commerce.

How to plan your move before August 11

Work backward from the date. A store on 2.4.6 today has about six weeks of support left, which is enough for a disciplined upgrade if it starts now and the extension audit comes back clean. Here is the order of operations we run:

1. Pick the target. For most stores upgrading this summer, that is 2.4.8, one stable line behind the newest, with support to April 2028. Choose 2.4.9 if your key extensions already support it and you want the runway to May 2029.
2. Run the compatibility audit first. Every extension, every customization, checked against the target before anyone touches production. This is the week that predicts the whole timeline.
3. Upgrade on a staging copy, fix what breaks, and regression test the money paths: checkout, payments, tax, ERP sync.
4. Ship, then get on a patch cadence so the next security release is a same-week apply, not a backlog item. Our patch cadence playbook, linked below, covers what that rhythm looks like in practice.

If your current agency has let you drift two lines behind support, that is information about the relationship as much as the codebase. Upgrades and patching are exactly the kind of unglamorous work a maintenance partner exists to keep off your desk, and it belongs in the contract, which is something we push hard on when we scope support retainers for merchants.

We are Bemeir, a Brooklyn agency that builds and maintains Magento and Adobe Commerce stores for US mid-market merchants, and a meaningful share of our work is inheriting stores that sat on old versions too long. We would rather do your two-week upgrade this July than your rescue project in November. Either way, put the date on your calendar: August 11 does not move.

Related Resources

• How often should you patch Adobe Commerce, and what happens if you don’t
• Adobe Commerce patch Tuesday: building a predictable monthly security cadence
• What an Adobe Commerce support retainer should cover
• Adobe Commerce retainer pricing: 40, 80, and 160 hour tiers explained
• Magento 1 after end of life: what happened when the patches stopped
• The total cost of ownership for Adobe Commerce, beyond the license fee