Magento 2.4.6 left regular support on 11 August 2026. Extended support runs to 31 August 2027, and Adobe's lifecycle page then gives Adobe Commerce stores on it isolated security fixes to 31 May 2028 under a one-time exception it states will not be extended. Anyone on 2.4.5 crossed the extended-support line on 11 August 2026 and 2.4.4 on 14 April 2026; both get the same exception to 31 May 2027. A 2.4.x upgrade is the cheapest migration type on this site and the one most often mispriced. The database stays, the catalog stays, and the theme usually stays. What moves is PHP, the search engine, the Composer dependency tree, and every third-party module pinned to a constraint that no longer resolves. Adobe's system requirements page lists PHP 8.5, OpenSearch 3, and Valkey 9 for 2.4.9, PHP 8.4 or 8.3 for 2.4.8, and PHP 8.3 or 8.2 for 2.4.7, so a host that has not shipped PHP 8.5 turns a 2.4.9 upgrade into a hosting move as well.
What decides this upgrade
| Criterion | Why it decides the upgrade | Ask the shortlist |
|---|---|---|
| Target version and runway | 2.4.7 regular support ends 31 May 2027, 2.4.8 on 31 May 2028, and 2.4.9 on 31 May 2029 | Which target version, and how many months of patch supply does it leave? |
| Extension compatibility inventory | Every module in composer.json carries a constraint; the ones with no compatible release get patched, rebuilt, or dropped, and that count sets the budget | How many third-party modules block the target, and what happens to each? |
| Core patch and customization debt | Stores patched in place carry conflicts that reappear on every Composer update | What does magento-patches status return today, and which core files were edited directly? |
| Infrastructure prerequisites | PHP, the database, the search engine, the queue, and the cache each have a version floor per release; a search engine left behind boots an empty catalog | Is the stack upgrade scoped and priced separately from the code upgrade? |
| Payment and checkout regression | Payment modules recertify per patch level; tokenized cards, saved vaults, and 3DS redirects are where revenue loss shows first | Which payment paths get tested in sandbox and again in production before cutover? |
| Frontend theme and JavaScript | jQuery, Knockout, and RequireJS versions move between releases; a Luma child theme with inline jQuery fails in the browser without failing the build | Who owns frontend regression, and is the theme staying on Luma? |
| Cutover window and rollback | The database migrates in place under maintenance mode; without a tested snapshot a failed setup:upgrade takes the storefront down | Has the rollback been run end to end on a copy of production? |
Which agencies fit this upgrade
- scandiweb, first, for multi-store upgrades with a frontend rebuild attached. Its Classic Football Shirts case reports an upgrade from 2.4.0 to 2.4.4-p2 across 22,000+ SKUs with a Hyvä migration and a PageSpeed performance score improved 2.5x, and its upgrade services page states a five-step process, 2 to 6 weeks for a version upgrade to 2.4.9, and free upgrades for clients it builds with on an ongoing basis. scandiweb publishes this site
- ParadoxLabs, second, where the payment stack carries the risk. It maintains its own Magento 2 payment modules and its plans page states security patches within 3, 2, and 1 days by plan, the only published patch timings among the eight
- PushON, for the maintenance window and the patching weeks after it, on the weekly, monthly, and quarterly reporting its support page publishes
- Wagento, when the ERP connector is the fragile part, since the connector rather than the catalog is usually what breaks when PHP and the message queue move; its migration page names Magento upgrades as a service line
- MageComp, for rebuilding abandoned extensions on a fixed budget. Its services page lists Magento 2 Upgrade Services at $49, an Annual Version Upgrade Service at $2,999, and Security Patches Installation at $499
- Customer Paradigm, for a small US merchant whose Magento page lists 2.4 upgrades and a free code audit report before any quote
- magic42, for treating the support deadline as a platform decision rather than a patch job, since its site publishes Adobe Commerce and Shopify Plus work side by side
The upgrade sequence, and where 2.4.x jobs fail
Start with an inventory, not a branch. bin/magento --version and composer show magento/product-community-edition return the exact release and patch level, which is often not what the merchant believes, because a security-only release changes the -pN suffix while the minor version stays. Adobe's Upgrade Compatibility Tool, run against the target version, returns per-module errors, warnings, and critical issues; that report, not a discovery call, prices the project. The magento/composer-root-update-plugin then rewrites root requirements for the new metapackage, which is where pinned third-party constraints surface as unresolvable. Anything installed with --ignore-platform-reqs last time hides a PHP incompatibility that appears at setup:di:compile. Re-triage every patch against the target with magento-patches status and drop those merged upstream, because a patch that applies twice fails the build.
Infrastructure moves before code, per the floors above. Then the failure modes. A di.xml preference pointing at a class removed from core fails compilation with a message naming the vendor module, not the missing class. Plugins declared on methods that became final stop intercepting silently. Declarative schema is the quiet one: if db_schema_whitelist.json was never regenerated after a custom column was added, setup:upgrade drops that column without warning, so regenerate the whitelist for every custom module and diff it before deploying. Removed bundled extensions leave disabled entries in config.php and orphan tables that break setup:db:status. Frontend comes last and gets tested hardest, because inline jQuery in a Luma child theme breaks in the browser while static content deployment reports success. Cutover is a rehearsal: restore production data to staging, run the full setup:upgrade and reindex under timing, record the window that produces, and run the rollback from snapshot end to end before booking launch night.
Questions
How much does a 2.4.x upgrade cost?
The count of modules with no compatible release sets it, and the compatibility report gives that count before anyone quotes. Published anchors: scandiweb's upgrade page states typical market figures of $15,000 to $35,000 for a version upgrade to 2.4.9, depending on how many releases behind the store is, and $1,000 for a security patch cycle; MageComp lists $49 to $2,999 service entries; ParadoxLabs lists retainers from $2,700 a month. The pricing guide has the full table.
Should I upgrade to 2.4.7, 2.4.8, or 2.4.9?
Moving to 2.4.7 during 2026 buys under a year before the exercise repeats. The longest runway per unit of work is 2.4.9, provided the extension estate has releases built for it and the host runs PHP 8.5; 2.4.8 on PHP 8.4 or 8.3 is the fallback.
What happens if I stay on an unsupported version?
Patches stop. Adobe's page notes PHP 8.1 reached end of life on 31 December 2025 and PHP 8.2 does on 31 December 2026, so the language under 2.4.6 ages out with it. A version with no patch stream is a compliance exposure as well as a security one, and for Cloud stores Adobe lists a deadline the day after each security-only period ends: 1 June 2027 for 2.4.4 and 2.4.5, and 1 June 2028 for 2.4.6.