Upgrade It and See

1. At a Glance

Issue study · From the public record. This study names no organisation as its case, because the public record holds none: we found no named retailer harmed by an out-of-support language or database under its shop. It is built from published dates and published figures, all of them about websites or developers in general, not shops alone. Nothing here describes an IOanyT client, and IOanyT had no part in anything described.

Organisation type	Websites written in PHP and running on MySQL, the layers under many online shops, set beside their published end dates
Size band	The websites: all sizes, not recorded. Our reader: a mid-size retailer, brand or online seller with an old, much-changed shop
Region	The figures: worldwide, not broken down by country. No case from India or the Middle East was found
The decision at stake	What to do when the language version and the database under the shop no longer get security fixes, and every attempt to upgrade has been rolled back
The public outcome	About half of all websites written in PHP run a version that no longer gets security fixes, by our own sum from published version shares. Three flaws in PHP itself are on the US government’s list of exploited flaws, two marked as used in ransomware
Why it matters to a mid-size retailer	A shop that cannot say where its code depends on the old versions cannot plan an upgrade. It can only try one and watch, and every rolled-back attempt makes the next harder to approve

2. The Business Problem, in the Buyer’s Words

“The hosting company says the PHP version under our shop is going. Last year we tried the upgrade on a copy. The checkout went blank, we fixed it, went live on a Saturday night, and on Sunday the warehouse had no orders. We switched back. Now the developer says three old parts will never run on the new version, and we should rewrite the whole shop. I cannot approve that. I cannot leave it either. Nobody can tell me what the shop actually needs from the old version.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between versions nobody fixes and an upgrade nobody can vouch for. Leaving it looks free every year, and every year more code is written on the old versions.

3. What We Found

Method. We went through the public record on websites left on old versions of PHP, the language many online shops are written in, and of MySQL, the database many keep their orders in: the published end-of-support dates, the published shares of websites on each version, the US government’s list of flaws known to be exploited, one survey of PHP developers and two developers’ own accounts, from 2018 to 2026.

The published dates. Each version gets security fixes until a published date, and then no more. Nothing stops working on the day.

Layer and version	Security fixes or support ended
PHP 5.6	31 December 2018
PHP 7.4	28 November 2022
PHP 8.0	26 November 2023
PHP 8.1	31 December 2025
PHP 8.2	Security fixes only, until 31 December 2026
MySQL 5.5	31 December 2018
MySQL 5.6	28 February 2021
MySQL 5.7	31 October 2023
MySQL 8.0	30 April 2026

How many sites are behind. By our own sum from the published shares of each PHP version, read on 12 October 2026, about half of all websites written in PHP run a version that no longer gets security fixes. Among websites on the most widely used website software, which many small shops run with a shop add-on, more than a third run a PHP version that no longer gets security fixes and about one in six run MySQL 5.x, an out-of-support database line, according to that software’s own live usage feeds read on the same day.

The language itself is on the list of exploited flaws. Three flaws in PHP itself are on the US government’s list of flaws known to be exploited, and two are marked there as used in ransomware. The most recent, in PHP on Windows in CGI mode, lets an attacker run commands and was added on 12 June 2024. Flaws from 2012 and 2019 were added on 25 March 2022.

What developers say about the work. In one survey of more than a thousand developers whose main language is PHP, about a third said they still write no tests at all. One developer who inherited an old PHP application wrote that it relied on dozens of third-party packages. Another, writing about old code in several languages, wrote that nothing is more frightening than changing a critical old system that has no tests. The last two are single accounts, and neither application was described as a shop.

Our reading of why the upgrade does not happen. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has written down where the shop’s own code depends on the old language version and the old database. A newer version removes some features and changes how others behave, so without that list the only way to find out is to try.
2. A few parts block everything. A shop runs on one language version at a time. One old module, one abandoned package or one set of calculations held inside the database can hold the whole shop back.
3. The choice offered is all or nothing. When a few parts cannot be upgraded, the usual advice is to rewrite the whole shop or leave it, and a full rewrite is too large to approve.
4. Nobody can tell whether an upgrade worked. With no written record of what the shop does and few or no tests, the check is a few days of clicking. Changes that produce no error are found later, by customers or the accounts team.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Upgrade in place, by the firm’s own team or agency	The code is recent, little changed, and has tests around it	Without tests or a list of dependencies, silent changes are found later by customers	Right where tests exist. Most old shops do not have them
Pay the hosting company to keep the old version a while longer	An upgrade already has a firm date	The PHP project issues no more fixes for the old version; any fixes depend on the hosting company. It buys time and nothing else	Right only as a bridge with an end date
Rebuild the whole shop at once	Most of the shop no longer fits the business anyway	Pays to rewrite code that would have upgraded without trouble; every rule found and checked under one deadline	We would advise against this for a shop where only a few parts block the upgrade
Write down the dependencies, then rebuild only the parts that block, module by module	The shop is old, much changed, and earlier attempts were rolled back	Costs money before anything is upgraded; code in two technologies for a time; the blockers may turn out to be most of the shop	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the code a retailer built or had built on old versions of PHP and MySQL (its pricing, delivery and tax rules, order handling, nightly jobs, and the logic held inside the database): write down first where that code depends on the old language version and the old database, and what each part touches. Then rebuild only the parts that block an upgrade, module by module, on technology that is still supported, starting with the part the business most needs moved. The old shop keeps trading until each module is accepted. The retailer’s own team or agency then upgrades the rest of the shop and checks it against the written record. If the record shows the blockers are most of the shop, a staged replacement of the whole is the honest advice, and we would say so.

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
Parts that depend on the old language version or the old database	Found by trying	Every one listed, with what it touches	The specification and the risk register
Logic held inside the database	Unknown, or known to one person	Written down in plain words	The specification
Parts that block an upgrade	”Too risky”, as one verdict	Named, and the count falls at every stage	Reported at every review, against the staged plan
Each rebuilt part	Not applicable	Proven to do what the old part did before it takes over	The traceability matrix, for every module IOanyT rebuilds
The upgrade of the remainder	Judged by “it seems fine”	Checked by the firm’s own team or agency against the written record	The specification

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the shop, the versions under it and the upgrade that keeps being rolled back. 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 study 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 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.
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. 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. 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 code does and where it depends on the old versions, in writing, as the record the upgrade of the remainder is checked against.
• 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 does not upgrade in place: it does not upgrade a language version or a database. The research paired this issue with such an upgrade; IOanyT does not offer it. The retailer’s own team or agency does the upgrade.
• IOanyT patches nothing: it does not apply security fixes. Nothing here makes a shop on old versions safe; after every step above, the rest of the shop is on the same versions until the retailer’s team upgrades it. Nothing here is a promise that an attack will not happen.
• IOanyT does not host shops or run their servers, and does not secure, scan or monitor them.
• 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 install, upgrade or move a packaged shop platform, choose add-ons, or connect a payment company or a courier.
• IOanyT has published no service for moving data from one database to another.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what card-payment or data protection rules require of a particular firm.
• This study does not say 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
endoflife.date, PHP; php.net, supported versions	PHP end dates
endoflife.date, MySQL	MySQL end dates
A web technology survey: PHP versions; The same survey: PHP 8 versions	Version shares behind our sum (“about half”)
Usage feed, PHP; usage feed, database	Sites on the most widely used website software: the two shares
CISA catalogue	PHP flaws known to be exploited
A tool maker’s developer survey, 2025	Testing among PHP developers
A developer’s post, 2025; a developer’s post, 2025	Developers’ accounts

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 the shop’s code needs from the old versions, because that is what turns an upgrade from a gamble into a list of jobs.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →