Magento Version Checker: 12 questions answered.

The Magento 2.3.x line hit end-of-software-support on 9 September 2022. Adobe stopped shipping security patches for 2.3.x after that date. Any store still on 2.3.x in 2026 is carrying every CVE published in the last three-plus years, including several rated 9+ on the CVSS scale.

What this means in practice:

• PCI-DSS: 2.3.x stores fail PCI compliance audits on the “unsupported platform” control. Some processors (Stripe, Adyen, Braintree) flag the merchant; others quietly add risk premiums.
• Insurance: Cyber-insurance renewals increasingly exclude breaches on EOL platforms.
• Extension support: Most extension vendors have dropped 2.3.x from their compatibility matrix. New features ship for 2.4.x only.
• Hyvä: Hyvä themes don’t support 2.3.x. If you’re planning a Hyvä migration, the upgrade comes first.

The recommended path off 2.3.x: 2.3.x → 2.4.4 → 2.4.9 (two-hop). 2.4.4 is the sane intermediate stop because it’s the first version on PHP 8.1+ and composer 2.x, so you get the major framework changes in one digestible hop. Doing 2.3.x → 2.4.9 direct is technically possible but the regression surface is unmanageable.

Magento 2.4.6 removed Elasticsearch support and made OpenSearch 2.x the only supported search engine. If you’re upgrading from 2.4.5 or earlier, this is the single biggest infra change you’ll hit.

What breaks:

• The Elasticsearch service. Magento won’t connect to ES 7.x anymore. You need to install OpenSearch 2.x alongside (or in place of) your existing ES, reindex the catalog, and update app/etc/env.php to point to OpenSearch.
• Custom search modules that hit Elasticsearch APIs directly. OpenSearch is API-compatible with ES 7.x for the basics but diverges on newer features. If you’ve written any custom search code, audit the API calls.
• Hosting provider configs. Cloudways, Nexcess, JetRails, MageMojo all support OpenSearch but may need a config flip. Self-hosted: install OpenSearch from the official RPM/DEB repo.
• Memory footprint. OpenSearch 2.x can use slightly more RAM than ES 7.x on the same index. If you’re running 4GB JVM heap, give it 6-8GB.

What doesn’t break: the storefront search UI is unchanged, the admin search-config screen is unchanged, third-party search extensions (Algolia, Klevu, Mirasvit) keep working because they bypass the Magento built-in search.

Workflow: install OpenSearch alongside Elasticsearch, repoint Magento to OpenSearch, smoke-test, decommission Elasticsearch a week later. Don’t do them simultaneously.

Clean stores: 2-3 weeks end-to-end. Messy stores: 4-6 weeks. Honest typical breakdown:

• Audit + planning: 2-3 days. Inventory extensions, check vendor compat releases, scan custom code for PHP 8.3 deprecations, draft staging plan.
• Staging build: 3-5 days. composer require, resolve dependency conflicts, run setup:upgrade, fix broken extensions, rebuild static content.
• QA + UAT: 5-10 days. Smoke-test every storefront, run checkout end-to-end, validate B2B (if applicable), test reindex on prod-data snapshot, fix issues iteratively.
• Cutover: 1 day. Pre-warm caches, freeze deploys, run final data-sync, switch DNS/load-balancer, watch dashboards for 4 hours.
• Stabilisation: 14 days, parallel with normal ops. Rollback button armed for first 72h.

Multipliers: B2B in scope adds +30%, multi-store adds +1 week per storefront, ERP integration adds +2 weeks for handshake retest, Hyvä migration alongside doubles the calendar time.

The 2.4.7 → 2.4.9 hop is one of the cleaner ones, OpenSearch already in place, PHP 8.2 → 8.3 (or 8.4) is the main framework lift, and the extension matrix is mostly clean by mid-2026.

Practical decision matrix as of May 2026:

• 2.4.7-p3 / -p4 (security-patch release on the 2.4.7 line). Pick this if you’re already on 2.4.7-px and just need the latest patches. PHP 8.2 + 8.3. Lightest upgrade, ships every ~3 months until Sep 2026.
• 2.4.8 (Apr 2025 GA, p1 in Aug 2025). Pick this if you’re jumping from 2.4.6 or earlier. PHP 8.3 required. Cleanest stable line right now, full extension compat matrix, security patches through 2027.
• 2.4.9 (latest, Apr 2026 GA). Pick this if you’re doing the upgrade anyway and want the longest support runway. PHP 8.3 + 8.4 supported. New Adminhtml refinements, GraphQL improvements, security hardening. Some extensions still catching up, check yours.

Decision shortcuts:

• Already on 2.4.7-p2 or older? → Go to 2.4.9 if your extensions are ready, else 2.4.8.
• Already on 2.4.7-p3 or -p4? → Stay until late 2026, then jump to 2.4.10 or 2.4.11.
• On 2.4.6 or earlier? → 2.4.9, single jump.
• On 2.3.x? → Two-hop via 2.4.4 then 2.4.9.

2.4.7-p4 vs 2.4.9 is a real tradeoff: -p4 is more battle-tested today; 2.4.9 has the longer runway. If you’re doing the work anyway, 2.4.9 wins on TCO.

Same code, same upgrade path, different licence and a few extra modules.

Adobe Commerce (formerly Magento Commerce, formerly Magento Enterprise) is the paid edition. Under the hood it’s the same Magento 2 framework as Open Source, with extra modules layered on: B2B Companies + Quotes + Shared Catalogs, page builder enterprise features, content staging, target rules, reward points, gift registry, customer segments. The upgrade path is identical, composer require magento/product-enterprise-edition:^2.4.9 instead of magento/product-community-edition:^2.4.9.

Differences that matter for the upgrade:

• B2B Companies + Quotes need explicit data-validation cycles post-upgrade (schema-tied, can silently break). Add 30-50% to the upgrade timeline.
• Adobe Commerce Cloud (the managed hosting platform) has its own deploy + upgrade pipeline. You can’t just composer update, the upgrade goes through their build/deploy system. Adds ~1 week to the timeline for the Cloud-specific dance.
• Licence renewal is on a separate cycle. Upgrading the codebase doesn’t change your licence; renewing the licence doesn’t upgrade the code. Co-ordinate them with Adobe at quote time.
• Customer segments + content staging need re-test after upgrade. They’re the “sneaky breaks” on Commerce-specific upgrades.

The checker on this page works for both Open Source and Commerce, the matrix is the same.

Three options, in order of preference:

1. Check the vendor’s changelog for a newer version. The checker uses Packagist + the vendor’s published changelog, but some vendors are slow to publish. Email the vendor; ask about 2.4.9 compatibility roadmap. Many vendors have a beta available privately.
2. Swap to an alternative. For most categories (SEO, search, blog, page builder, GDPR) there are 2-5 viable alternatives. Use my extension finder to find swaps. Migration effort: ~$500, $2,500 per swapped extension depending on data migration needs.
3. Fork + patch. If the vendor is silent and there’s no swap, fork the extension into your custom code and patch it yourself. Cost: $1k, $5k per extension depending on size. Long-term maintenance burden, you now own that codebase.

Categories where swap is easy: SEO, blog, page builder, GDPR, customer reviews, related products, abandoned cart. Categories where swap is hard: payment gateways (locked to processor), ERP integrations (data-coupled), B2B-specific modules (Commerce-only).

Never option: ship a broken upgrade. An INCOMPATIBLE extension on a production storefront means silent data corruption, broken checkout, or an admin-side crash. Always swap or patch first, never ignore.

Realistic 2026 ranges for an Adobe Certified freelance dev (mine):

• 2.4.8 → 2.4.9 patch hop: $1,500, $3,500. 1-2 weeks calendar time. Mostly composer + reindex + smoke-test.
• 2.4.6 / 2.4.7 → 2.4.9: $4,000, $10,000. 3-5 weeks. Two minor versions of deprecation work, full UAT cycle.
• 2.4.4 / 2.4.5 → 2.4.9: $7,000, $15,000. 5-8 weeks. PHP 8.1 → 8.3 sits on top, plus extension audits.
• 2.4.0-2.4.3 → 2.4.9: $10,000, $22,000. 8-12 weeks. Composer 1 → 2, OpenSearch migration, layout-XML schema cleanup.
• 2.3.x → 2.4.9: $18,000, $40,000. 12-20 weeks. Effectively a re-build. PHP 7 → 8.3, full Knockout audit, every extension re-validated.

Multipliers: Adobe Commerce +30% (B2B Companies UAT). Hyvä in place +10%. ERP integration +$3k, $8k. Multi-store +20% per additional storefront. Custom checkout +$2k, $5k.

For the precise number, run /magento-upgrade-cost-calculator which factors all the multipliers, or book the audit via the form above. Agency rates run 3-5x the freelance numbers.

Three quick ways, pick whichever is easiest:

• Admin → System → System Information. Magento prints the exact version (e.g. Magento ver. 2.4.7-p4) at the top of the page, along with PHP version, MySQL version, OpenSearch/Elasticsearch version, and PHP extensions list. This is the single best place to start.
• CLI: SSH to your server, cd to your Magento root, and run php bin/magento --version. Outputs e.g. Magento CLI 2.4.7-p4.
• Composer: composer show magento/product-community-edition shows the installed version and what’s available to upgrade to. For Adobe Commerce, use magento/product-enterprise-edition.

Common gotcha: composer.json may list a different version than what’s actually installed if composer install hasn’t run since the last edit. bin/magento --version is the source of truth.

If you’re on a really old version (2.0-2.1) the System Information page may not exist; check app/etc/config.php or the footer of the admin login screen.

No. Two Magento installations can’t share the same database (schema mismatches), same Redis (cache-key collisions), same OpenSearch (index conflicts), or same domain (cookie + session collisions). It’s a hard architectural no.

What you can do:

• Blue-green deployment. Run 2.4.9 on a parallel staging environment with cloned production data. Smoke-test, get UAT-clean, then cut DNS over at a planned maintenance window. The two never serve customer traffic simultaneously, the cutover is atomic.
• Subdomain split. If you have two separate storefronts (e.g. shop.example.com and b2b.example.com) on truly separate Magento installs, each can be on a different version. This is rare but valid, usually for staged migrations where one brand goes first.
• A/B testing the upgrade. Not supported. Magento doesn’t have a built-in mechanism for serving 1% of traffic to the upgraded version. You’d need an edge-layer router (Cloudflare Workers, Fastly VCL) doing the split, doable but expensive.

The blue-green pattern is what I recommend for stores above $2M annual GMV. It costs roughly 2x hosting for the ~1 week of overlap, but eliminates downtime risk and gives you an instant rollback path. For stores under $2M GMV, in-place upgrade in a planned 30min, 4h maintenance window is fine.

Yes, Magento 2.4.9 officially supports PHP 8.3 and PHP 8.4 (8.4 added with the 2.4.9 GA in Apr 2026). Older lines:

• 2.4.7: PHP 8.2 + 8.3 (8.4 unofficial, some warnings, no GA support).
• 2.4.8: PHP 8.3 only (8.4 added experimentally in -p1).
• 2.4.9: PHP 8.3 + 8.4 fully supported.
• 2.4.10 (expected Q4 2026): probably PHP 8.4 minimum.

PHP 8.5 is not supported by any Magento version as of May 2026. PHP 8.5 entered GA in Nov 2025 but Magento’s release cadence runs ~12 months behind PHP. Expect 2.4.10 (Q4 2026) or 2.4.11 (Q2 2027) to add it.

If you’re upgrading PHP separately from Magento: upgrade Magento first, then PHP within the same maintenance window. Doing PHP first on an older Magento breaks the framework (PHP 8.3+ deprecates things 2.4.6 still depends on). The exception: PHP 7.4 → 8.x is so foundational that some teams do PHP first on a heavily-patched older Magento, then Magento, but it’s riskier.

Yes, Magento upgrades are cumulative. You can composer update from 2.4.5 to 2.4.9 in a single run; all the intervening data patches execute in order during setup:upgrade. Adobe explicitly supports skipping minor versions.

What you can’t skip:

• The deprecation work from each intervening version. 2.4.6 introduced the OpenSearch requirement (Elasticsearch removed), 2.4.7 deprecated Knockout components, 2.4.8 bumped to PHP 8.3. All of those land on you at once if you skip.
• The dependency cascade. Composer will resolve to the latest compatible versions of every dependency at once. If you have third-party extensions with tight constraints, this can fail spectacularly, the resolution might find no compatible combination.
• The UAT cycle. Skipping versions doesn’t reduce UAT, it concentrates it.

Rule of thumb by version distance:

• 2.4.6 → 2.4.9 or 2.4.7 → 2.4.9: direct jump, single composer run.
• 2.4.4/2.4.5 → 2.4.9: direct works, but add 50% extra UAT time.
• 2.4.0-2.4.3 → 2.4.9: stop at 2.4.4 or 2.4.6 first.
• 2.3.x → 2.4.9: always two-hop via 2.4.4.

Different tool, complementary purpose. Use both in sequence.

This page (/magento-version-checker): tells you whether and how to upgrade.

• Input: your current Magento + PHP + extensions.
• Output: EOL status, recommended target, multi-hop path, breaking-change checklist, PHP warnings, per-extension compatibility flags.
• The “is my version dead, what’s the safest path forward, and will my extensions survive” tool.

The cost calculator (/magento-upgrade-cost-calculator): tells you how much it’ll cost and how long it’ll take.

• Input: version distance, SKU count, custom modules count, extensions count, Hyvä yes/no, B2B yes/no, multi-store, custom checkout, ERP integration.
• Output: $ range, week range, risk factors, cost breakdown.
• The “what budget do I need” tool.

Recommended workflow:

1. Run this checker first to confirm your version is upgrade-target-worthy and your extensions are ready (or need swap).
2. Run the cost calculator next to budget based on the path the checker recommended.
3. Book the audit via either form to get a written, locked fixed-price quote within 24 hours.

Both tools are free, both run with no signup, neither stores your input.