Magento 2.4.6 standard support has ended: what changes, and how to plan the upgrade

Adobe's standard support for Magento 2.4.6 ended on 11 August 2026. If your store is on 2.4.6, it kept running the next day. Orders went through and the admin loaded as usual. That's why end-of-support dates get ignored, and why the cost tends to arrive later, all at once.

For Magento Open Source, the change showed up four weeks after the deadline, in two bulletins a day apart. On 7 September 2026 Adobe released an emergency hotfix for a critical zero-day (APSB26-146), and it did cover Open Source 2.4.6. On 8 September the regular bulletin, APSB26-138, listed Open Source 2.4.6 as affected but shipped Open Source fixes for 2.4.7 and later only. Its 2.4.6 fix is for Adobe Commerce customers.

So Open Source 2.4.6 now gets a fix only when Adobe decides an issue is serious enough to make an exception. You can't plan a business around that.

This guide covers what changed for each edition, the PHP deadline that comes next, which version to move to, and how we run these upgrades on live stores.

The dates that matter

Adobe publishes a fixed support window for every release line. Here's where the current lines stand, with the PHP versions each one supports.

Magento and Adobe Commerce release lines (Adobe lifecycle policy and system requirements, September 2026)

Two things stand out. First, 2.4.7 has about eight months left, so upgrading to it now means planning the next upgrade straight away. Second, 2.4.9 runs on PHP 8.5 only, which is a hard jump for stores with older extensions.

Open Source and Adobe Commerce are not in the same position

The same version number means different things depending on which edition you run, and many end-of-support articles don't separate the two.

The PHP deadline behind the Magento one

Magento's dates get the attention, but PHP's matter just as much. PHP has its own security support window, and 2.4.6 limits which PHP versions you can run.

Magento 2.4.6 supports PHP 8.1 and 8.2. According to php.net, PHP 8.1 is already end of life. PHP 8.2's security support ends on 31 December 2026.

So a 2.4.6 store has two clocks running. Even an Adobe Commerce store inside its extended support will be on an unsupported PHP version from January 2027, because 2.4.6 can't run on anything newer. Hosting providers also retire old PHP versions on their own schedules, so a managed host may force the issue before you're ready.

What keeps working, and what quietly stops

End of support doesn't switch anything off. Your storefront, checkout, admin, integrations and data keep working. The risk builds slowly, which makes it easy to ignore.

The PCI point is the one that tends to move budgets. If your store is in PCI DSS scope, an unsupported release makes the assessment harder. "We're on a version that no longer gets routine security patches" is a difficult sentence to put in front of an assessor.

Which version to move to

Many upgrade plans go wrong here. Moving from 2.4.6 to 2.4.7 feels like the small, safe step, but it buys very little time. Its standard support ends on 31 May 2027, so you'd be planning the next upgrade before this one is finished.

Our position: skip 2.4.7 and go to 2.4.8. It's supported until May 2028 and runs on PHP 8.3 or 8.4. Check each extension against the target patch release and PHP version; on the stores we look after, the actively maintained ones were ready.

Choose 2.4.9 only if every extension you depend on already supports PHP 8.5. It gives the longest runway, to May 2029. It's also the newest release line, so expect more extensions to need checking or updating.

There are two cases where 2.4.7 can make sense. One is a store with an extension that is critical to the business and won't support 2.4.8 in time. The other is an Adobe Commerce store using its extended support as a deliberate two-step plan. In both cases, put the second upgrade on the calendar the day the first one finishes.

What actually makes these upgrades hard

We look after several Magento stores and have taken them through these release lines one at a time. The Magento core is rarely the hard part. These four things usually are.

1. The extension count. One B2B multistore we run carries dozens of third-party packages, including search, a page builder, a theme framework, a marketplace connector and payment modules. Each one has to support the target version before the upgrade can ship. Bought extensions get a store to market quickly. Each one then upgrades on someone else's schedule.

2. Shared code across storefronts. In a multistore, three storefronts can share one parent theme and one set of custom modules. That's what keeps them maintainable, and it's also why a single regression breaks three shops at once, or breaks one in a way the other two hide. Every upgrade has to be tested three times.

3. Patches applied between releases. It's common for stores to carry security patch files applied by hand between vendor releases, named after the vulnerability they fix. That's good practice when a fix can't wait. At upgrade time, each one has to be checked: is it now part of core, does it still apply, or does it need retiring?

4. Metadata that stopped telling the truth. On stores we've taken over, the version declared in the project's composer metadata has often been years behind what was actually installed. Harmless day to day, but a new engineer, a security scanner or an auditor reading that file gets the wrong answer. Fixing it now sits on our upgrade checklist.

How we run the upgrade

We work in this order to keep a live store safe. It's the same for single stores and multistores, and for 2.4.8 or 2.4.9.

1. Audit every extension. List each module, check its vendor's support for the target version and PHP, then decide to update, replace or remove it. This step sets the timeline.
2. Plan the whole stack together. PHP, database, search engine, cache and Composer versions move with Magento, not after it. Check Adobe's system requirements for the exact patch release you're targeting, because they change between patches.
3. Upgrade a copy of production. Use real data (anonymised where needed), run the checkout, account and order flows end to end, then fix what breaks.
4. Declare your patches in code. Keep every security patch in the project's dependency configuration so each fix is recorded, repeatable and visible at the next upgrade.
5. Fix the metadata. Make the project files describe the version you actually run.
6. Release in a quiet window, with a rollback ready. Database backup, code tag and a tested way back.

For step 4, the common approach is the cweagans/composer-patches plugin, which applies listed patch files every time dependencies install:

{
  "extra": {
    "composer-exit-on-patch-failure": true,
    "patches": {
      "magento/module-catalog": {
        "Example: vendor security fix, remove once in core": "patches/catalog-security-fix.patch"
      }
    }
  }
}

Setting composer-exit-on-patch-failure matters on version 1 of the plugin, which many Magento projects still run: without it, a patch that no longer applies can be skipped with only a warning, and the store ships without the fix. Version 2 changes how patches are configured and locked, so follow the documentation for the version you run.

A realistic timeline from today

If you're on 2.4.6 now, this is the order we'd work in. The calendar dates assume you start in October 2026; the gaps between steps are what matter.

An illustrative plan for a typical single-store upgrade starting in October 2026

Smaller stores move faster than this. A multistore with dozens of extensions, or custom billing logic, can take longer. The point is the sequence: the audit comes first, and the release lands before 31 December 2026, not after it.

Two things make this go faster. The first is a staging environment that matches production, including the same PHP, search and cache versions. Testing on a mismatched stack hides problems until release day. The second is a short freeze on new features during the upgrade, so the team isn't testing a moving target.

Questions to ask your developer or agency

Whoever runs your store, these questions show quickly whether the upgrade is under control.

If the answers are vague, the audit is the first job, before any upgrade work is quoted.

What drives the cost

Every store is different, but the same factors drive the effort. This is how we scope an upgrade before quoting it.

What makes a 2.4.6 upgrade bigger or smaller

Custom billing logic is a good example. One store we maintain runs custom recurring-payment logic on Magento. It works well, and it has to be re-verified at every upgrade. We build that verification into each upgrade estimate from the start.

Should you change the frontend at the same time?

It's tempting to combine the upgrade with a move to Hyvä, especially since the Hyvä Theme became free and open source in November 2025. Hyvä's checkout and some of its other products are still paid.

Our advice is usually to keep them apart. The upgrade is a risk-reduction project with a deadline. A new frontend is a growth project with design decisions. Doing both at once makes it harder to tell what caused a problem. Upgrade first, then plan Hyvä as its own project. Make sure the extensions you keep have Hyvä support, and the second project will go faster.

What about not upgrading?

There are three alternatives to upgrading:

• Stay on 2.4.6 and patch it yourself. Possible, but you're now maintaining your own security fork. It gets more expensive with every bulletin, and it doesn't fix the PHP problem.
• Move to Mage-OS. A community-owned distribution built on Magento Open Source and designed to stay compatible with it. Worth a look for teams who want an alternative release path. It's still an upgrade project, because your extensions and PHP version still have to fit.
• Replatform. Sometimes right, but it's a far bigger decision than an upgrade. It shouldn't be made under a security deadline.

For stores whose extensions and hosting support it, 2.4.8 is our default upgrade target.

FAQ

If you're on 2.4.6, send us your version and patch level. If you're not sure what you're on, say so. We'll tell you where it sits against Adobe's dates and what we need to check before anyone talks about scope. You can also see how we run upgrades for a three-storefront B2B multistore.