Operators Know Which Servers Are Old. What Nobody Has Written Down Is What Runs on Them.

It is Friday, a little after eleven at night. One of the oldest servers in the billing room has stopped.

The engineer on call knows the machine. Its maker ended support years ago, and the part that has failed is no longer made. A used one can be found by Tuesday.

By midnight the calls have started. Dealers cannot activate new connections. The overnight invoice file has not been produced. The payment reminders did not go out. Each of these turns out to have lived on that one machine, and nobody had ever written that down.

What We Found

For this article we went through the public record on billing and customer applications that run on old hardware: one trade-press account of one operator’s billing and customer stack, the published support dates of one server operating system and one database, and one survey of IT professionals on old systems.

Four findings stand out.

In the one operator account we found, the hardware was failing and nothing stood behind it. In an older case, from 2019, a trade-press report described a mobile operator in Sri Lanka, “a three-million customer business”, running “an expensive ten-year-old BSS” (its billing and customer stack) made up of “more than 60 different applications” on 77 physical servers. The report’s words are: “The hardware was reaching end of life, suffering frequent failures and there was no disaster recovery contingency.” The record does not say what stopped when a server failed, or what a failure cost, and we do not guess. What the operator did afterwards is its own story, and we do not use it.

The software on old machines has end dates of its own, and some have passed. 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 the paid security updates that followed ended on 13 October 2026. For the database SQL Server 2016, extended support ended on 14 July 2026; paid security updates run to July 2029. Spares keep a machine going; they do not move those dates.

Old systems are common, and keeping them costs. In one survey of 504 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 “62% of organizations still use legacy systems”. Among the top challenges of those systems, 39% named high maintenance/support costs.

Nobody in the public record says what stopped when an old server failed. We found no account, from any operator, of which application stopped with which machine, or what a failure cost.

Our reading is that operators keep machines past their support not because their engineers are careless, but because over ten years applications and overnight jobs were put on whichever machine had room, a few of them written for that one machine, and nobody kept a list of what each one carries. A replacement cannot be priced without that list, so it waits, and the machine decides the date.

What Waits While Nobody Knows What Runs on Each Machine

The first cost is the replacement that cannot be priced. A new server is easy to buy; the knowledge of what the old one carries is not, so the proposal is deferred again.

The second cost is the risk list that cannot be ranked. An asset register records the model, the serial number and the room, not which machine holds the invoice run.

The third is the first hours of a failure, spent on discovery: the team learns what was on the machine by watching what breaks.

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

Four Ways to Deal With Servers Past Their Support, 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	Time is bought, not a way off. The software on the machine keeps its own end dates, and the 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’s operating system, database or devices will not start, and the old software and its end dates travel with the rest
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	Years of work and one large move, with the old machines kept on until it ends

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, what each needs from the machine, and what would stop if it failed	The map of the applications as they stand
Applications that pin a machine	Not counted; “it only runs on that box”	Each one named, with what ties it to its machine; the count falls as each is rebuilt	The specification and the risk register
Old machines your own team has retired	Few or none; the same machines on the list each year	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, where an application is rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix

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 and what you think runs on 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 cannot leave the old machines, 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. 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. We do not monitor old systems, and we do not migrate databases or data; your own people move the records, or a firm you choose. We do not replace, repair or retire hardware, supply spares or extended support, or host. An old machine is exactly as likely to fail after the assessment as before, and stays so until your own team retires it; we promise no level of availability. Reading code finds most of what an application needs from its machine and may not find all of it. We do not work inside a packaged billing or customer product, and we do not work on the network. Whether you may put billing or customer systems 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. 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.

What changes for the business:

Role	What they gain
CEO	A hardware failure stops being the moment the firm learns what it depends on. The board has already seen the list.
CTO or CIO	For every old machine, a list of the applications and jobs on it, what each needs, and which could run elsewhere as they are.
CFO	Money for replacement goes first to the machines the business could least afford to lose.
CISO	The machines that can no longer be supported are named, with what runs on each, so the exposure can be ranked and reported.
COO	Operations knows which daily work rests on the oldest machines, and has decided beforehand what happens if one stops.

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

The case	What IOanyT does
A mobile operator in Sri Lanka, in 2019 “a three-million customer business”, ran “more than 60 different applications” on 77 physical servers; “The hardware was reaching end of life, suffering frequent failures and there was no disaster recovery contingency”. An older case.	Our part is far narrower: we do not replace, repair or monitor hardware, and nothing we do would have kept a server running. For applications an operator built, we record what each stands on and needs from its machine, and rebuild the ones that cannot leave, so that the operator’s own team can retire the hardware.

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 by writing down what each old machine carries, because that is the list every deferred replacement has been missing.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →