Magento 2 Security Upgrade
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. We move stores onto a supported release — fixed price, fixed scope, every integration regression tested before it goes anywhere near production.
What "unsupported" actually means
It doesn't mean your store stops working. It keeps taking orders exactly as it did in July. That's the problem — nothing visible changes, so the decision keeps getting deferred until something forces it. Adobe stops fixing your version. When a vulnerability is found in Magento core after your version's support ends, Adobe issues a patch for supported releases only. Yours stays open. Magento is one of the most actively targeted e-commerce platforms in the world, and attackers read the same release notes your developers do. PCI DSS expects supported software. The standard is built around software that can be patched. An unsupported version is a much harder conversation with your acquirer or payment provider — and it's a conversation that arrives on their schedule, not yours. Extension compatibility decays. Third-party vendors stop testing against old cores. Each month the gap between your store and the current ecosystem widens, and the eventual upgrade gets more expensive. Waiting doesn't save money; it defers a bill that's growing.
What's actually involved
Magento upgrades get quoted badly because the platform version is the easy part. The cost lives in everything built on top of it. Here is the honest breakdown.
The platform requirements have moved
Magento 2.4.8 requires PHP 8.3 or 8.4 — 8.1 and 8.2 are no longer supported. It needs MySQL 8.4 or MariaDB 11.4, and OpenSearch 2.x, with Elasticsearch support removed entirely. If your store is still on Elasticsearch, catalogue search stops working the moment you upgrade until it's reconfigured and reindexed.
Third-party extensions are the real cost
Every module needs a version supporting both the new Magento release and PHP 8.3 or 8.4. Some vendors have shipped one. Some have shipped one that costs money. Some have abandoned the extension entirely. This is the biggest variable in any upgrade quote, and the one most quotes guess at rather than check.
Custom code written for older PHP
Code written against PHP 8.1 often relies on behaviour that 8.3 and 8.4 tightened or removed — implicit nullable types and dynamic properties are the usual offenders. Every custom module and theme override needs reviewing.
Frontend JavaScript
jQuery, RequireJS and TinyMCE all move with the platform. Custom admin widgets and theme scripts built against earlier versions frequently break, and they break quietly — often somewhere in checkout.
Integrations, not just the platform
An upgrade is where PIM, ERP, 3PL and CRM connections quietly break. We inventory every integration before we start, test each one on staging, and hand you the list of what was touched.
Our process
Audit first, always
We don't quote an upgrade blind. The £950 audit produces the extension inventory and infrastructure picture the quote is built from — and it's credited in full against the project.
Full-size staging clone
Built from production data, not a sample. Large catalogues are where data patches stall, and you want to discover that on staging.
Upgrade and remediate
Platform, PHP, database and search versions, then extensions and custom code, in dependency order.
Regression testing where it matters
Checkout, payment, search, catalogue, account, and every integration you rely on. Tested by a person, on real journeys.
Deploy in a window you choose
With a rollback plan written down before we start, not improvised on the night.
Two weeks of hypercare
Included. Priority response on anything that surfaces after launch.
Who this is for
Most merchants do not know which version they are on. That is not negligence — it is what happens when the last upgrade was done by an agency that has since moved on.
- ✓ You're on Magento 2.4.6 or earlier, or nobody can tell you which version you're on
- ✓ You've been quoted for an upgrade and want to know whether the number is credible
- ✓ Your last agency has moved on and nobody currently owns the platform
- ✓ Compliance, your acquirer or your insurer has started asking questions
It's for you if
- ? You're on 2.4.7 or later with an active support arrangement
- ? You're planning to leave Magento entirely within the next six months — talk to us about replatforming instead
It isn't if
Upgrading and want the frontend fixed too?
An upgrade combined with a Hyvä frontend migration is £18,000 to £26,000 — meaningfully less than doing them a year apart, because the regression testing, the staging build and the deployment happen once instead of twice. If a Hyvä migration is anywhere on your roadmap, doing it alongside the upgrade is the cheapest it will ever be.
Find out where you stand
If you don't know which version you're running, that's the first thing to fix and it costs nothing. Send us your domain and we'll check.