Old Servers Outlive Their End Dates for One Reason. Nobody Has Listed What Stands on Them.

The largest customer has sent its yearly supplier questionnaire. Question fourteen asks whether any server in the business runs an operating system its maker no longer supports.

The head of IT knows the answer. There is one in the cupboard beside the plant office, and it has been there for twelve years. The managing director asks the obvious question. Why not replace it?

The head of IT starts to answer and stops. Something on that machine prints the dispatch labels. Something else feeds the weighbridge record. There may be more. The person who set it up left six years ago.

What We Found

For this article we went through the public record on the software beneath a manufacturer’s own applications: published end dates for server operating systems, databases, one old programming tool and one older ERP product, and one survey of cyber incidents at manufacturers.

The end dates are public, and several have passed. For Windows Server 2012 and 2012 R2, paid security updates ended on 13 October 2026. For the database SQL Server 2012, extended support ended on 12 July 2022, and even the paid updates ended on 8 July 2025. For SQL Server 2016, extended support ended on 14 July 2026.

The tools many in-house applications were written in are older still. The VB6 development tool has been unsupported since 8 April 2008, and its maker “strongly recommends that you replace your applications with modern technology”. VB6 programs have not stopped working: their runtime is still supported, in a limited way, on current Windows. What has gone is any supported way to build or change them.

The ERP has its own end date. For one widely used older packaged ERP product, mainstream maintenance ended on 31 December 2025 for some versions, with no extension, and ends on 31 December 2027 for others, with a paid extension to 31 December 2030. The dates are the maker’s; our source is a firm that sells support for the product.

Incidents at manufacturers are common, whatever their cause. In one survey of UK manufacturers by an industry body, almost a third said they had a cyber incident over the past year. Of those affected, about three in ten reported reduced production capacity or operational delays, and a similar, separate share reported late deliveries to customers. The survey does not say how many of these incidents came through old or unsupported systems, and we do not suggest a number.

Our reading is that an old server or database is rarely kept because anyone wants it. What holds it in place is usually the firm’s own applications that stand on it: a label program, a weighbridge record, a costing tool, a set of scheduled jobs. Each was written for the versions of its day, and nobody has listed which would stop on anything newer.

What Waits While Nobody Lists What Stands on It

An old server is usually discussed as a hardware question. Our reading is that it holds four other decisions in place.

The machine’s retirement. It cannot be planned while nobody can say what would stop with it.

The cost of staying. Paid cover can be renewed every year, but not compared with anything, because the cost of ending the need for it was never worked out.

The ERP move. A specialist can price the product; the firm’s own programs around it are priced as a guess.

The risk list. Without a list of what runs on an out-of-support machine, its exposure cannot be ranked, and the exception is renewed.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Answer an End Date, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Accept the risk for another year	The machine is isolated, little depends on it, and a retirement date is already set	The exception is renewed without a plan, the machine stays exactly as exposed, and the same question returns next year
Buy paid extended cover and wait	Cover exists for that version, and an upgrade already has a firm date	Cover has its own end date, some versions have none, and nothing about what holds the machine changes
Try the upgrade, and see what stops	The applications on the machine are few, known and recently tested on the newer version	The trial stops at the first application that fails, and whatever else would have failed stays unknown
Write down what stands on each old machine first, then deal with what pins it	Nobody holds a full list, the person who set it up has gone, and earlier attempts stopped	It costs money before anything changes, the machine is exactly as exposed meanwhile, and the list may be longer than anyone hoped

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
Your own applications on each old server or database	A label: do not switch off	Every application listed, with what it does for the business	The map of the system
What each application stands on	Not recorded	The operating system and database each needs, with their published support dates	The specification
Applications that pin an old machine	Found one at a time, in failed upgrades	Named for each machine, before anyone tries again	The risk register
The cost of staying	Paid cover, renewed each year	Set beside the cost of ending the need to stay	The cost comparison
Old machines past their end date	Not counted	Counted, and falling at each stage	Reported at every review

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, 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 manufacturer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your applications, the old servers and databases beneath them, and what stopped the last attempt to retire one. 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 applications you built or had built beside your ERP, and what each of them stands on. 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. 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 applications that pin an old machine, rebuilt on current technology so that your own team can retire the machine. We never do a single cutover. Each module has a traceability matrix. 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.

This approach has a price. The assessment costs money and by itself upgrades nothing: the machine is on the same version afterwards, and just as exposed. Reading code may not find every need an application has; some show only when it runs, so your own team’s upgrade still needs its own testing. We do not upgrade, patch, replace or retire an operating system, a database or a server, we do not sell or arrange extended cover, and we do not host. We do not install, configure, upgrade or convert a packaged ERP product, or change the customisations inside one; that is your ERP specialist’s work. We do not work on plant control systems or machines, and we do not read RPG or COBOL. Nothing we do makes an old machine safe while it is still in use, and we promise no protection from attack. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	An end date that kept arriving with no plan becomes a list with an order of work.
CTO or CIO	For every old server and database, a list of the applications that stand on it and what each needs. “We cannot switch it off” gets a reason.
CFO	The yearly cost of staying can be set beside the cost of ending the need to stay, application by application.
CISO	The out-of-support machines are named, with what runs on each, so the exposure can be ranked and reported.
COO	Operations knows which daily jobs sit on the oldest machines: the dispatch labels, the weighbridge slips, the planning sheet.

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

The case	What IOanyT does
Paid security updates for Windows Server 2012 and 2012 R2 ended on 13 October 2026, and for SQL Server 2012 on 8 July 2025.	Our part is narrower than this. We do not upgrade or patch servers or databases, or sell extended cover. We list which of your own applications stand on such a machine and what each needs, so your own team can plan its retirement.
In one UK survey, almost a third of manufacturers had a cyber incident in a year; the survey does not link the incidents to old systems.	We promise no protection from attack, and we do not secure or monitor anything. A named list of what runs on each out-of-support machine is for your own security team to rank.

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 the list of what stands on each old machine, because every earlier attempt to retire it lacked one.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →