Still in Service

1. At a Glance

Issue study · From the public record. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Both are government bodies far larger than the firms we write for, and neither runs systems of a kind IOanyT works on. We found no public case of a mid-size logistics, travel or hotel firm harmed because a server or its operating system was out of support. Each case is reported as the public record gives it, without judgement.

Organisation type	A very large national railway whose passenger reservation system has stayed in service for about fifteen years, set beside the position of a mid-size firm that moves goods, moves people or looks after guests, with its own applications on servers past their makers’ support
Size band	The cases: very large, government. Our reader: a mid-size transporter, courier, forwarder, bus or tour operator, travel seller or hotel group with a few old servers at head office, in accounts and at depots or hotels
Region	The railway: Asia. The reader: anywhere
The decision at stake	What to do about a server past its maker’s support: pay for extended support, move it as it is to new hosting, replace the applications with a packaged product, or list what each application stands on and rebuild the programs that pin the server
The public outcome	The railway’s passenger reservation system has been in service for about fifteen years, and a published account says it needs to move from older technology to current cloud-based systems
Why it matters to a mid-size firm	Systems stay in service long after they are called legacy. A firm’s own old servers stay for a plainer reason: nobody has listed what runs on each, so leaving cannot be priced

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

“We have four servers whose operating systems their maker no longer supports. I know where each one is and how old it is. What I cannot tell our largest shipper, or our insurer, is what runs on them. We moved most things to new servers last year, and one program that works out the month’s commissions would not start, so the old machine stays on, with a support contract and one engineer who understands it. Every year the exception is renewed, ‘pending replacement’. I do not know what leaving would cost, because nobody can say what would have to move.”

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

The firm is caught between servers it cannot keep for ever and applications it cannot describe. The answer it can buy quickly, another year of support, does not change what holds the server in place.

3. What We Found

Method. We went through the public record on the software beneath a firm’s own applications: the published end dates for one maker’s server operating systems and databases, reporting on a national reservation system, a US government audit of air traffic control systems, and one cross-sector survey on how firms see their old systems. The reports were published between September 2024 and August 2025; the end-date pages are live pages, read on 12 October 2026. The sector research behind this study holds no case of a mid-size firm on this issue, no figure for what paid support or a failed server costs, and no figure for how often it happens.

A system that stays in service. The case is a very large national railway, a government body, as reported in the press in 2025. We pass no judgement on it, and systems of that kind and scale are not IOanyT’s work.

What	Public record
The system	Passenger reservation system
When deployed	About fifteen years before the report
How it is described	As needing to move from older technology to current cloud-based systems

We report this as published. The account’s own names for the servers and operating system are garbled, so we name neither and do not call them old. We say nothing about how the system performs or about its announced replacement.

An audit of far larger systems. This concerns systems that control air traffic. They are not IOanyT’s kind of work, nothing in this study bears on them or on the safety of air travel, and no judgement is passed on the agency. In September 2024 a US government auditor reported on the air traffic control systems of the Federal Aviation Administration.

What	The auditor’s words
The finding	”of its 138 systems, 51 (37 percent) were unsustainable and 54 (39 percent) were potentially unsustainable”
Causes named	”citing outdated functionality, a lack of spare parts, and more”
On timing	”Some system modernization projects won’t be complete for another 10-13 years.”

We quote the auditor and add nothing. The audit is used for one narrow point: old systems stay in service long after the parts and the support behind them have gone.

The published end dates. These are one maker’s dates and are not about this sector; which of these products firms in this sector run was not researched.

Product	Public record
Windows Server 2008 R2	Paid security updates ended 10 January 2023
Windows Server 2012 and 2012 R2	Support ended 10 October 2023; paid security updates ended 13 October 2026
Windows Server 2016	Support ends 12 January 2027
SQL Server 2016	Extended support ended 14 July 2026; paid updates available to 17 July 2029

What firms say about their old systems. In one cross-sector survey of about 500 US IT professionals, 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; more than two in five named budget limits, and more than a third each named fear of disrupting operations and concerns about moving data.

Our reading of why old servers stay. These four are our reasoning from the record above. None is a finding of any source, and none is a finding about either organisation.

1. Nobody has a list of what each server carries. The inventory lists machines, not the applications and scheduled jobs on each, or what each needs from the operating system and the database.
2. One or two programs will not run anywhere else. They were written for the operating system and database of their day, and the server stays on for their sake.
3. The plan to leave treats every application alike. “Migrate everything” is one line with one figure, so the hard programs are met late.
4. The exception has no end. “Pending replacement” is renewed each year, because nothing behind it has changed.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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, some versions have none left, and nothing that holds the server in place changes	Right as a bridge while a way off is built, as a separate decision
Move the server as it is to new hosting	The hardware is the worry, and the firm’s own team will upgrade the operating system and database soon after	The operating system and database are exactly as unsupported in the new place; the move is a project with its own risk	Right only when an upgrade by the firm’s own team follows and is dated
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; nobody yet knows which programs pin the server	The firm’s own decision, and not IOanyT’s kind of work; we would advise against this as the answer to an end date alone
List what each of the firm’s 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, one or two programs will not move, and earlier attempts stalled	Costs money before anything changes; the server stays exactly as unsupported until the firm’s own team retires it	Our recommendation

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

For the applications a firm built or had built (booking and quotation tools, dispatch and trip-planning, rate and tariff tools, billing and invoicing, and the overnight jobs between them): list first, then rebuild only what pins the server. Write down what each application and scheduled job on each old server does, what it needs from the operating system and the database, and which of them ties the server in place. Then rebuild those programs module by module on current technology beside the old ones, with a traceability matrix to prove each module does what the old one did. The old program keeps working until each module is accepted. The firm’s own team, or a firm it chooses, moves what can move, carries the records and switches each server off in the ordinary way. Until then each server is exactly as unsupported as before, and IOanyT neither monitors nor hosts it; paid support may be the bridge, as a separate decision.

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
Applications with a written record of what they stand on	None, or a list of machines	Every application and scheduled job on each old server, with the operating system and database it needs and 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 size of one commitment	One figure for “migrate everything”	One module, with the freedom to pause after any accepted module	The staged plan
The programs that pin a server, rebuilt	Untouched, because month end depends on them	Rebuilt module by module beside the old program, each shown to do what the old one did	The traceability matrix
Who moves the records and retires each server	Not named	Named: the firm’s own team, or a firm it chooses	The firm’s plan; outside IOanyT’s work

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your applications, the old servers beneath them, and what stopped the last attempt to retire one. 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 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.
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. 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: what the firm’s own applications do, in writing.
• The risk register: the programs most likely to pin an old server, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• 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.

Moving what can move, carrying the records and retiring each server belong to the firm’s own team or a firm it chooses.

9. What This Approach Does Not Cover

• IOanyT does not migrate databases or data as a stated service. The research’s suggested answer to this issue included database migration; the firm’s own people, or a firm they choose, move the records.
• IOanyT does not upgrade or patch an operating system or a database, and does not sell or arrange paid extended support.
• IOanyT does not replace, repair or retire servers, and does not move applications from one server to another as a service.
• IOanyT does not monitor old servers, and does not host.
• Until the firm’s own team retires a server, it is exactly as unsupported, and exactly as likely to fail, as before. IOanyT promises neither that a system stays up nor that it is secure.
• Reading code may not find every need an application has from its server; some show only when it runs. The firm’s own move still has to be tested.
• IOanyT does not install, upgrade, move or choose a packaged reservation, warehouse, property management or ERP product, and does not work on the customisations inside one.
• IOanyT does not work on the systems that run aircraft, trains or vehicles, or on anything on which a traveller’s safety depends, and does not read COBOL, RPG or FoxPro.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what any transport, aviation or data protection rule requires of a particular firm. Whether a firm may use a public cloud is the firm’s decision.
• This study does not say IOanyT would have prevented or changed anything described in it. IOanyT has no published case of this work for a logistics, travel or hospitality firm.

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

10. Sources

Source	Used for
News report, 2025	A national railway’s passenger reservation system
GAO-24-107001, 23 September 2024	The audit of air traffic control systems (section 3 only)
endoflife.date/windows-server	Support dates for a server operating system
Microsoft lifecycle, SQL Server 2016	Support dates for a database
A vendor’s survey, 2025	Top issues with old systems and reasons for not upgrading

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. An old server stays in service until someone lists what holds it there; we start with that list, and rebuild only what pins it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →