A Magento store can run for years without anyone touching its version number, and that is exactly the problem. Each Magento 2.4 release line receives security fixes for a limited time, and a store left on an old line keeps working while quietly collecting known vulnerabilities. Planning a Magento 2.4 upgrade before the deadline, rather than after an incident, turns it into routine work. This guide explains how release lines and support dates work, how patches differ from upgrades, and the checklist we follow.
Magento end of support: how release lines work
Magento Open Source and Adobe Commerce are released in lines: 2.4.6, 2.4.7, 2.4.8 and, since May 2026, Magento 2.4.9. Within each line, patch releases with a -p suffix, such as 2.4.8-p3, deliver security and critical fixes without new features. The Adobe Commerce lifecycle policy sets out how long each line is supported, generally about three years from its release, with some lines extended for Adobe Commerce customers. Support windows can differ between the paid and the open source edition, so read the policy for your edition rather than relying on a date quoted secondhand.
In practice, a store on 2.4.6 or older is at or past the end of its standard support and should be planning its move now, and a store on 2.4.7 has time, but not much to spare. When Magento end of support arrives for your line, the store keeps running; it simply stops receiving fixes, and every vulnerability published after that date stays open.
Magento security patches between upgrades
Magento security patches arrive in two ways: as the next -p release of your line, and occasionally as an isolated hotfix when a critical flaw cannot wait. SessionReaper (CVE-2025-54236) is the example to remember. Adobe released the fix in September 2025 in security bulletin APSB25-88, and once technical details became public, attackers began exploiting unpatched stores on a large scale. Stores that applied the hotfix promptly were in a very different position from those that waited for their next planned upgrade.
For individual fixes between releases, Adobe provides the Quality Patches Tool, which applies selected patches from the command line and keeps a record of what was applied. Subscribe to Adobe's security notifications as well, so a critical bulletin reaches someone who can act on it within days.
A Magento upgrade checklist
Our Magento 2 development work rehearses every upgrade on a copy of the store before touching the live one; the checklist below shows what that involves.
- Record the current state: Magento version, PHP, database server, OpenSearch, Redis, Varnish and Composer versions, and the list of installed modules.
- Check the target's system requirements. A new line often needs newer PHP, database or search engine versions, which may mean a server upgrade before the application upgrade.
- Review third-party extensions. For each one: is it still used, is it maintained, and does its vendor support the target version? Remove what nobody uses and replace what is abandoned. Third-party extensions cause more upgrade delays than Magento itself.
- Review custom code for edits to core files, class preferences that replace core classes, and deprecated APIs. Custom modules that change behavior through plugins and observers usually upgrade cleanly.
- Build a staging environment from a recent copy of production, with customer data anonymized, running the same software versions the live server will use.
- Upgrade on staging with Composer, run the setup upgrade, compile, deploy static content and fix what breaks.
- Test the paths that earn money: search, product pages, cart, checkout with every payment and shipping method, customer accounts, admin order handling and integrations.
- Plan the release: a full backup, a quiet time window, maintenance mode and a written rollback plan.
- Watch the first days: error logs, order volume, payment failures and page speed.
Magento 2.4 upgrade paths: skipping versions and moving the infrastructure
A store several lines behind does not need to stop at every intermediate release: Composer can move straight to the target, and the database upgrade scripts run in order. The work that cannot be skipped is the infrastructure. PHP, the database and the search engine each have supported versions for every Magento line, and a jump from an old line may mean replacing much of the server stack. That is often the moment to decide whether the current hosting still fits the store.
Upgrade or re-platform?
An upgrade is usually the right call when the store does what the business needs and the pain is technical debt. If the business has changed around it, for example the catalog has shrunk and the team wants less to maintain, or B2B requirements have outgrown the extensions in place, compare the upgrade with a move to another platform. Our e-commerce re-platforming service covers that route.
Frequently asked questions: magento 2.4 upgrade
How often should a Magento store be updated?
Apply each security patch release for your line soon after it is published, and critical hotfixes within days. Plan the move to a newer line well before your current line's support ends; for most stores that means a larger upgrade every year or two.
Will an upgrade change how my store looks?
It should not, but themes that override many core templates may need adjustments. Luma-based and Hyvä themes both need their own compatibility check on staging before the live upgrade.
Does Magento Open Source get the same support as Adobe Commerce?
Both receive security patches for supported lines, but the paid edition has additional support options and, for some lines, longer windows. Check the lifecycle policy for your edition.
Running an older Magento 2.4 release? Our Magento 2 and Adobe Commerce development team handles upgrades, security patches, extension audits and integrations, and this site itself runs on Magento Open Source 2.4.8, so the routine is our own as well. Contact us with your current version and the extensions you rely on, and we can scope the upgrade.
