Hundreds of Shops in One Day
A study of online shops left on a platform version its maker no longer fixes, from the public record: hundreds of shops infected in one day, the published dates, what India's government announced on showing price cuts, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. None of the shops referred to here was an IOanyT client, and IOanyT had no part in the events described. The shops in the record are not named. Everything about them comes from the public record.
| Organisation type | Online shops running a platform version whose maker had stopped fixing it, set beside the platform’s published dates and a rule on price cuts coming into force in India |
| Size band | The shops: not recorded. Our reader: a mid-size retailer, brand or online seller with a much-changed shop |
| Region | The shops: not recorded. The rule on price cuts: India |
| The decision at stake | What to do with a shop on a version its maker no longer fixes, when nobody can list the custom code and add-ons built on it |
| The public outcome | In early 2022, hundreds of shops on the unsupported version were infected on the same day, through a known flaw in an add-on, in a wider breach with card-skimming code loaded on all of them. An older case; no loss is recorded |
| Why it matters to a mid-size retailer | Most shops on an old version stay for the same reason: nobody holds a list of what was built on them. The question is whether that list is made on a plan, or under pressure after something has happened |
2. The Business Problem, in the Buyer’s Words
“Every January the agency tells us our shop version gets no more security fixes and we should move. I ask what it would take, and the answer is always that it depends on our customisations. Three agencies have looked after the shop in nine years and none of them left a list. Meanwhile marketing’s best offers keep getting cut down because nobody dares touch the old discount module. I know we have to move. I cannot see what we would be moving.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm is caught between a version nobody fixes and custom code nobody has listed. Staying looks cheaper every year, and each season adds more code to the side that has to move.
3. What We Found
Method. 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 an unsupported version and of stores left unpatched on the current one, the US government’s list of flaws known to be exploited, a migration seller’s own statement on its tools, and a rule on price cuts announced in India, from 2020 to 2026.
Hundreds of shops in one day. In early 2022, a security firm found that shops on Magento 1, a widely used open-source shop platform, were being infected in a wave.
| What | Public record |
|---|---|
| Infections found in one day | Several hundred, on the same day, all with the same malicious code |
| The way in | A known flaw in an add-on |
| How wide the breach was | Several hundred online shops running the old version |
| What was loaded | Card-skimming code, which copies card details at checkout, on all of them |
| The shops | Not named; size not recorded |
| The loss | Not recorded |
The version had no fixes since 2020. Magento 1 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”. How many remain today, we could not find. Later versions have passed their own end dates: version 2.3 on 30 September 2022, and version 2.4.5 on 25 November 2024.
Moving is not the end. On the 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. Magento has 5 flaws on the US government’s list of flaws known to be exploited, 4 of them added since October 2023, the latest on 24 September 2026.
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.
A rule on price cuts in India. The government announced on 10 September 2026 that the Consumer Protection (E-Commerce) (Amendment) Rules, 2026 “shall come into force from January 1, 2027”. Under them, “Where a price reduction is announced, the reduced price and prior price shall both be displayed”, the prior price being “the lowest price at which the goods or services were offered during the 30 days preceding the announcement”. The release names “e-commerce entities” generally, and “Marketplace e-commerce entities” for some other duties; we did not read whether that covers a retailer’s own shop.
Our reading of why shops stay. These four are our reasoning from the record above. None is a finding of any source.
- Nobody has a list of what was built on the shop: pricing and offer rules, checkout changes, loyalty schemes, links to the warehouse, the courier and the accounts, added over years by different agencies.
- The firm’s own rules are written inside the old version, so they can leave only when the whole shop leaves.
- The firm’s own code leans on add-ons whose makers have stopped, and an add-on cannot be removed while the shop’s modules depend on it.
- With no record of what the shop does, a move can be neither priced nor checked, so every quote begins “it depends”.
What this record does not show. The shops are unnamed, their size is not recorded, and the record gives no loss; this study adds nothing to it and does not describe what any shopper lost. The record does not say the shops were attacked because of custom code. The figures on infections and on unpatched stores come from security firms that sell shop security, and the statement on tools comes from a firm that sells migrations. We found no named retailer of any size harmed because its shop platform was unsupported, and no case from India or the Middle East. We found no figure for what an attack or a platform move costs a mid-size shop. The rule on price cuts is taken from the government’s press release, not the text of the rules; no source ties it to any retailer’s old system, and the link is our reading.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| 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 | Right only as a bridge with an end date |
| 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 | We would advise against this for a much-changed shop whose custom code nobody has listed |
| 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 | Right, once the list exists |
| Write down the custom code first | The shop is old, much changed, and looked after by several agencies in turn | Costs money before anything moves; may show more custom code than expected | Our recommendation, as the first step |
What we would have advised against: for a firm in this position, renewing the same warning every January with no date to end it, and buying the whole platform move on a quote made from the storefront before anyone has written down what the shop does.
5. Our Recommendation, and the Decision It Asks of the Board
For the custom code a retailer built or had built on its shop (pricing, offer and loyalty rules, checkout changes, order handling and the links to the warehouse, courier and accounts): write it down first, with the add-ons each part relies on. Then rebuild the shop’s own pricing, offer and order rules module by module beside the old shop, on technology that is still supported, starting with the rules the planned offers need first. The old shop keeps trading until each module is accepted. The platform move itself is done by a platform specialist the retailer chooses, priced against the specification, subject to its own contract with its present supplier. The retailer’s own team or agency keeps the old shop running and applies what fixes exist until then.
The decision it asks of the board: approve a fixed-price assessment now, separately from the agency’s yearly fee. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops receiving the same warning each year and starts approving a plan whose last line is a date.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the retailer’s own figures, taken in the first review.
| 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 |
| Offers waiting on old code | Not linked to any part of the shop | Each listed against the custom rule it needs | The staged plan |
7. How IOanyT Would Work
- 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.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
- 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.
- 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.
- 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.
8. What the Client Would Own
- The map and the specification: what the shop’s custom code does, in writing, and the written scope a platform specialist can price, subject to its own contract with its present supplier.
- The risk register: what the assessment found, listed before any price is set.
- The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
- The code: the rebuilt modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT patches nothing: it does not apply a platform’s security fixes or fix known flaws while a shop waits to move.
- IOanyT secures nothing: it does not scan, guard or monitor a shop, and does not respond to an attack. Nothing here makes a shop on an unsupported version safe; until the platform move, the old shop has the flaws it had before. Nothing here is a promise that an attack will not happen.
- IOanyT moves no platform and chooses no platform: it does not install, upgrade or move a packaged shop platform or a packaged ERP product, and it is not a partner of any platform maker. The next platform is the retailer’s decision, and the move is made by a platform specialist.
- IOanyT does not keep the old shop running or host it. The retailer’s own team or agency does.
- PHP is a language IOanyT reads, not one it builds in. The older technologies it reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
- IOanyT does not offer a compliance, audit or legal service, and says nothing about what card-payment, consumer-protection or data protection rules require of a particular firm. Meeting the amended e-commerce rules is the seller’s own work.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a retailer. IOanyT has no published case of this work for a retailer.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| Security news report, February 2022 | The shops infected in one day |
| Help Net Security, 29 June 2020 | End of support for Magento 1, and the installations live on that date |
| endoflife.date, Magento | Support dates for later versions |
| Security news report, October 2025 | Stores still vulnerable six weeks after a flaw was made public |
| CISA catalogue | Flaws known to be exploited |
| A vendor’s article, 9 March 2026, updated 12 June 2026 | A migration seller’s statement on the limits of its tools |
| PIB, Ministry of Consumer Affairs, 10 September 2026 | The amended e-commerce rules and the prior price |
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.
Read the research notes on this issue
Unsupported shop software
Research note 1
Online Shops Stay on Unsupported Versions for One Reason. It Is Rarely the Platform.
Online shops stay on platform versions their maker no longer fixes. What the public record shows, why the shops stay, four ways forward and our benchmark.
Research note 2
New Offers Are Waiting on Shop Code Nobody Can Change.
New offers, campaigns and price-cut display rules all touch custom code in an old shop. What waits, four ways to answer it and a decision benchmark.
Research note 3
An "Unsupported" Entry With No Date Is Not a Plan. A Shrinking List of Custom Code Is.
Quotes to move an online shop come in far apart. The benchmark we would set, and the path from a written scope to a move that can be priced and checked.