Why upgrading is not optional
Adobe releases security patches for Magento 2 every quarter. A patch on version 2.4.6-p14 closes known vulnerabilities in the admin and checkout. A store staying on 2.4.4 or 2.4.5 misses those patches and is exposed to known exploits actively being used.
- ▸2.4.4 end-of-life: no more security patches after April 2026. Every day after that date is an uncovered vulnerability.
- ▸PHP version EOL: PHP 8.1 no longer receives security updates. Magento 2.4.7 requires PHP 8.2 or 8.3. The PHP upgrade is almost always part of the same project.
- ▸Vendor modules: third-party extensions follow their own release schedule. A module compatible with 2.4.5 sometimes no longer works on 2.4.7 without an update or patch.
- ▸Adobe Commerce roadmap: new features such as the improved checkout and GraphQL enhancements are only available in recent versions. Staying on an outdated version means falling behind on functionality.
- ▸Composer dependencies: an outdated version pulls a chain of outdated packages with it. The longer you wait, the larger the delta at the next upgrade.
The risk of not upgrading grows over time. From 2.4.6 to 2.4.7 is a controlled step. From 2.4.4 to 2.4.8 is a much larger delta with more conflicts.
How I approach an upgrade
An upgrade on a production Magento store requires preparation. I always work with a dev clone of the production store before anything changes on production.
- ▸Set up dev clone: export production database, import on staging, adjust .env. Everything I do, I test here first.
- ▸Composer resolve: run the core upgrade via composer require and then work through conflicts per extension. With 328 modules on CarCare24 this sometimes means resolving 15 to 20 manual conflicts.
- ▸Vendor module updates: each extension requiring a new version for compatibility, I update separately. Sometimes a composer patch is the temporary solution when the extension vendor has not yet released a compatible version.
- ▸di:compile + static-content:deploy: after each significant change, a full compile and deploy cycle. Without static-content:deploy the store returns HTTP 500 with 'Unable to retrieve deployment version'.
- ▸Smoke test on 6 routes: homepage, category page, product page, search results, checkout, confirmation page. These are the critical paths. Everything must work before I consider moving to production.
- ▸Rollback strategy: before each production upgrade I prepare a database snapshot and note the exact composer.lock state. If there is a P1 issue within 24 hours, I can roll back.
On production I prefer to work outside peak hours. The cache flush after deploy gives a brief period of higher load from cache warming. That is normal and acceptable. Actual downtime is not acceptable.
The 4 deploy steps that always matter
After every code change on a Magento 2 installation in production mode, these 4 steps are mandatory, in this order:
- 1.
bin/magento setup:upgradeUpdate database schema, register new module configurations. - 2.
bin/magento setup:di:compileRegenerate dependency injection code. If a class is missing, a 500 follows at runtime. - 3.
bin/magento setup:static-content:deploy -fRegenerates deployed_version.txt. Without this step every page returns HTTP 500 with 'Unable to retrieve deployment version'. This is the step most often forgotten. - 4.
bin/magento cache:flushClear cache so new code becomes active for visitors.
For stores with an SRI hashes module: run step 3 with --jobs=1. Parallel jobs create a race condition that corrupts the sri-hashes.json.
Risks I know and address
Not every upgrade goes smoothly. These are the problems I have encountered on a production environment with 328 modules and know how to solve:
- ▸Knockout.js compatibility breaks: Magento 2.4.7 contains updates to the KO components for checkout and mini-cart. Custom templates using KO bindings need to be checked for deprecated syntax.
- ▸Third-party module breaks: an extension that has not been maintained can stop working after a core upgrade. I check every extension against the Magento Marketplace compatibility matrix and find the right patch or update.
- ▸Custom theme JavaScript regressions: custom JS that interferes with RequireJS modules or the new checkout flow. I test all custom front-end code against the upgrade version.
- ▸SRI hashes race conditions: the sri-hashes module generates a manifest during static-content:deploy. With parallel jobs the manifest can become corrupt, blocking frontend resources. I experienced this live on Wave 9.
- ▸MagePack rollback: after an upgrade an existing MagePack bundling can be outdated and produce larger bundles than standard RequireJS loading. I roll back the bundle configuration and rebuild.
- ▸Plumrocket cookie-blocking regressions: cookie consent modules that re-block the consent flow after an upgrade because scripts have become render-blocking again due to order changes in layout XML.
These problems are solvable. The difference is that I recognise them before they become a P1 on production.
-- Upgrade case
CarCare24: patch p14 to p15 with MagePack rollback
CarCare24 runs Magento 2.4.6 on Hypernode with Cloudflare. The production platform has 328 modules including M2EPro for marketplace sync, Plumrocket cookie consent and a custom SRI hashes module. On 15 May 2026 I performed the patch upgrade from p14 to p15.
After the patch deploy the front end initially ran stably. After 2 hours MagePack turned out to have loaded a stale bundle configuration producing larger JS bundles than before the patch. The LCP on mobile increased measurably. I rolled MagePack back to standard RequireJS bundling and performed a reinstall of the bundle configuration. Plumrocket also had a cookie-blocking regression where scripts became render-blocking again. That fix required an adjustment in the layout XML.
After the MagePack rollback and the Plumrocket fix the store returned to its pre-patch performance level. The total impact on visitors was limited to the 2-hour period. Rollback strategy and monitoring are not a luxury with a store of this module count.
What I do not do
There are projects I advise against and do not carry out myself:
- ✕Major Adobe Commerce upgrade without licence check: an upgrade to Adobe Commerce Enterprise requires a licence. I do not perform that upgrade without a clear licence situation.
- ✕Theme version upgrades without custom mod assessment: a theme update overwrites custom adjustments. I always first map which custom changes sit in theme files before recommending a theme update.
- ✕Vendor module replacement without feature parity check: if an extension is replaced by an alternative, I first check that all functionality the store uses is also available in the alternative.
- ✕Upgrade on production without staging test: no code change on production without it having run on staging first. This is not a recommendation, it is a hard rule.
- ✕Skipping major version upgrades: going from 2.4.4 directly to 2.4.8 is technically possible but significantly increases the risk of unexpected conflicts. I recommend incremental upgrades via intermediate minor versions.
Scope and price
The price of an upgrade project depends on the number of modules, the presence of custom modules or custom theme adjustments, the size of the PHP version jump and whether a staging environment is available.
I do not work with fixed upgrade packages. A store with 20 standard Marketplace extensions on Hypernode has a different scope than a store with 328 modules of which part are custom. Prices are always on request, after a brief inventory of the current stack.