One Old Application Can Keep a Whole Server Past Its End Date. It Can Be Rebuilt by Itself.

The IT team gave up a weekend to move everything off the old server. By Saturday evening the shared folders, the user accounts and nine of the ten applications were running on the new one.

The tenth would not start. It is the program that prints dispatch labels and records each truck’s weight, written fifteen years ago in a language the team no longer uses. On the new machine it shows one error and closes.

On Sunday night the team put everything back. On Monday the old server was still in its cupboard, with its warning label, and the plant shipped as usual.

What We Found

For this article we went through the public record on what holds a business on old software: the published support dates for one old programming tool, a server operating system and a database, and one survey on why firms do not replace old systems.

The tool is long unsupported, even where the program still runs. VB6 is one of the tools such applications were written in. Its development tool has been unsupported since 8 April 2008, and its maker “strongly recommends that you replace your applications with modern technology”. Their runtime is still supported, in a limited way, on current Windows, so the programs keep running. What is gone is any supported way to build or change them.

The platforms beneath them keep moving. For Windows Server 2012 and 2012 R2, paid security updates ended on 13 October 2026. For the database SQL Server 2012, even the paid updates ended on 8 July 2025. A machine kept on such a version for one program gets no more fixes from its maker.

The pull to leave things alone is strong. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, half gave the fact that the current system still works as a reason for delaying the replacement of old systems, and more than four in ten named budget limitations. That survey covers every sector, not manufacturing alone.

Our reading is that an old server rarely stays because of everything on it. It stays because of the one or two applications that cannot leave: written for the versions of their day, with a tool nobody supports, doing a job the plant cannot ship without. The proposal to deal with them then grows to cover every old system, is too large to approve, and the only other choice on the table is to change nothing.

What Opens Up When the Application That Pins It Is Named

The usual question is whether to replace the old systems or keep them. Our reading is that the larger opening is in a smaller question: which applications hold this machine in place?

• The machine can be retired. Once the applications that cannot move are named and dealt with, the move the team already knows how to do can be done again, and this time nothing has to go back.
• The cost of staying gets an end. Money goes to the few applications in the way, not to replacing everything, and the renewal of extended cover has a year in which it can stop.
• The ERP move can be priced. The same list that names what pins a machine also names the programs the firm built beside its ERP, so a specialist can be asked to price a written scope.

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

Four Ways to Free an Old Machine, Weighed

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

Option	When it fits	What it risks
Buy paid extended cover and wait	Cover exists for that version, and a retirement date is already firm	Cover has its own end date, some versions have none, and nothing about what pins the machine changes
Upgrade in place, by your own team	The applications on the machine are known to run on the newer version	The first application that fails stops the upgrade, and whatever else would have failed stays unknown
Rebuild the application that pins the machine	The one or two applications that cannot move are already known by name	Without a list of what stands on the machine, the wrong one can be rebuilt, or a second one is found after the first
Write down what stands on the machine first, then rebuild only what pins it, one module at a time	Nobody holds a full list, the tool is unsupported, and earlier attempts stopped	It costs money before anything changes, old and new run side by side for a time, and the machine is exactly as exposed until your team retires it

Where You Are Now, and Where You Should Be

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
Applications that pin each old machine	Found one at a time, when a move fails	Named for each machine, with what each needs from it	The risk register
The size of the job	Replace everything, or nothing	Only the applications that pin the machine, listed by name	The staged plan
What the pinning application does	In its code, and in one person’s memory	Written down in plain words, confirmed by your own people	The specification
The old application while its replacement is built	Kept, untouched, with no end date	Still running until each new module is accepted	Reported at every review
Old functions matched to new ones	Not recorded	Each function of the old module linked to its replacement	The traceability matrix
The machine’s retirement	Called off at the first failure	Done by your own team once nothing on it pins it	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 machine that keeps being kept, and the program that stopped the last move. 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 on the old machine that you built or had built, and above all the ones that will not run on anything newer. 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 application that pins the old machine, rebuilt on current technology one module at a time. 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 limits. Until the last module is accepted and your own team has retired the machine, the old server is still running and exactly as exposed as before; we do not secure it, patch it or monitor it in the meantime. The new application has to reach whatever the old one read from and wrote to; where that is a packaged ERP product, that side is your ERP specialist’s work. We do not upgrade an operating system or a database, move your other applications, retire the machine or host anything; your own team does the move and the retirement. We do not install, configure, upgrade or change a packaged ERP product, we do not work on plant control systems or machines, and we do not read RPG or COBOL. 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	One old application stops deciding how long the firm stays on software nobody fixes.
CTO or CIO	The applications that would only run on the old version are rebuilt on current technology, and the team can retire the machine in the ordinary way.
CFO	Money goes to the few applications that hold the old machine there, released one accepted module at a time, and the renewal of extended cover has an end in sight.
CISO	There is a route off each unsupported machine that does not wait for one large project, and the exception on the risk list gets a closing date.
COO	The jobs the plant 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
The VB6 development tool has been unsupported since 8 April 2008, though its runtime is still supported in a limited way.	VB6 is among the technologies we read. Where an application written in it pins an old machine, we can rebuild that application one module at a time on current technology. Your own team retires the machine.
For SQL Server 2012, even the paid updates ended on 8 July 2025.	Our part is narrower than this. We do not upgrade databases or move data between them as a service. We write down what each of your applications needs from the database, and rebuild the ones that pin it.

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 application in the way, not the size of the machine it holds.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →