"Running 2.4" is not a version
Teams describe their store as "on 2.4" as if that settled the question. It does not. The exact patch level, and whether that version is still supported, decide whether you get security fixes at all.
Adobe publishes a supported matrix for each release, covering PHP, the database, the search engine, and the rest of the stack. Running outside that matrix is unsupported, whether or not the store appears to work.
This article covers what the matrix actually specifies, how to find your exact version and its support status, and why alignment is the base every other upgrade depends on.
What the supported matrix actually covers
The matrix is not just a PHP version. Each Magento release pins supported ranges for the whole stack it runs on:
- PHP, with a specific range per version.
- MySQL or MariaDB, at particular major versions.
- OpenSearch or Elasticsearch for catalog search.
- Redis or Valkey, Varnish, RabbitMQ, and Composer.
Each of those has a supported range tied to your exact Magento version. A component outside its range is an unsupported configuration, even when nothing is visibly broken yet.
Find your exact version and patch level
Start with what you actually run. bin/magento --version reports the release, and composer show magento/product-community-edition or the enterprise equivalent gives the precise package version.
The patch level matters as much as the minor version. A store on 2.4.7 without its later security patches is a different risk than one on the current patch of 2.4.7.
Write down the exact string, because every other check in this article compares against it. Vague version knowledge produces vague conclusions.
Supported versus end of life
Every Magento version has a support lifecycle, and security patches only ship for versions still inside it. Once a version reaches end of support, Adobe stops issuing fixes for it entirely.
This is the single most important fact about version alignment. A store can run for years past end of support, accumulating unpatched vulnerabilities the whole time, with no error message to announce it.
The components people upgrade out of range
Alignment breaks in both directions. Sometimes Magento falls behind, and sometimes the infrastructure moves ahead of it.
A server team upgrades PHP, MySQL, or OpenSearch to a newer major for reasons of their own, and the store is suddenly running a component the Magento version never supported. This produces subtle failures that are hard to trace, from search mapping errors to database syntax incompatibilities.
The fix is to treat the matrix as a constraint on infrastructure changes, not just on Magento upgrades. Every component version should be checked against the range for the Magento release before it is changed.
The lifecycle is published, not a guess
You do not have to guess whether your version is supported. Adobe publishes the lifecycle policy and the release schedule, with dates for when each version stops receiving quality and security fixes.
Open Source and Commerce editions follow their own timelines, so check the one you actually run. The date that matters is when security patches end, because that is when standing still starts accumulating risk.
Mark that date somewhere your team will see it. A version supported today still has an end-of-support date, and planning the next upgrade before it arrives is far cheaper than reacting after.
What alignment gives you back
Confirming alignment is not busywork. A store inside the matrix and inside its support window has a clear, incremental upgrade path and the full set of security patches available to it.
A store that has drifted out has neither. Its next upgrade is larger, its patches may not apply cleanly, and its dependencies may need their own upgrades first, all at once.
Why alignment is the base of everything else
Version alignment is unglamorous, and almost everything else depends on it. You cannot apply current security patches, trust a staging test, or plan an upgrade path from an unsupported configuration.
It also determines your options. A store far behind the current version has a longer, riskier upgrade ahead, and knowing that early lets you plan for it instead of discovering it under pressure.
Know exactly where you stand
Confirming version alignment is one of the fastest, most authoritative checks in a platform review. It produces a clear yes or no: supported and in range, or not.
It is also the check that scopes every other one. Until you know your version and its support state, every other finding sits on shifting ground, because the fix available to you depends on where you stand in the lifecycle.
Knowing your exact version, its support status, and whether every component sits inside the matrix is the foundation any upgrade or security plan is built on. Everything else is guesswork until that fact is settled.