Spares Buy Time, Not a Way Off. Four Ways to Deal With Servers Past Their Support, Weighed.
New servers are bought, most applications move across, and one or two that will not run anywhere else keep the old machines switched on. Here is why spares and extended support buy time but not a way off, the four ways forward, weighed, and the one we would recommend.
The new servers arrived in March. By the end of April most of what ran on the old machines had been moved across, and the project was reported as nearly done.
It is now October. Two of the old machines are still switched on, in the same room as the new ones. They run two programs: the one that works out dealer commissions, and the one that prints invoices for business accounts. Neither will start on the new servers.
The operator pays for power, space and used spare parts for both sets of hardware, and the support renewal for the old pair is on the finance head’s desk again.
The paradox: The operator bought new hardware to get off the old, and now runs both.
What We Found
For this article we went through the public record on what keeps old machines switched on: 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.
Three findings stand out.
Paid support is a bridge, and the bridge has an end. 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. Paid security updates carried it for three more years, and they 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. Paying for more support moves the date. It does not remove it.
Old systems stay because they still run, and staying 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, 50% gave “the current system still works” as a reason for not modernising, 44% named budget limitations and 38% named fear of disrupting operations. Among the top challenges of old systems, 39% named high maintenance/support costs.
Nobody in the public record says which application held an old machine in place. The one operator account we found, described in the first article of this series, records 77 physical servers with hardware reaching end of life; it does not say which of its applications could not be moved, and we do not guess.
Our reading is that the machines that stay on are rarely held there by the hardware. They are held by one or two applications written for that machine: its operating system, its database version, its file paths, sometimes a device plugged into it. Spares and extended support keep the machine alive. They do nothing about the application that will not leave.
What our review does not show: We found no figure for what extended support, a spare part or a second set of hardware costs an operator, and no named operator that kept old machines on for one application. The support dates are for one operating system and one database, and are cross-sector; no end-of-support date for any server hardware was researched. The survey was run by a vendor, in the US, across all sectors. The opening scene is imagined.
Why Spares Cannot Retire a Machine
Every operator with old hardware has a team that can retire a machine. Unplugging it, wiping it and taking it off the asset register are ordinary work. What that team cannot do is retire a machine while nobody knows which applications pin it.
So the machine is kept. A used spare is found when a part fails. Extended support, or paid security updates for the software on it, are bought for another year. Each of these is a sensible decision for that year. Together they buy time, and the time is spent waiting, because nothing in them produces a way off.
Three things are lost while the machine waits. The first is the cost of running two rooms of hardware for the sake of a few programs. The second is the date: paid updates end on a day someone else published, and the machine fails on a day nobody chose. The third is attention: by the time the old machine is the last item left, the project that bought the new ones has closed and its people have gone back to other work.
The gap we see: most operators keeping old machines alive do not need another year of support as much as they need the few applications that pin those machines named, and then rebuilt so that they no longer need one particular machine. Once nothing on a machine needs it, the operator’s own team can retire it in the ordinary way.
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. Paid support ends on its own published date, 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 one or two applications written for the old machine will not start, and the old operating system and database, with their 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 |
Our recommendation: the third. Record, for every old machine, what each of your own applications and scheduled jobs needs from it and what would stop if it failed. Most of them your own team can move as they are. Rebuild only the few that cannot leave, one module at a time, while the old application keeps running, and then your own team retires the hardware. Buy spares or support for as long as that takes, as a bridge with a planned end. We do not lift and shift machines, and we do not monitor old systems, migrate databases or data, replace, repair or retire hardware, or host. Until your own team retires a machine, it is exactly as likely to fail as before.
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 |
|---|---|---|---|
| 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 |
| What each pinning application needs from its machine | Known only by whoever last restarted it | Operating system, database, files, devices and scheduled jobs written down for each | The specification |
| Old machines kept on only for a pinning application | Not separated from the rest | Each listed, with the application that keeps it on and a planned end for its support | The map of the applications as they stand and the staged plan |
| Old functions matched to new ones, in each rebuilt application | 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
- We listen: a free Reliability Review. A first conversation about the old machines that are still switched on, and the programs that keep them there. 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.
- 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.
- 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.
- 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 on React, Node.js, Python or Java so that they no longer need one particular machine; where they then run is your decision. 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.
- 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. A rebuild costs more than another year of spares, and it is not quick. Until the last pinning application has moved and your own team retires the machine, the old machine stays on and is exactly as likely to fail as before; we promise no level of availability. The records the old program holds still have to be moved, by your own people or a firm you choose; we do not migrate databases or data. We do not monitor old systems, replace, repair or retire hardware, or host. 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 or customer product, and we do not work 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.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The age of a machine stops deciding how long a part of the business can run. |
| CTO or CIO | The applications that only ran on the old machines are rebuilt on current technology, and the team can retire the hardware in the ordinary way. |
| CFO | Spares and support are bought as a bridge with a planned end, and spend moves to applications the firm owns. |
| CISO | Each machine that is emptied is one fewer that cannot be supported, and the list is shorter at every review. |
| COO | The work the service floor depends on moves one module at a time, each accepted by the firm’s own people while the old one keeps running. |
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. Its figures are one maker’s published support dates and one vendor’s survey, none of them about telecom. | For applications an operator built, we record what each needs from its machine and rebuild only those that pin it, one module at a time, so that the operator’s own team can retire the hardware. We do not supply spares or support, and the machine is as likely to fail until it is retired. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We rebuild only the few applications that keep an old machine switched on, so that the spares you buy are a bridge with an end.