How to check if your business software is still supported
8 min read
Key takeaways
A self-checkout in Sainsbury's printed its own internals onto the customer screen: an operating system weeks from the end of its life, a database out of support since 2022, and a build date that showed it was installed that way. Here is how to check your own.
We regularly hear people ask "how do I know if my software is out of date?" It is usually said quietly, and it usually comes with a second sentence: "It still works, so I've never really looked."
If that is you, this post is for you. The system that runs your bookings, your stock or your invoicing was built a few years ago. It does its job. Nobody has touched the parts underneath it since the day it went live, and you have a nagging feeling that might matter. You are not sure who you would even ask.
You are in very good company. I recently watched one of the UK's biggest supermarkets show exactly the same problem, on a screen, in front of a queue of shoppers.
What a supermarket till told me about itself
I was at a self-checkout in Sainsbury's when it restarted. Instead of a logo, the customer screen showed a start-up diagnostic console: a plain text window where the till checks itself over and reports what it finds. I took a photo, because it is rare to be handed the inside of a system so politely.
Here is what that screen reports, in plain English.
The operating system is Windows 10 Enterprise 2016 LTSB. That is a long-life edition of Windows made for devices like tills. It gets ten years of security fixes and no feature changes, which is a sensible choice. Its ten years run out on 13 October 2026. After that, fixes are only available through a paid extended programme.
The database is SQL Server 2016 at Service Pack 2. A service pack is a large bundle of fixes, and this one dates from April 2018. The wording on the screen is what you see when nothing has been applied since. Microsoft stopped supporting Service Pack 2 in October 2022, and stopped supporting SQL Server 2016 altogether in July 2026. Paid extended support exists here too, but only for systems that have first moved up to Service Pack 3.
The till was built on 26 September 2024. "Built" means the day its software image was installed. These units have been in my local store three or four years at most, so this is not a relic nobody has got round to replacing. Whether that date was the original install or a later rebuild, it tells us the same thing: in September 2024 a fresh copy of the software went onto this till, and the database inside it was already nearly two years out of support on day one.
The processor is an Intel design from 2014.
Alongside all of that, the screen displayed the machine's serial number, its BIOS version and the names of the services it runs, to anyone in the queue with a phone.
What the same screen got right
Fairness matters here. The same console shows that only approved programs are allowed to run, that the till has to prove its identity before the network lets it on, that its traffic goes through a proxy, and that it has not had a single unexpected restart in 28 days. Somebody even wrote the health check that produced the screen. That is a managed estate, looked after by people who care.
It is also one till in one store. I cannot see the rest of the estate, and there may well be a replacement programme already under way.
Why this should make you feel better, not worse
Sainsbury's reported just over £1 billion in underlying retail operating profit for the year to February 2026, and returned an extra £400 million to shareholders. They have a technology team most businesses could only dream of.
If out-of-support software can end up on a recently built till in a business like that, then the cause is not a shortage of money, and it is not one careless person. The likeliest explanation is the one we see everywhere: nobody's job was to own the dates. The operating system has an end date. The database has a different one. The hardware has a third. Each belongs to a different supplier, and the template the tills are built from was never refreshed.
That is precisely the position most small and medium businesses are in with their bespoke software, and it is nobody's fault. When your system was built, everything underneath it was current. Your developer delivered what was asked for. Nobody was asked to come back four years later and check the foundations.
"But can anyone actually exploit it?"
I do not know whether anything on that till can be exploited. I do not know the network, or whether there is a reachable USB port. And I do not need to know.
"Our payments are handled by someone else, so we're fine"
The till has its own version of this. The card reader on the side is a separate, encrypted device, and the till itself probably never sees your card number. That is true, and it is good design.
But the till does see your Nectar number and everything in your basket. There is a UK court case about exactly this. DSG Retail, the company behind Currys, had malware sitting on 5,390 tills for nine months. The Information Commissioner issued the largest fine available at the time, £500,000, and pointed to patching, network separation and security testing. DSG argued that the card numbers taken did not identify anybody. In February 2026 the Court of Appeal disagreed: what counts is whether the company holding the data can link it to a person, not whether a thief can. The case has gone back to the tribunal, but the principle is clear.
Your version is simpler. A payment provider may take the card, but your system holds the names, addresses, order histories and notes. That is the part you are responsible for.
What decides how bad a bad day gets
M&S and Co-op were not broken into through old software. The attackers phoned the IT help desk, pretended to be members of staff, and had passwords reset. No amount of patching stops a convincing phone call.
What they find once they are inside decides the rest.
You cannot guarantee nobody ever gets in. You can decide how much unfixable software is waiting for them when they do.
The layers under your software, and how to check each one
Every system sits on a stack of other people's products. Each has its own end date.
- The operating system on the server or device, such as a version of Windows Server or Ubuntu.
- The database, such as SQL Server, MySQL or PostgreSQL.
- The language and framework your system is written in, such as PHP, .NET, Node or Laravel.
- Libraries and plugins, the ready-made parts your developer pulled in.
- The web server and hosting platform, including any control panel.
- Hardware and firmware, if you have physical devices such as tills, scanners, readers or tablets.
- Third-party services, such as payment, email or mapping providers, who retire old versions of their connections too.
For each layer, ask four questions. Which version are we on? When does the supplier stop fixing it? Whose job is it to watch that date? What is the plan when it arrives?
Whoever hosts or maintains your system should be able to answer the first question. Every major supplier publishes a lifecycle page that answers the second, and the community site endoflife.date gathers most of them in one place.
Put the answers in a single sheet: component, version, end-of-support date, owner, plan. Look at it twice a year. Anything already past its date goes to the top.
Two lessons from the till that are easy to miss
Check what new things are built from. The till's most telling detail was its build date. A brand-new install inherited old foundations because the master copy was old. Your equivalent might be the template your developer starts new sites from, the image your host builds new servers from, or the standard setup for a new laptop.
Check what your system tells strangers. The diagnostic console is the physical version of a very common software habit: error pages that show the inner workings, debug mode left switched on, version numbers in the footer of every page. Ask whoever looks after your system one question: "What does a visitor see when something goes wrong?"
If you cannot answer the first question
If you have read that list and realised you do not know the version of half the layers, that is the normal starting point, especially if the person who built the system has moved on. Finding out is a small, contained job. Someone reads what is there and writes down what they find.
"If I ask, I'll be told it all needs rebuilding"
This is the fear that keeps most people from looking, and it is usually wrong.
Take the till. The fix for the database is a service pack and a patch. The operating system has newer long-life editions that are still supported for years. None of that is a rebuild. In our experience most findings are upgrades in place, done in an order that suits the business.
Occasionally something really has reached the end of the road. It is far better to learn that with eighteen months' notice than with three weeks'.
Start with the list.
Matt Houldsworth
Matt has spent thirty years building software that has to work, from systems handling a hundred million database transactions an hour to ecommerce platforms turning over millions of pounds a month. He founded Software Delivered to price development honestly and to rescue the projects other people walked away from.