What Each Old Server Carries

1. At a Glance

Issue study · From the public record. Everything about it comes from the public record.

Organisation type	Telecom operators whose billing and customer applications, and the scheduled jobs between them, run on servers past or near the end of their makers’ support
Size band	The operator in the record: a mobile operator with a few million customers. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, or another mid-size operator
Region	The case: South Asia (an older case, from the late 2010s). The support dates and the survey: cross-sector, not about any one country’s operators
The decision at stake	Whether to keep buying spares and support for old machines, move them as they are, replace everything at once, or record what each application needs from its machine and rebuild only the few that pin it
The public outcome	In the late 2010s a trade-press report described one operator’s costly billing and customer stack, about a decade old, of dozens of applications on dozens of physical servers, and said its hardware was nearing the end of its life, failing often, with no disaster recovery in place
Why it matters to a mid-size operator	The software on old machines has published end dates, and some have passed: paid security updates for one widely used server operating system ended on 13 October 2026. An operator that cannot say what runs on each old machine cannot price getting off it

2. The Business Problem, in the Buyer’s Words

“We bought new servers two years ago. Most of what ran on the old ones moved in the first month, and the project was reported as nearly done. The old machines are still on. Two programs will not start anywhere else, and nobody can tell me whether there are others, because nobody has a list of what runs on each machine. Every year I approve another round of support and a few used spare parts, and every year the same machines are on the risk list. One of them stopped on a Friday night last spring, and we found out what was on it from what stopped. I do not want to buy another year of support without a way off at the end of it.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The operator is caught between spares that keep old machines alive and a move that cannot finish while a few applications still need them.

3. What We Found

Method. 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 why old systems stay and what they cost.

One public case. These are the record’s own words.

Case

What the public record says

A mobile operator in South Asia with a few million customers, an older case from the late 2010s

The report describes a costly billing and customer stack, about a decade old, made up of dozens of applications running on dozens of physical servers. It says the hardware was nearing the end of its life, failing often, with no disaster recovery in place. The support contract was due for renewal at a much higher price, and the code was not kept in one central place. The report does not say what stopped when a server failed, or what a failure cost. What the operator did afterwards is its own story and is not used here

End dates above the hardware. These are not telecom facts, and which of these products operators run was not researched. 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, and paid security updates run to July 2029. No end-of-support date for any server hardware was researched.

Why old systems stay. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a vendor 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. Among reasons for not modernising, half said that their current system still works, more than four in ten named budget limits and nearly four in ten named fear of disrupting operations.

Our reading of why old machines cannot simply be retired. These four are our reasoning from the record above. None is a finding of any source, and none is offered as the explanation of the case above.

1. Nobody knows what each machine carries. Over the years applications and overnight jobs were put on whichever machine had room. The asset register lists equipment, not what the equipment does for the business.
2. A few applications are tied to one machine. They were written for its operating system, its database version, its file paths, or a device plugged into it, and they will not start anywhere else.
3. Those few are left until last. A move to new hardware takes the easy applications first and closes with the hard ones still in place, so old and new hardware are both kept.
4. Spares and support buy time, not a way off. Each renewal is sensible for its year. None of them produces a list of what pins the machine, so the time is spent waiting.

Illustration, not a real case. A regional broadband provider buys new servers. Within a month most of its applications have moved. Two have not: the program that works out dealer commissions and the program that prints invoices for business accounts. Each expects an operating system the new servers do not run. Two old machines are kept on for them, with a cupboard of used parts. Nobody has a date for switching them off.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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; paid support ends on its own published date; each machine is as likely to fail as before	Right as a bridge with a planned end; on its own, it is bought again next year
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 will not start, and the old operating system and database travel with the rest	Right for most applications, done by the operator’s own team; it does not deal with the few that pin a machine. IOanyT does not do it
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	Costs money before any machine is retired; reading code may not find every need; each machine stays on, exactly as likely to fail, until the last application tying it down has moved	Our recommendation
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	We would advise against this as an answer to old hardware alone, before anyone knows which applications pin which machine

5. Our Recommendation, and the Decision It Asks of the Board

Record, for every old machine, what each of the operator’s own applications and scheduled jobs on it stands on and needs from the machine (its operating system, its database, what is installed and scheduled) and what would stop if the machine failed. Most of those applications the operator’s own team can then move as they are. Rebuild only the few that cannot leave, one module at a time, while the old application keeps running, so that they no longer need one particular machine. Each module is checked function by function against the old one. The operator’s own team then retires each machine as its last pinning application moves. Spares and support are bought only as a bridge with a planned end. IOanyT does not monitor old systems, migrate databases or data, replace, repair or retire hardware, or host, and until the operator’s own team retires a machine it is exactly as likely to fail as before.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

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	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	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 the firm’s 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 the firm’s team	The firm’s 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
Spares and support bought for old machines	Renewed each year with no end in view	Each renewal tied to a machine with a planned end	The staged plan, reviewed at each stage

7. How IOanyT Would Work

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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: for every old machine, what each of the operator’s own applications and scheduled jobs on it does, stands on and needs from the machine, and what would stop if it failed, confirmed by the operator’s own people.
• The risk register: the applications that pin a machine, and the machines the business could least afford to lose, listed before any price is set.
• The traceability matrix: for every application IOanyT rebuilds, every old function linked to its replacement.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not replace, repair or retire hardware, and supplies no spare parts or extended support. Retiring a machine is the operator’s own team’s work.
• IOanyT does not monitor old systems or old hardware. Until the operator’s own team retires a machine, it is exactly as likely to fail as before, and no level of availability is promised.
• IOanyT does not migrate databases or data. The operator’s own people, or a firm they choose, move the records an old program holds.
• IOanyT does not host, does not lift and shift machines, and does not keep an old application running while a module is rebuilt.
• Reading code finds most of what an application needs from its machine and may not find all of it.
• IOanyT does not work inside a packaged billing or customer product, and does not work on the network or the systems that run it.
• Whether an operator may place billing or customer systems in a public cloud is its own decision, under rules this study did not research. IOanyT’s published offer does not cover an operator that must stay on its own premises.
• IOanyT gives no legal or regulatory advice.
• This study does not say that IOanyT has done this work for a telecom operator. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A trade press account, late 2010s	The operator: the stack, the applications, the servers, the state of the hardware, the support renewal and the code repository
endoflife.date/windows-server	Windows Server 2012 and 2012 R2 support dates
Microsoft lifecycle, SQL Server 2016	SQL Server 2016 support dates
A vendor’s survey of about 500 US IT professionals, 2025	How common old systems are, their costs, and why they stay

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, so that the next support renewal is a bridge with an end.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →