An old application can become an awkward presence in a modernisation presentation. It may occupy a small corner of the architecture diagram while consuming disproportionate attention from the people who still understand it. The natural ambition is to remove the dependency. I share that ambition. My concern is with the point at which a desired retirement becomes an assumed fact in a savings case. If the organisation still needs the application to interpret historical material, the dependency has not ended merely because new work has moved elsewhere or the replacement project has declared completion.
The distinction became concrete in an archive review at Orvanel. We examined 1,200 sampled historical laboratory packages before retiring an older reader. Of those, 1,056 were fully readable through the proposed replacement route, while 144 needed the older capability. The numbers did not establish a failure rate for the entire archive. The sample had been chosen to explore different periods and configurations, not to support a statistical extrapolation. It did establish a dependency that the retirement proposal had to address. A majority of readable packages could not make the remaining packages irrelevant.
Separate new work from historical access
The application was no longer our intended route for new activity. That was an important change, but it answered a different question from whether earlier material could be examined without it. I asked the team to separate those two decisions in the programme account. Doing so made the remaining obligation more manageable: we could define a controlled retrieval purpose rather than keep the full old operating arrangement by default. It also prevented the replacement project's success from being used as evidence for a retirement decision that had not yet been adequately supported.
A retained capability needs an operating description. Who is allowed to use it? Which material does it support? What configuration and knowledge does it depend on? Who responds if the route becomes unavailable? These are practical questions, not an argument for keeping every historical system indefinitely. Without answers, an old reader can become an unowned service that everyone assumes somebody else maintains. That is a poor outcome for both technology cost and record stewardship. A narrow, documented purpose gives the enterprise a better basis for deciding whether and how the dependence should continue.
The relevant specialists must also define what they need to understand. A technology team can make a file open while missing the context that gives its contents meaning. Equally, it can preserve unnecessary complexity because nobody has challenged which elements remain relevant. I want laboratory and quality colleagues involved in that discussion, with their responsibilities clear. My team maintains the technical route and describes its limitations. The judgement about the material's suitability for a particular review belongs with the appropriately qualified and authorised people. Neither group benefits from treating the other's participation as a formality.
Price the actual choice
The original proposal anticipated EUR180,000 in annual decommissioning savings. We instead recommended EUR430,000 for a defined programme to retain a segregated reader and support the retrieval requirement while developing the replacement route. These amounts describe different things: an expected recurring saving and a specified retention programme cost. They should not be casually subtracted to produce a payback period or a permanent annual disadvantage. The decision needed its own account of period, scope and continuing obligations. Precision about those boundaries made the conversation with finance more useful than a contest between the labels legacy cost and modernisation benefit.
I did not ask colleagues to ignore the cost because the work involved regulated records. That would have made the recommendation harder to challenge and potentially easier to overbuild. We examined the narrow capability required, the access arrangements and the support needed. We also considered the effort of producing a replacement interpretation route. A responsible proposal should let the organisation compare feasible alternatives, including their limitations. It should not imply that one is free of uncertainty simply because it is newer, or that any expenditure on an older system is justified by invoking an unspecified future need.
The sample result remained bounded in the investment paper. I reported that 144 of the 1,200 examined packages required the reader under the tested conditions. I did not estimate the total number of dependent packages without evidence, and I did not declare that retaining the reader resolved every retrieval issue across the archive. That restraint did not weaken the recommendation. It made clear which observed fact supported the immediate decision and where further work remained necessary. An honest limitation helps directors decide what additional evidence they want, rather than leaving them to discover the qualification after approval.
There was an opportunity cost in keeping specialists on the problem. The effort could not simultaneously serve every proposed programme. I included that consideration alongside the financial cost, because a retirement decision can consume scarce knowledge as well as software support. It may be tempting to accelerate a replacement route by assuming that the people who understand the oldest material can contribute without limit. Their knowledge is precisely why their availability needs planning. A programme that depends on them should state the contribution required and protect the time, rather than rely on goodwill at the end of another working day.
Define what would permit the next decision
A decision to retain should contain a route to reconsideration. I ask what evidence would allow the organisation to stop using the reader, which people must assess that evidence and how the support arrangement will be reviewed in the meantime. This is different from selecting an arbitrary retirement date and expecting the evidence to catch up. A date can organise effort, but it should not silently change the acceptance question. If the required conditions are not met, the next discussion should address that fact and its consequences openly, including the cost of extending the arrangement.
I would not prescribe one retention period for every laboratory package or claim that a single architecture satisfies every future requirement. Those questions depend on the material, the organisation's responsibilities and appropriate specialist advice. My contribution is to keep the technical dependency legible: what can be read now, what still needs the older environment and what work could change that position. The company can then take a decision with an understanding of the practical obligation, rather than confuse an attractive diagram with an operating capability that has already been demonstrated.
An older reader should neither be hidden nor celebrated. It is a means of meeting a defined need while the organisation develops a better route. I want a successor to know why we retained it, what we tested and what remains uncertain. That record makes eventual retirement easier to justify because the decision can follow evidence accumulated over time. The best modernisation account does not merely show that old technology has disappeared. It explains how the enterprise has ceased to depend on it without losing its ability to understand the work that came before.