The annual process missing from a ninety-day log

An old application is easy to dislike. It requires specialist support, complicates upgrades and appears in every discussion about simplifying the technology estate. When an interface shows no recent activity, removing it can seem an obvious step towards a cleaner system. The difficulty is that a quiet interface may support work outside the observation period. A ninety-day log can accurately show no use while an annual process still depends on the connection. The retirement decision needs to understand that business cycle before technical silence is treated as permission to withdraw a service.

At Orelvi, a project-administration application had nineteen recorded interfaces. Twelve had activity in the preceding ninety days and seven did not. The technical proposal suggested closing the seven quiet connections. We asked consumer owners to confirm the purpose of each one first. Five were no longer needed and could close. Two supported annual reconciliation work that had not occurred during the observation window. The logs were not defective. The proposed interpretation was too broad. Recognising that distinction allowed us to change the retirement plan without dismissing the value of the evidence the team had collected.

## Treat silence as a prompt to identify the consumer

The consumer may be a team, a business process or another application whose owner has changed. Finding that owner is sometimes harder than reading the traffic. An interface can survive several reorganisations while its purpose becomes increasingly obscure. I do not think that uncertainty is a reason to retain everything indefinitely. It is a reason to assign the investigation and a decision date. The company should know who can explain the work and who has authority to accept a change, rather than ask an infrastructure engineer to infer business importance from a technical connection alone.

A useful discussion describes the process in ordinary terms. What arrives through the interface, when is it needed, what happens next and what would fail if it stopped? The answer may reveal that the service is obsolete, duplicated or only used to compensate for another problem. It may also reveal a legitimate low-frequency obligation. Consumer confirmation should therefore be more than a request to sign a form saying that an interface is required. It should establish the work that must continue and the evidence by which an alternative route could be accepted.

Observation periods should be selected with the business cycle in mind. A monthly process and an annual reconciliation need different evidence, and an exceptional event may not appear in either routine window. That does not mean every retirement must wait a full year. Teams can examine records, consult responsible owners and conduct an appropriate trial. The important point is to understand what the evidence represents. A convenient period should not quietly become a definition of relevance simply because the monitoring system makes that period easy to report or because the shutdown date has already been announced.

## Price the bridge and the replacement separately

Once we identified the two annual dependencies, we retained them for a four-month transition. Additional support cost ₹12 lakh. A replacement route required ₹26 lakh within the capital programme. Those were separate commitments with different purposes: one kept the existing service available while the other established the future arrangement. I wanted both visible in the decision. Reporting only the eventual simplification would hide the cost of getting there; treating the bridge as an indefinite operating arrangement would lose the discipline of the retirement plan. The business needed to accept the transition with its dates and expense.

The delay was frustrating for the application team. They had good reasons to want the old service removed and had already planned other work around its closure. A CIO should acknowledge that pressure rather than portray the team as careless for trusting the activity report. The review exposed a missing consumer decision, not a lack of effort. We agreed which work could continue, who would own the replacement and what evidence was needed before the old interfaces were removed. That gave the technical team a bounded obligation instead of an open-ended instruction to keep supporting an unloved application.

A bridge can become a permanent arrangement if nobody is accountable for acceptance. The replacement needs a business owner who can confirm the outputs and any reconciliation required, with technical support for the trial. In our case the consumer owners specified the required outputs, examined a trial and accepted the new route before closure. Acceptance was not merely a message that the software had been installed. It concerned whether the annual work could proceed through the agreed process. That difference matters because a technically successful replacement can still leave the operating team unable to complete its obligation.

## Close the obligation before celebrating the shutdown

The reporting should preserve the different populations. Five of the seven quiet interfaces closed after owners confirmed they were unnecessary. Two closed later after replacement and acceptance. The twelve active interfaces followed their own planned migration. We did not describe the intervention as if it had independently resolved all nineteen dependencies. That would have overstated the case and obscured the work already under way. A clear retirement account lets directors and managers see what changed, what remained on another workstream and which cost belonged to each decision, without reconstructing the sequence from a single completion percentage.

Closure should also address what must remain available for legitimate reference and what can be removed under the company's authorised arrangements. The answer depends on the material, the obligations and the permissions involved. A technology team should not infer retention or disposal authority merely from the decision to stop an interface. Nor should it leave copies everywhere as a substitute for resolving the question. The retirement owner needs the relevant business and specialist advice so that the end of a live service does not create a different unmanaged problem in stored data or unsupported access.

For a board, the useful question is whether management understands the obligations being changed and has assigned acceptance to the right people. Directors do not need to approve every interface removal. They should be alert when a material simplification programme measures success only through systems switched off or costs removed from one budget. An interruption transferred into another department may not appear in that account until much later. Asking how low-frequency work was considered can reveal a weakness without requiring the board to prescribe the technical replacement or delay every change out of general caution.

The lesson I took from this case was to begin consumer confirmation earlier, while the retirement date could still be shaped by evidence. A dependency list should connect technical observations with the business cycle and a responsible owner. That makes it easier to close what is no longer needed and harder to mistake quiet for irrelevant. The result is not a commitment to preserve old systems. It is a more credible way to leave them: with necessary work transferred, costs understood and the people who rely on the service able to explain how they will continue after the connection disappears.