The End Dates Are Published. The List of What Runs on Each Old Server Is Not.

The questionnaire comes from your largest shipper. Question fourteen: list every system running on an operating system its maker no longer supports, and say what each one does.

The head of technology can answer the first half from memory. There are four such servers. One is in the rack at head office, one is under a desk in accounts, and two are at the northern depot.

The second half is harder. The old rate calculator runs on one of them. So do some overnight jobs, and something that prints consignment notes. Nobody has a list, and nobody is willing to switch a server off to find out.

What We Found

For this article we went through the public record on the software beneath a firm’s own applications: published end dates for server operating systems and databases, reporting on a national reservation system, an audit of air traffic control systems, and one cross-sector survey. It holds no case of a mid-size logistics, travel or hotel firm on this issue. Every named organisation below is far larger than the firms we write for.

The end dates are public, and several are close. For the server operating systems Windows Server 2012 and 2012 R2, support ended on 10 October 2023, and paid security updates ended on 13 October 2026. For Windows Server 2016, support ends on 12 January 2027. For the database SQL Server 2016, extended support ended on 14 July 2026, with paid updates available to 17 July 2029. These dates are not about this sector.

Systems stay in service long after they are called legacy, even at the largest scale. This is a very large national railway, a government body, and we pass no judgement on it. Its passenger reservation system has been in service for about fifteen years, and a press account in 2025 says it needs to move from older technology to current cloud-based systems. We use it for one point only: a system can stay in service for many years after it is described as legacy.

Old systems stay where the support has gone. This is an audit of systems that control air traffic. They are not our kind of work, and we pass no judgement on the agency. In September 2024 a US government auditor reported that, at the Federal Aviation Administration, “of its 138 systems, 51 (37 percent) were unsustainable and 54 (39 percent) were potentially unsustainable”, “citing outdated functionality, a lack of spare parts, and more”. We quote the auditor and add nothing. We take one narrow point: old systems stay in service long after the parts and the support behind them have gone.

Firms know the risk and stay anyway. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, more than two in five named security vulnerabilities and nearly a third named a lack of vendor support or updates among the top issues with their old systems. Half said the biggest reason they had not upgraded is that the current system still works.

Our reading: an old server is rarely kept because anyone wants it. What holds it in place is the firm’s own applications and jobs on it, each written for the operating system and database of its day. Nobody has listed which would stop on anything newer, so leaving cannot be priced.

What Waits While Nobody Lists What Runs There

An old server is usually discussed as a hardware question. Our reading is that it holds three other decisions in place.

The exit. Nobody can say what would stop with the server, so leaving cannot be planned.

The price. Paid support is renewed every year and never compared with the cost of ending the need for it.

The answer to the customer. A shipper’s or an insurer’s question about unsupported systems is answered with “we think”, and an exception marked “pending replacement” is renewed in the same words.

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

Four Ways to Answer an End Date, Weighed

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

Option	When it fits	What it risks
Pay for extended support and wait	Paid updates exist for that version, and a way off the server already has a date	Paid support has its own end date, and nothing that holds the server in place changes
Move the server as it is to new hosting	The hardware is the worry, and the operating system and database will be upgraded soon after by the firm’s own team	The operating system and database are exactly as unsupported in the new place as in the old
Replace the applications with a packaged product	The firm’s way of working fits such a product, and it can carry a long change	The firm’s own rules, rates and links to depots and billing must be refitted. This is the firm’s decision, and not our kind of work
List what each of your own applications stands on and what ties it there, then rebuild the programs that pin the server, module by module	Nobody holds a full list, the person who set the server up has gone, and earlier attempts to leave stopped	It costs money before anything changes, the server is exactly as unsupported meanwhile, and the list may be longer than anyone hoped

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. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Your own applications and jobs on each old server	A label: do not switch off	Every application and scheduled job listed, with what it does for the business	The map of the system
What each application stands on	Not recorded	The operating system and database each needs, with their published support dates	The specification
Programs that pin an old server	Found one at a time, when a move fails	Named for each server, with what ties each one there	The risk register
Exceptions for unsupported servers	”Pending replacement”, renewed each year	Each with the program that holds the server, an exit date and a price	The cost comparison and the staged plan

The starting points above are 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 logistics, travel or hospitality firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your applications and the servers beneath 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 booking, dispatch, rate and billing applications your firm built or had built, and what each of them stands on. 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 programs that pin an old server, rebuilt on current technology so that your own team can switch the server off. 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.

What we do not do: we do not migrate databases or data as a service; your own people, or a firm you choose, move the records. We do not upgrade or patch an operating system or a database, and we do not sell or arrange paid extended support. We do not replace, repair or retire servers, we do not monitor old servers, and we do not host. Until your own team retires a server, it is exactly as unsupported, and exactly as likely to fail, as before; we promise no level of availability and no protection from attack. Reading code may not find every need an application has, so your own team’s move still has to be tested. We do not work inside a packaged reservation, warehouse or property management product, and we do not work on the systems that run aircraft, trains or vehicles. We have no published case of this work for a logistics, travel or hospitality firm.

What changes for the business:

Role	What they gain
CEO	An old server stops being a thing the firm hopes will last, and becomes a list the board has seen, with a decision beside each line.
CTO or CIO	For each old server, a written list of the firm’s own applications and jobs on it, what each needs from the operating system and database, and which of them ties the server in place.
CFO	Money for leaving is put first where the business could least afford a stoppage, and is no longer set by which server failed last.
CISO	A customer’s or an insurer’s question about unsupported systems can be answered with a list: which servers, what runs on each, and what is planned.
COO	Operations knows which daily work rests on the oldest servers, and has agreed 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 very large national railway’s passenger reservation system has been in service for about fifteen years, and a press account in 2025 says it needs to move off older technology.	We make no comment on the railway and do not work on systems of that kind or scale. For a firm’s own applications, we write down what each stands on and what ties it there.
In September 2024 a US government auditor found 51 of the Federal Aviation Administration’s 138 air traffic control systems unsustainable, citing outdated functionality and a lack of spare parts.	We do not work on systems of that kind, nothing we do bears on the safety of air travel, and we make no comment on the agency. Our part is far narrower: a firm’s own business applications.

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 with the list of what runs on each old server, because every earlier attempt to retire one lacked it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →