Magento & OpenMage compatibility and lifecycle

Compatibility is not determined by the Magento or OpenMage version alone. A production store also depends on PHP, its database and search services, extensions, custom code, the theme, payment and shipping integrations, and the hosting environment.

This page was reviewed on September 27, 2026. Always verify the linked upstream sources before planning a production change because supported versions and dependency requirements continue to move.

Current support boundaries

Magento 1

Adobe no longer maintains Magento 1. A store that still identifies as Magento 1 should not be treated as current merely because historical SUPEE patches are present. For Magento Community Edition stores, a maintained OpenMage release is usually the first modernization path to assess.

OpenMage

The OpenMage security policy lists the 20.x line as supported and the older 19.x line as unsupported. Use the OpenMage releases page to confirm the current release and its security notes; do not infer support from a store’s Magento-compatible version string alone.

The current OpenMage requirements state PHP 8.1 or newer, MySQL 5.6 or newer with MySQL 8 recommended, or a compatible MariaDB release. That application minimum is not the same as a safe runtime recommendation: the selected PHP and database branches must also still receive upstream security updates.

For workload-based infrastructure sizing, see which hosting suits OpenMage best. The software minimums do not determine how much CPU, memory or database capacity a particular store needs.

Magento 2 and Adobe Commerce

Magento 2 compatibility is release-specific. PHP, Composer, database, search, cache and message-queue requirements can change between patch lines. Match the exact installed and target versions against Adobe’s current system requirements and software lifecycle policy before planning an upgrade.

PHP lifecycle matters separately

PHP support does not follow the Magento or OpenMage release calendar. The official PHP supported versions table distinguishes actively supported branches, security-fixes-only branches and end-of-life branches.

An application may technically run on a PHP branch that no longer receives security fixes. Conversely, switching PHP independently can expose incompatible extensions, custom code or old libraries. Treat the application and runtime upgrade as one tested change:

inventory the application, extensions and integrations;
select an application release and supported runtime together;
reproduce the store in staging or from a restorable backup;
resolve code, theme and dependency compatibility problems;
test storefront, admin, checkout, payments, shipping, email and scheduled jobs;
plan production deployment, cache invalidation and rollback.

What a public check cannot prove

A public URL can reveal useful version and configuration signals, but a reliable compatibility assessment normally requires code and configuration access. In particular, an external check cannot establish:

core modifications and local overrides;
installed extensions that expose no public asset;
extension or custom-code compatibility with the target PHP version;
Magento class rewrites and event observers;
custom database schema and data migration complexity;
private payment, shipping, ERP and fulfilment integrations;
cron jobs, queue workers and deployment-specific infrastructure.

Use the Security Scanner for public Magento 1 and OpenMage signals, or the OpenMage Readiness Test for preliminary migration triage. Neither replaces a code-level assessment and a test migration.