The Plan to Leave the Old Servers Has One Line for the Hard Part. Here Is the Benchmark We Would Set.

The plan for leaving the old servers has forty lines. Thirty-nine are about the new environment: the accounts, the network, the backups, the training.

Line twenty-two reads “Migrate applications and data”. It has one date and no owner. In the budget it has one figure, with “approx.” in front of it.

The finance head asks what line twenty-two is made of. The answer is eleven applications, a number of overnight jobs nobody has counted, and nine years of consignment records. Which of them will move easily, and which will not move at all, nobody can yet say.

What We Found

We looked at the public record on the dates that drive plans to leave old servers and on why firms hold back. None of it is about a firm of our readers’ size: the research behind this article holds no case of a mid-size logistics, travel or hotel firm leaving its old servers, and no figure for what that costs.

The deadline usually comes before the scope. 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. These are one maker’s dates and not about this sector, but a plan written to beat a date like these has its deadline before it has its scope.

The worries that hold firms back are the ones line twenty-two hides. 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 budget limits among their reasons for not upgrading old systems, and more than a third each named fear of disrupting operations and concerns about moving data.

What a Move in Stages Opens Up

A list of what stands on each old server is usually seen as the technology team’s homework. Our reading is that it frees more.

• The figure gets something under it. Each application is a known kind of job, and each stage has its own price beside the cost of staying.
• The hard part comes first. The programs that pin an old server are named before the plan is signed, not met in its last third.
• The exception gets an end. Each unsupported server on the exception list carries the program that holds it, an exit date and a price.
• Every job has a name. Moving what can move, carrying the records and retiring each server are given to your own team or a firm you choose; rebuilding what cannot move is the part we do.

This is our reading. It is not a measured market figure.

Three Ways to Plan the Move, Weighed

Option	When it fits	What it risks
Keep renewing paid support and the exceptions until a larger replacement	Paid updates exist for every server, and a replacement of the whole estate is already funded and dated	Paid support ends, and the programs that pin each server are no better known when the replacement arrives
One project, “migrate everything”, priced as one figure	The applications are few, recently written and known to run on newer systems	The hard applications are met in the last third, the date slips and the old servers stay on past their deadline
List what each application stands on, name the programs that pin each server, and rebuild those module by module against a benchmark; your own team moves what can move, carries the records and retires each server	Nobody holds a full list, earlier attempts stalled, and the firm wants each exception closed for good	It costs money before anything moves, the plan that comes back may be longer and dearer than one line, and the servers stay exactly as unsupported until each is retired

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

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	The specification
Programs that pin an old server	Met in the last third of the move	Named for each server, with what ties each one there, before the plan is signed	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, module by module
Who does each part of the move	”Migrate applications and data”, no owner	Named: your team moves what can move and retires each server; your people or a firm you choose carry the records; we rebuild what cannot move	Your plan, and our staged plan for our part

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.

A small part of the finished list might look like this.

Old server	What ties it in place	Status
Accounts server	The month-end commissions program needs the old database version	Stage 1: rebuilt beside the old program; matrix accepted; your team retires the server
Depot server	The rate calculator runs on the newer system as it is	Moved by your own team; no rebuild needed
Head office rack	A packaged warehouse product	Outside our work: the product’s maker or specialist
Units in the vehicles	Systems that run vehicles	Outside our work

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the plan to leave your old servers and the line that holds the hard part. 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.
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 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 above. As each module is accepted 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 has a price. You pay for the assessment before the move is approved, and the plan that comes back may be longer and dearer than the one line it replaces. A support date may pass while the work is under way, and the old servers must be kept and paid for until each is retired. Our fixed quote is for our own part; the parts done by others are priced by them. We do not migrate databases or data, and we do not move applications from one server to another as a service. We do not upgrade or patch operating systems or databases, and we do not sell paid support. We do not replace, repair or retire servers, we do not monitor them, 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 neither that a system stays up nor that it is secure. 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.

At the end you hold the specification, the list of what each application stands on, and the traceability matrix and code for every module we rebuilt. Moving what can move, carrying the records and retiring each server are your team’s.

What changes for the business:

Role	What they gain
CEO	”Get off the old servers” becomes a plan the board can approve one stage at a time, with a first stage small enough to start.
CTO or CIO	An order of work against a benchmark: which programs pin which server, which are rebuilt in each stage, and what each stage depends on.
CFO	A price for each stage beside the cost of staying, in place of one figure for “migrate everything”.
CISO	Every exception for an unsupported server carries an exit date and a price, and the list is reported against them at each review.
COO	Operations knows before each stage which daily work moves in it, and each rebuilt program is compared with the old before depots and desks rely on it.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
For Windows Server 2012 and 2012 R2, paid security updates ended on 13 October 2026; for Windows Server 2016, support ends on 12 January 2027.	Our part is narrower than this. We do not upgrade or patch servers, sell paid support, or move what already runs. We name the firm’s own programs that pin each server and rebuild those, so the firm’s own team can retire the server against a date it has set.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We cannot make an old server safe while it waits, and we will not claim to; we can open line twenty-two before you sign it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →