Online Shops Stay on Unsupported Versions for One Reason. It Is Rarely the Platform.

The email from the agency arrives in the first week of January, as it has for three years. The version of the platform your shop runs on no longer receives security fixes. We recommend moving to a supported version.

You ask the question you asked last year. What would it take?

The answer has not changed either. It depends on your customisations. How many are there? The agency is the third to look after the shop in nine years. It does not know, and neither do you.

What We Found

For this article we went through the public record on online shops left on platform versions their maker no longer fixes: the published support dates, security reporting of attacks on shops running old versions, and the US government’s list of flaws known to be exploited, from 2020 to 2026.

Four findings stand out.

The end dates are published, and they keep arriving. Magento 1, a widely used open-source shop platform, has had no fixes from its maker since 30 June 2020. On that date a news report counted “over 100,000 active Magento 1.x installations”. Nothing stops working on the day. The fixes stop coming.

In one recorded wave, old shops were hit together, through an add-on. In early 2022 a security firm found several hundred infections on the same day, all with the same malicious code, on shops running Magento 1. The way in was a known flaw in an add-on. The wider breach covered several hundred online shops on that version, with card-skimming code, which copies card details at checkout, loaded on all of them. This is an older case. The shops are not named, and no loss is recorded.

A supported version helps only when its fixes are applied. On the platform’s current version, one security firm reported in October 2025 that about three in five of the platform’s shops were still exposed to a flaw six weeks after it was made public. The firm sells shop security.

Flaws in the platform go on being used. Magento has 5 flaws on the US government’s list of flaws known to be exploited. Four of them were added since October 2023, the latest on 24 September 2026.

The record does not explain why shops stay. Our reading is that they rarely stay out of carelessness. They stay because nobody has listed the custom code and the add-ons built on the shop, so nobody can say what a move would have to carry.

What Waits on the Code Nobody Has Listed

An unsupported shop is usually discussed as a security problem. Our reading is that it also holds the business in place.

The first cost is the warning with no decision. Answering the agency’s email takes a list nobody has, so the move waits for another season.

The second cost is growth on the wrong side. Every new offer, voucher rule and connection to the warehouse is built on the old version, and each is one more thing a move must carry.

The third is the quote that cannot narrow. Nobody can price moving your shop without knowing what is in it, so the range stays as wide as last year.

This is our reading of the evidence. It is not a measured market figure.

Four Ways Forward, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep the old platform and have the agency apply what fixes it can	A move already has a firm date, and the shop has little custom code	On an unsupported version the maker issues no new fixes. It buys time and nothing else
Move the whole platform at once with a platform specialist	The shop is close to standard, with few customisations and add-ons	Every custom rule is found during the move, priced as a change, and checked by shoppers on launch day
Rebuild the shop’s own rules beside the old shop	The pricing, offer and order rules are the firm’s own and change often	Started without a list, nobody knows which rules matter, or what touches them
Write down the custom code first	The shop is old, much changed, and looked after by several agencies in turn	It costs money before anything moves, and the list may show more custom code than anyone expected

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own shop, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Customisations on the shop	Known to whoever built them	Every one written down in plain words	The specification
Add-ons	Counted, at best	Each listed with its maker and whether anyone still maintains it	The list beside the specification
Code that runs at checkout or reads customer details	Not marked	Marked, part by part	The risk register
A verdict on each part	Everything assumed to be needed	Each part marked keep, rebuild or retire, agreed with your own people	The staged plan
Custom rules still on the unsupported version	Not counted	Counted, and falling with each stage	Reported at every review

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the shop, what was built on it, and the decision that keeps being put off. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the custom code built on your shop. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the shop’s own pricing, offer and order rules, rebuilt beside the old shop on technology that is still supported. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

We patch nothing: we do not apply the platform’s fixes or fix flaws while the shop waits. We secure nothing: we do not scan, guard or monitor the shop, and the assessment leaves it exactly as exposed as it was the day before. We move no platform and choose no platform: the next platform is your decision, and the move is made by a platform specialist. We do not host the shop. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP; PHP is a language we read, not one we build in. We say nothing about what card-payment or data protection rules require, and we have no published case of this work for a retailer.

What changes for the business:

Role	What they gain
CEO	The move that has been put off every season becomes a decision of known size. The owner can say what holds the shop where it is.
CTO or CIO	A written list of every customisation, add-on and connection, and which of them still matter. The team stops guessing what a move would break.
CFO	The cost of staying and the cost of leaving sit side by side for the first time.
CISO	The custom code and add-ons that touch checkout and customer details are listed part by part, so the security team can rank them.
Head of marketing	Marketing knows which offers, vouchers and loyalty rules live in old code, and plans campaigns on fact.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
Magento 1 has had no fixes from its maker since 30 June 2020, and over 100,000 shops were on it at that date.	Our part is narrower than this case. We do not supply fixes and we do not move the platform. We read the custom code that keeps a shop on an old version and write down what a move would have to carry.
Hundreds of shops on that version were infected in one day in 2022, through a flaw in an add-on.	Our part is narrower than this case. We do not scan or secure shops, and we promise no protection from attack. We write down the shop’s own code and the add-ons it relies on, so the retailer can decide what to rebuild, retire or move.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start with what was built on the shop, because that is what keeps it on the old version.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →