An Upgrade Nobody Can Check Is a Gamble. A Shrinking List of Blocking Parts Is a Plan.

The upgrade has been done on a copy of the shop. Your developer calls you over to look.

The home page loads. A product page loads. A test order goes through, and a confirmation email arrives. The developer says it seems fine.

You ask what “seems” means. Has every discount been tried? Every delivery zone? The export to the warehouse? The developer has clicked through what they could think of in two days. There is no list of what the shop does. “Seems fine” is the most anyone can say.

What We Found

We looked at the next end dates for PHP, the language many online shops are written in, and at what developers who work on old code say about checking a change. Every figure is about websites or developers in general, not shops alone, and we name no retailer.

The question comes round again. PHP version 8.1 lost its security fixes on 31 December 2025. Version 8.2 gets security fixes only until 31 December 2026. A shop that upgrades by guesswork this year will be guessing again soon, and every upgrade after that.

Many teams have nothing to check a change against. In one survey of well over a thousand developers whose main language is PHP, about a third said they still write no tests at all. A test is a small program that puts a known input in and checks the answer. Without one, the check after an upgrade is whatever people remember to try.

Developers say plainly what that feels like. One developer, writing about old code in several languages, PHP among them, said nothing is more frightening than changing a critical old system that has no tests. It is one person’s account, and we give it as that.

What a Written Record Opens Up

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

• “Done” gets a meaning. With a written record of what the shop does, an upgrade can be checked against it, rule by rule, before a customer finds the difference.
• The work can go to anyone. Your own team or any agency can do the upgrade of what remains, and be judged on the same record.
• The next end date stops being a crisis. The record is made once. At the next version, the same record is the starting point, and only what changed since needs to be read again.

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

Three Ways to Check an Upgrade, Weighed

Option	When it fits	What it risks
Upgrade, click through the shop, and fix what customers report	The shop is small and simple, and a few days of errors would be tolerable	Silent changes, such as a total rounded differently or a list sorted another way, are found by customers or the accounts team, weeks later
Your own team or agency writes tests around the code that stays, then upgrades	The team has the time and the skill, and the code is reasonably clear	Tests record what the code does today, including its mistakes, and cover only what someone thought to record. They take time before any upgrade begins
Write down the dependencies and what the shop does first, rebuild the blocking parts module by module, then have your own team or agency upgrade the rest against the written record	The shop is old, much changed, and earlier upgrades were rolled back	It takes stages and costs money before the upgrade starts. Code in two technologies for a time. A written record can miss behaviour that shows only when the code runs

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
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
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 we rebuild
The upgrade of the remainder	Judged by “it seems fine”	Checked by your own team or agency against the written record, rule by rule	The specification
The next end date	A surprise each time	Known in advance, with the written record ready as the starting point	The risk list beside 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.

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

Part of the shop	What it depends on	Status
Delivery-charge module	Language features that later versions removed	Stage 1: rebuilt and accepted; no longer blocks the upgrade
Nightly stock update	Calculations held inside the old database	Stage 2: still on the old version until its module is accepted
Product pages and search	Nothing that later versions removed	Upgrades as it is; checked by the client’s own team against the specification

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 upgrade that was rolled back, and the next end date. 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 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.
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 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 upgrade is done, the shop is on the same versions as before, and your own team or agency must go on running it. We do not upgrade in place, we patch nothing and we do not host the shop, and we cannot promise that an attack will not happen in the meantime. PHP is a language we read, not one we build in. A written record can miss behaviour that shows only when the code runs, so the upgrade still needs care from whoever does it. Some parts are too tangled to lift out, and the list may be longer than anyone hoped. It is slower than upgrading and hoping, and it is the first time “done” has a meaning. 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 list of blocking parts that has reached zero. The upgrade of the rest is your team’s or your agency’s, checked against a record you own.

What changes for the business:

Role	What they gain
CEO	The upgrade can go to the firm’s own team or any agency, and be judged on evidence.
CTO or CIO	A written record that says, after each step, what the shop should still do, and a check against it.
CFO	Faults are found in a check before going live, where they are cheap, and not by customers afterwards.
CISO	The next version can be checked against a written record, so taking it is easier to approve.
COO	A change made at night is checked before the morning’s orders, and not discovered by the warehouse.

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

The case	What IOanyT does
PHP 8.2 gets security fixes only until 31 December 2026, a year after 8.1 lost them.	Our part is narrower than this. We do not upgrade the language. We write down what the shop does and rebuild the parts that block, so the firm’s own team or agency can upgrade the rest and check it.
In one survey, about a third of developers said they still write no tests at all.	For each module we rebuild, a traceability matrix links every old function to its replacement. For the code that stays, the written specification is what your own team checks against, and tests around it are your own team’s choice.

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 whether the upgrade worked, the answer is a record, not a feeling.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →