An "Unsupported" Entry With No Date Is Not a Plan. A Shrinking List of Custom Code Is.

The risk committee asks the question it asked last quarter. When will the online shop be off the unsupported version?

The answer in the notes has not changed: target date to be confirmed. Three quotes to move the shop sit in the same folder. The highest is three times the lowest, and each carries an asterisk: subject to the extent of custom work.

One agency promises it in weeks, with AI tools. Nobody can say how anyone would know that the new shop charges every customer what the old one does.

What We Found

We looked at what happens to shops after the end date and after a move, at what one seller of AI-assisted shop migration says its own tools cannot do, and at one survey of mid-size firms.

The date passes, and the shops stay. 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”. It is a 2020 figure; how many remain today, we could not find.

A move ends nothing unless the 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. A supported version helps only when whoever runs the shop applies its fixes.

The tools do the standard part. One seller of AI-assisted shop migration states the limit of its own method: complex business logic, custom pricing rules, unusual checkout flows and the way each integration behaves still need a person who understands them. Those are the parts of a shop that nobody has listed.

Old technology is said to hold mid-size firms back. In one vendor-sponsored survey of a few hundred leaders at mid-size US and UK manufacturers, retailers and wholesalers, about seven in ten agreed that outdated technology is holding them back.

What a Written Scope Opens Up

A list of what was built on the shop is usually seen as the technology team’s homework. Our reading is that it frees more than that team.

• The risk list gets a date. “Unsupported” stops being an entry with no end. It becomes a set of named parts, each with a stage, and the last stage has a date.
• Quotes become comparable. Three figures for one written scope can be set side by side.
• “Done” gets a meaning. With a record of what each rule does, a new shop can be checked rule by rule, before a shopper finds the difference.

This is our reading. It is not a measured market figure.

Three Ways to Buy a Shop Move, Weighed

Option	When it fits	What it risks
Ask platform specialists to quote from the storefront and a list of add-ons	The shop is close to standard, with few customisations	Each quote rests on a different guess. The custom work is found after the contract, as change requests
Choose an agency and let it discover the custom work as it goes	The firm trusts one agency and can carry an open budget	The cost and the date move with every discovery, and nothing defines what “done” means
Write down the custom code first, rebuild the shop’s own rules beside the old shop, then have the platform move priced against the written scope	The shop is old, much changed, and its own rules matter to the business	It takes stages and costs money before the move starts. The scope may be larger than the lowest quote assumed

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Customisations and add-ons on the shop	Known to whoever built them	Every one listed; each add-on with its maker and whether it is still maintained	The specification
Code that touches checkout	Not marked	Marked, part by part	The risk register
Custom rules still on the unsupported version	Not counted	Moved off module by module; the count falls at every stage	Reported at every review, with the traceability matrix
Quotes to move the platform	Each from its own guess, with an asterisk	Compared against one written scope	The quotes set beside the specification
The “unsupported” entry on the risk list	”Target date: to be confirmed”	A date, tied to the last stage and the platform move	The risk list beside the staged plan
What “done” means for each rule	The new shop is open	The same basket gives the same total in old and new	The specification, rule by rule; for modules we rebuild, the traceability matrix

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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.

A small part of the finished list might look like this.

Custom part	Add-on it relies on	Status
Festival bundle offer	A discount add-on whose maker no longer updates it	Stage 1: rebuilt beside the shop and accepted; off the old version
Loyalty points	None	Stage 2: still on the old version until its module is accepted
Gift-card step at checkout	A gift-card add-on, still maintained	Marked as checkout code; in the written scope for the platform move

The rows above are an illustration, not taken from a real shop.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the shop, the quotes on the table and the date nobody can give. 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.
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 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.
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. A traceability matrix links every old function to its replacement. 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 above. As each module is accepted 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.

This has a price. It does not make the old shop safe: until the platform move, the shop is as exposed as it was, and your own team or agency must go on applying what fixes exist. We patch nothing and secure nothing, and we cannot promise that an attack will not happen in the meantime. We move no platform and choose no platform: the move is made by a platform specialist you choose. Some rules are too tangled in the checkout to lift out, and the scope may be larger than the lowest quote assumed. It is slower than signing the cheapest quote, and it is the first time the “unsupported” entry has a date. We have no published case of this work for a retailer.

At the end you hold the specification, the traceability matrix for every module we rebuilt, and a risk list whose “unsupported” entry has a date. Choosing the platform and the specialist is your decision.

What changes for the business:

Role	What they gain
CEO	The firm chooses its next platform and its supplier freely, because what the shop does is on paper the firm owns.
CTO or CIO	Proof, rule by rule, that a new shop charges and behaves as the old one did.
CFO	Quotes that can be compared, because every bidder prices the same written scope.
CISO	The move gets a date that can hold, so “unsupported” stops being an entry with no end.
Head of marketing	The offers shoppers rely on work the same on the day after a move, because each one was written down and checked.

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

The case	What IOanyT does
Magento 1 lost its maker’s support on 30 June 2020, with over 100,000 shops on it at that date.	Our part is narrower than this case. We do not move shops between platforms. We write down what a shop’s custom code does and rebuild its own rules, so the firm can get the move priced.
On the current version, about three in five of the platform’s shops were still exposed six weeks after a flaw was made public.	Our part is narrower than this case. We do not apply fixes or run shops. A move ends nothing unless whoever runs the new shop keeps it up to date, and that is their work, not ours.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next time someone asks when the shop leaves the old version, the answer has a date.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →