One Old Program Can Keep a Server Switched On. Extended Support Is One Answer of Four.
A firm moves to new servers and keeps the old one on for the sake of one or two programs. Here is what that holds up, the four ways off an old server (paid support, a move as it is, a packaged product, or a rebuild of the programs that pin it), weighed, and our recommendation.
The hotel group moved its systems to new servers in the spring. The old server in the basement of the first hotel was to be switched off in June.
It is November, and the old server is still on. It runs one program: the one that works out travel agents’ commissions at the end of each month. That program was written fourteen years ago, and it will not start on the new servers.
So the group pays for the old machine, for extended support on its operating system, and for the one engineer who knows how to coax it back to life.
The paradox: The group moved to new servers to be rid of the old one, and now runs both.
What We Found
We looked at the public record on the software beneath a firm’s own programs and on how firms see their old systems. It holds no case of a mid-size logistics, travel or hotel firm kept on an old server by one program.
Paid support buys time, and the time ends. For the server operating system Windows Server 2008 R2, even the paid security updates ended on 10 January 2023. For Windows Server 2012 and 2012 R2, support ended on 10 October 2023, and paid security updates ended on 13 October 2026. For the database SQL Server 2016, extended support ended on 14 July 2026, with paid updates available to 17 July 2029. These are one maker’s dates, and they are not about this sector.
Keeping old systems is seen as costly, and done anyway. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, nearly two in five named high maintenance or support costs among the top issues with their old systems, and half said the biggest reason they had not upgraded is that the current system still works.
Very large organisations live with the same tie. 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 only to show that what a system stands on can stay in place for many years.
What our review does not show: We found no named firm in this sector of our readers’ size kept on an old server by one program, no figure for what paid support costs, and nothing from the Middle East on this issue. The dates describe one maker’s products in general; which of them firms in this sector run was not researched. The survey is cross-sector, from a firm that sells related services. The railway account is not a finding about how its system performs. That one or two programs usually decide when an old server can go is our reasoning, not a measured finding.
What One Program Holds Up
A program left behind on an old server is usually treated as a loose end. Our reading is that it is the real project.
The server. A server cannot be half switched off. One program keeps the whole machine, its operating system and its database in service.
The money. Power, space, paid support and the one engineer are paid for twice: once for the new servers and once for the old.
The exception. As long as the program needs the old operating system, the server stays on the list of unsupported systems, renewed in the same words.
The gap we see: most firms in this sector that have moved to new servers can say that one or two programs stayed behind. Few can say why: what each does, what it needs from the old operating system and database, and what it would take to have that done by something that runs anywhere. A firm that holds that answer can choose its way off the server.
This is our reading of the evidence. It is not a measured market figure, and the cost of a second server room has to come from your own accounts.
Four Ways Off an Old Server, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Pay for extended support | 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 the program that pins the server is no nearer leaving |
| 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 program, its operating system and its database are exactly as unsupported in the new place, and the move is a project with its own risk |
| Replace the program with a packaged product | The firm’s way of working fits such a product, and it can carry a long change | Commission, freight and billing rules must be refitted to the product. 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 | One or two programs will not run on anything newer, and the firm wants the old server gone | It costs more than leaving the program where it is, it takes time, and the old server stays on, exactly as unsupported, until the last module is accepted |
Our recommendation: list first, then rebuild only what pins the server. Write down what each of your own applications stands on and which of them ties the old server in place. Then rebuild those programs, one module at a time on current technology, with the old program running until each module is accepted, and let your own team switch the server off in the ordinary way. Paid support may still be the right bridge while that happens: a separate decision, and not something we sell. We do not migrate databases or data, we do not upgrade or patch the operating system or database the old program needs, and we do not replace, repair or retire servers. We do not monitor the old server, and we do not host. Until the last module is accepted and your team retires the server, it is exactly as unsupported as before, and we promise neither that a system stays up nor that it is secure.
The honest costs. A rebuild costs more than leaving the program where it is, and the old server stays on meanwhile. The records the old program holds still have to be moved, by your people or a firm you choose. And a list made by reading code may not find every need a program has; some show only when it runs.
Where You Are Now, and Where You Should Be
Before the next support renewal is signed, we would set a benchmark for the decision.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Programs that pin an old server | ”One or two would not move” | Named, with what each does for the business and what ties it to the old operating system and database | The specification and the risk register |
| Answers weighed for each | One: renew the support | Four, each weighed against the program that pins the server | The cost comparison |
| The cost of staying | Paid support, renewed each year | Support, power, space and staff time for the old server, set beside the cost of ending the need for it | The cost comparison |
| The size of one commitment | A new system or a whole move | One module, with the freedom to pause after any accepted module | The staged plan |
| Who moves the records | Not named | Named: your own people or a firm you choose | Your plan, outside our work |
The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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
- We listen: a free Reliability Review. A first conversation about the program that keeps an old server on, and what stopped the last attempt to move it. 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 booking, dispatch, rate and billing applications your firm built or had built, and what each of them stands on. It produces 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 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. 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.
What you need to bring: a budget for the assessment; read-only access to the program’s code once the assessment begins; the people who rely on it, such as the accounts team, to say what it must never get wrong and to accept each module; your own people or a firm you choose to move the records; and your own team to keep the old server running until the last module is accepted, and then to switch it off.
What we do not do: we do not migrate databases or data as a service. 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 the old server, and we do not host. Until your own team retires it, the server is exactly as unsupported, and exactly as likely to fail, as before; we promise neither that a system stays up nor that it is secure. We do not move or rebuild 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 | The life of an old operating system stops setting the life of a part of the business, because the way off each server was chosen and not deferred. |
| CTO or CIO | The programs that pin an old server are named, with a chosen way off for each, so the team can plan to switch the server off in the ordinary way. |
| CFO | The yearly cost of paid support is set beside the cost of ending the need for it, program by program, before the renewal is signed. |
| CISO | Each exception for an unsupported server names the program that keeps it there and the answer chosen for it. |
| COO | Operations knows which nightly and month-end jobs the chosen answer will touch, and what it changes for depots and desks. |
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 program that runs only on an old operating system, we rebuild it one module at a time, so the firm’s own team can retire the server. |
| Paid security updates for Windows Server 2008 R2 ended on 10 January 2023; for SQL Server 2016 they are available to 17 July 2029. | Our part is narrower than this. We do not upgrade, patch or support servers or databases. We rebuild the firm’s own programs that need them, so that paid support stops being the only answer. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before another year of support is signed, we would find out which program is the reason for it.
Sources
- endoflife.date/windows-server
- Microsoft lifecycle, SQL Server 2016
- A vendor's survey, 2025
- News report, 2025
In this issue
Old servers and operating systems
Research note 1
The End Dates Are Published. The List of What Runs on Each Old Server Is Not.
The end dates for server software are published; the list of what runs on each old server is not. What we found, four ways to answer and the benchmark we set.
Research note 3
The Plan to Leave the Old Servers Has One Line for the Hard Part. Here Is the Benchmark We Would Set.
Plans to leave old servers describe the new setup and give the applications one line. The benchmark we would set before that line is signed, and who does what.
Issue study
Still in Service
A railway reservation system, an audit of air traffic control systems and published end dates: the options a logistics or travel firm has and our benchmark.
More from Logistics, travel and hospitality
Scarce skills and missing documentation
A Record Your Staff Open Before They Pick Up the Phone. Here Is the Benchmark We Would Set.
Inherited systems nobody understands
A Year After the Deal You Still Run Two of Everything. Here Is the Benchmark We Would Set.
Too slow and costly to replace