New Servers Are Not the Same as Off the Old Ones. Where Your Old Machines Are Now, and Where They Should Be.

The quarterly review reaches the item on hardware. The head of IT has one slide. The new servers were bought two years ago. Most applications have moved. The project is reported as nearly complete.

The managing director asks one question. How many of the old machines have been switched off?

The asset register is passed across the table. Every old machine on it is still marked “in service”. Nobody can say which of them could go tomorrow, or what would stop if one of them went tonight.

What We Found

For this article we went through the public record on old hardware that stays in service: the published support dates of one server operating system and one database, and one survey of IT professionals on how common old systems are and what they cost.

Three findings stand out.

Old systems are the normal state, not the exception. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, the headline was that about six in ten organisations still use old systems. Among the top challenges of those systems, nearly four in ten named high maintenance and support costs.

The software on an old machine keeps a calendar of its own. These dates are not about telecom, and which of these products operators run was not part of our research. For the server operating system Windows Server 2012 and 2012 R2, extended support ended on 10 October 2023 and paid security updates ended on 13 October 2026. For the database SQL Server 2016, extended support ended on 14 July 2026, and paid security updates run to July 2029.

Nobody in the public record counts machines retired. We found no account, from any operator, that reported how many old machines it had switched off, or how many applications still held old machines in place. The one operator account we found, described in the first article of this series, records the hardware as reaching end of life and failing often; it does not say what held any machine in place.

Our reading is that moves off old hardware are measured by what has arrived in the new place, not by what has left the old one. Old machines retired are not counted, because nobody wrote down what each one carries.

What a Count of New Servers Does Not Tell You

A count of new servers and moved applications tells you that work has been done. It does not tell you four things.

It does not tell you what each old machine still carries, and what would stop if it failed tonight.

It does not tell you which applications pin the machine: the few written for its operating system, its database or a device plugged into it.

It does not tell you how many old machines your own team has retired. A machine still switched on, with nothing on it that anyone needs, can still fail.

And it does not tell you, for each rebuilt application, whether every old function has a replacement.

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

Four Ways to Get Off Old Machines, Weighed

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

Option	When it fits	What it risks
Buy extended support or spares, and keep the machines	A replacement is already planned and funded, and the machines only have to last until it is done	The count of retired machines stays at zero for as long as the support is renewed, and each machine is as likely to fail as before
Lift and shift the old machines as they are, onto new servers or a cloud account	The applications on them do not care which machine they run on	The applications written for the old machine stay behind, and so does the machine; the progress report says nearly done
Record what each application needs from its machine, then rebuild only those that pin it	Most of what runs on the old machines could move, and a few applications hold them in place	It costs money before any machine is retired; reading code may not find every need; each old machine stays on, exactly as likely to fail, until the last application tying it down has moved
Replace everything at once	The whole stack is near its end, and the firm can fund a large programme	Nothing can be counted as retired until the end of a long programme and one large move

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.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Old machines with every application on them listed	None; the asset register lists equipment, not what it carries	Every old machine listed with each application and scheduled job on it, and what each needs from the machine	The map of the applications as they stand
What would stop if each old machine failed	Found out on the night it fails	Written down for each machine, with an owner on your side who decides what happens	The map and the risk register
Applications that pin a machine	Not counted	Each one named, with what ties it to its machine; the count falls as each is rebuilt	The specification and the risk register, reviewed after each module
Old machines your own team has retired	Few or none; every machine still “in service”	Each machine whose last pinning application has moved, retired by your team	Your own asset records, reported at every review
Old functions matched to new ones, in each rebuilt application	Not recorded	Each function linked to its replacement	The traceability matrix
Old machines kept on with nothing that needs them	Not known	None: once nothing needs a machine, your team retires it	Your own asset records against the map

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 telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the old machines still in service and how you measure the move off them. 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 and scheduled jobs your firm built or had built around its billing system, and the assessment records what each one stands on and needs from its machine (operating system, database, what is installed and scheduled) and what would stop if a machine failed. 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 only the applications that pin an old machine, rebuilt so that they no longer need one particular machine, and your own team then retires the hardware. 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 above. 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. Retiring a machine is your own team’s work, not ours: we do not replace, repair or retire hardware, and we do not monitor old systems or migrate databases or data. An old machine is exactly as likely to fail until your team retires it, and we promise no level of availability. The benchmark counts what has been listed, rebuilt and retired; it does not make any machine more reliable. Whether a rebuilt application may run in a public cloud is your decision under rules we did not research, and our published offer does not cover an operator that must stay on its own premises. We do not work inside a packaged billing product or on the network. 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 telecom operator.

One of our published cloud cases is ITCan, an e-commerce client outside telecom: a move of its hosting to AWS, after which its capacity went from 300 to 30,000+ concurrent users. It was a move of hosting, not a rebuild of an application tied to old hardware, and it is one client’s result, not a forecast for an operator. For an application that has moved to your own cloud account, VigilCloud, a sister venture, monitors and operates a client’s own cloud account. It does not host. Nothing IOanyT or VigilCloud does watches your old hardware.

At the end you hold the map of every old machine and what it carries, the specification and risk register, the traceability matrix and code for every application we rebuilt, and the filled-in benchmark. Retiring the machines is your team’s.

What changes for the business:

Role	What they gain
CEO	The board can be told how many old machines the firm still depends on and how many it has retired, and not only that the move is nearly complete.
CTO or CIO	Progress off the old hardware is counted in applications that no longer pin a machine and machines the team has retired.
CFO	Spend on old hardware can be read against a count of machines still needed, so the support line has an end in view.
CISO	The list of unsupported machines is measured against a target at every review, and each machine leaves it for a recorded reason.
COO	For every old machine still in service, operations has a written note of what would stop and who decides.

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

The case	What IOanyT does
This article names no organisation as a case of the problem. Its figures are one maker’s published support dates and one vendor’s survey, none of them about telecom. ITCan, named above, is IOanyT’s own client, outside telecom.	We set a benchmark from your own applications, record what each old machine carries, and rebuild only the applications that pin a machine, so that your own team can retire it. Nothing we do watches the old hardware or keeps it running.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We set the benchmark before work starts, so that “nearly complete” is replaced by a count of machines your own team has retired.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →