A Few Old Parts Hold the Whole Shop on an Old Version. Everything Else Waits With Them.

Your developer has spent two weeks on a copy of the shop, trying it on a supported version of the language.

The report is short. Most of the code runs. Three parts do not. One is the module that works out delivery charges, written in a style later versions no longer accept. One is a payment add-on whose maker closed years ago. One is a set of calculations that live inside the database.

Meanwhile the courier you want to add sends its connection kit. It needs a newer version than the shop runs. The developer’s advice is to rewrite the shop, or leave it alone.

What We Found

We looked at the published end dates of PHP and of the MySQL database, the share of websites still on old versions, and what one developer found inside an old PHP application. Every figure is about websites or developers in general, not shops alone, and we name no retailer.

The versions sites moved to are ending too. PHP version 8.1 lost its security fixes on 31 December 2025. MySQL 8.0 reached the end of its support on 30 April 2026, and the last of the MySQL 5.x line, version 5.7, on 31 October 2023. A shop that upgraded once, years ago, may already be on a version that no longer gets fixes.

Many sites are still on the older line. Among websites on the most widely used website software, which many small shops run with a shop add-on, 17.3% run MySQL 5.x, an out-of-support database line, and 36.9% run a version of PHP that no longer gets security fixes. Both come from that software’s own live usage feeds, read on 12 October 2026.

Old applications lean on many outside packages. One developer who inherited an old PHP application wrote that it relied on dozens of outside packages. It is one person’s account, and the application was not described as a shop. When a package’s maker stops, the package stays on the version it was written for.

What Waits While the Shop Is Held on an Old Version

The usual choice is the one in the scene: rewrite the shop, or leave it. The question that decides the matter is in neither: what can the business not do while a few old parts hold the shop where it is?

New add-ons. Our reading, and only that: a shop runs on one version of its language at a time. Add-ons and libraries are written for the versions their makers support. When the shop is held on an old one, the newer add-on the business wants may not install at all, or only in an old release.

Payment and courier connections. The same reasoning applies to the connection kits payment companies and couriers give their sellers. When a provider moves its kit to newer versions, a shop held on an old one stays on what it has, or someone writes a workaround in old code.

The rest of the code ages while it waits. Code that would have upgraded without trouble goes another year without fixes, because three parts cannot go.

This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own business.

Four Ways to Answer a Shop That Cannot Be Upgraded, Weighed

Option	When it fits	What it risks
Upgrade in place, by your own team or agency	The code has tests around it, and the blocking parts can be changed safely	Without tests, the blocking parts are changed with nothing to compare against
Pay the hosting company to keep the old version	An upgrade already has a firm date, and nothing new is waiting to be added	The PHP project issues no more fixes for the old version; any fixes depend on the hosting company. New add-ons and connections still wait
Rebuild the whole shop at once	Most of the shop no longer fits the business anyway	It pays to rewrite code that already works, and the decision is often too large to approve, so nothing happens
Write down the dependencies, then rebuild only the parts that block, module by module	The shop is old and much changed, and a few parts stopped earlier attempts	Old and new parts run side by side, and for a time you pay for both. The shop has code in two technologies, and the list may show that the blockers are most of the shop

Where You Are Now, and Where You Should Be

Before the next year on the old version is agreed, we would set a benchmark for the decision itself.

Measure	Typical starting point	Where it should be	How it is checked
The cost of staying	The hosting fee alone	The fee, workarounds, add-ons and connections that wait, and staff time, in one place	The cost comparison
The size of the job	The whole shop, or nothing	Only the parts that block, listed by name	The staged plan
Add-ons and connections waiting	Not linked to any part of the shop	Each listed against the part that blocks it	The staged plan
Logic inside the database	Left where it is, unread	Read, written down, and marked keep or rebuild	The specification
The size of one commitment	One large rewrite, or nothing	One module, with the freedom to pause after any accepted module	The staged plan
The upgrade of the rest	Waiting on the blockers	Done by your own team or agency, against one written scope	The specification

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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the shop, the parts that stopped the last upgrade, and what the business is waiting to add. 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 shop’s own code and the database beneath it. 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. 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 parts that block an upgrade, rebuilt on technology that is still supported. We never do a single cutover. 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.

What you need to bring: a budget for the assessment; read-only access to the code once it begins; someone from operations or finance to accept each rebuilt part, with real orders to test; a way for the old shop to call each rebuilt part, agreed with whoever looks after it; and your own team or agency to run the shop and do the upgrade.

What we do not do: we do not upgrade in place; the upgrade of the language and the database is your own team’s or agency’s work. We patch nothing, and a rebuilt part is not a secured shop: until the upgrade is done, the rest of the shop is still on versions nobody fixes. We do not host the shop or run its servers. PHP is a language we read, not one we build in. We do not choose or install add-ons, or connect a payment company or a courier on the old shop. We have no published case of this work for a retailer.

What changes for the business:

Role	What they gain
CEO	A few old parts stop holding the whole shop on a version nobody fixes.
CTO or CIO	The blocking modules are gone, and what remains is code the team can upgrade in the ordinary way.
CFO	Money goes to the parts that block, released one accepted module at a time, and not to rewriting what already works.
CISO	There is a route to a supported version that does not wait for one large rewrite.
COO	The jobs dispatch depends on are moved one at a time, each compared with the old before it takes over.

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

The case	What IOanyT does
MySQL 8.0 reached the end of its support on 30 April 2026, and 17.3% of sites on the most widely used website software still run the older 5.x line.	Our part is narrower than this. We do not upgrade databases or move data between them as a service. We read the logic held in the database and rebuild the parts that block an upgrade, one module at a time.
One developer’s inherited PHP application relied on dozens of outside packages.	We write down which outside packages each part leans on. Where an abandoned package is part of what blocks the upgrade, the part that depends on it is a candidate for rebuilding. We do not maintain or patch other makers’ packages.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The size of the job should be the size of the parts that block, not the size of the shop.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →