Magento Health & Upgrade Audit
Magento and Adobe Commerce 2.4.5 and 2.4.6 stopped receiving security patches on 11 August 2026; 2.4.4 went unsupported in April. Six stages, one senior Magento 2 engineer, and a document that tells you exactly where your store stands, what it’s exposed to, and what it costs to fix.
The deadline has already passed
Adobe ended support for Magento Open Source and Adobe Commerce 2.4.5 and 2.4.6 on 11 August 2026. Version 2.4.4 went unsupported in April. If your store runs any of those, three things are true today that weren't true in July. Security patches have stopped. Any vulnerability discovered in your version from here will not be fixed by Adobe. It stays open until someone backports a patch by hand — and Magento is among the most actively targeted e-commerce platforms there is. PCI DSS becomes a harder conversation. The standard expects software that is supported and patchable. That question tends to arrive through your payment provider or your acquirer, usually at a moment you didn't choose. Your extensions start drifting. Third-party vendors stop testing against unsupported cores. Every future integration, every new payment method, every plugin update gets more expensive and more fragile. Most merchants we speak to don't know which version they're on. That isn't negligence — it's what happens when the last upgrade was done by an agency that has since moved on.
Audited by the people who'd do the work
The engineer writing your report is the one who would run the upgrade. They’ve done it on stores carrying six-figure catalogues and on stores doing forty orders a week, and the report says which of those yours resembles. No account manager relaying findings they don’t understand.
Six areas, checked by hand
No automated scan report with our logo on it. A senior engineer works through your store, your codebase and your infrastructure, and writes down what they find.
01 — Version and support status
Your exact Magento version and patch level, its position against Adobe's lifecycle, and how long you've been running without cover.
02 — Security exposure
Known vulnerabilities affecting your version, admin hardening, file permissions, publicly reachable endpoints, and credential and API key hygiene.
03 — Performance, measured properly
Core Web Vitals from real user field data — LCP, INP and CLS — alongside lab testing on your three highest-traffic template types. Weighted to mobile, because that's where the revenue and the losses are.
04 — Extension inventory
Every third-party module, its version, whether it's still maintained, whether it supports PHP 8.3 and 8.4, and whether a Hyvä-compatible release exists. This table is the biggest driver of upgrade cost, and it's what most quotes guess at.
05 — Theme and frontend
How much custom Luma work exists, what carries across to Hyvä untouched, and what has to be rebuilt. This is where fixed-price quotes usually go wrong.
06 — Hosting and infrastructure
Your PHP, MySQL or MariaDB and search versions against what your upgrade target requires — 2.4.8 needs PHP 8.3 or 8.4, MySQL 8.4 or MariaDB 11.4, and OpenSearch 2.x, with Elasticsearch support removed entirely. Plus caching, indexing and cron health.
What lands in your inbox
A written report of 15 to 25 pages, specific to your store. Written for a commercial decision-maker, with the technical detail in appendices for whoever inherits the work. Findings ranked by commercial risk, not by CVSS score — what actually threatens revenue, first. A named upgrade target, and the reasoning for that version over the alternatives. A costed remediation plan split three ways: do now, can wait a quarter, not worth doing. An extension-by-extension compatibility table you can hand to any developer. A 45-minute walkthrough with the engineer who did the work — not an account manager. All raw data and test output, so any agency can act on it. Including one that isn't us.
How the audit runs
Day 0 — Access
A 30-minute call. You give us read-only admin access and read access to hosting or your repository. Nothing is deployed, nothing is changed.
Days 1–4 — Technical review
A senior engineer works through all six areas by hand: version status, security exposure, performance, extensions, theme and infrastructure.
Day 5 — Costing
Findings ranked by commercial risk, and a remediation plan costed three ways: do now, can wait a quarter, not worth doing.
Days 5–7 — Report delivered
A written report of 15 to 25 pages, plus all the raw data and test output. Yours outright.
Within 10 days — Walkthrough
A 45-minute call with the engineer who did the work, at your convenience. Not an account manager.
Who this is for
The audit suits stores where nobody internally can answer a simple question: are we exposed, and what would fixing it cost? If you are already on a supported version we will tell you on the first call and we will not take your money.
- ✓ You're running Magento 2.4.6 or earlier, or you don't know which version you're on
- ✓ Your store turns over roughly £250,000 a year or more
- ✓ Nobody internally can answer "are we exposed, and what would fixing it cost?"
- ✓ You've been quoted for an upgrade and want to know whether the number is real
It's for you if
- ? You're already on 2.4.7 or later with an active support agreement
- ? You want the cheapest possible upgrade quote rather than an accurate one
It isn't if
Find out where you actually stand
A week from now you could have a costed, prioritised plan instead of an open question. Not sure which version you are on? Send us your domain and we will check for free — and if you are on a supported release, we will tell you that and leave you alone.