Chief Information Officer / India
The handover needed evidence beyond the receipt
- Company employees
- 310
- March 2026; eighteen IT colleagues through three heads
- Company revenue
- ₹124 crore
- FY 2025–26; ₹9.7 crore operating profit
- Enterprise technology experience
- 27 years
- Applications analysis through manufacturing CIO responsibility
Decisions & consequences
01Requiring a current business reason for thirty-one inherited modifications
Before a 2022 enterprise-software upgrade, the applications team listed eighty-six customisations. Thirty-one could not be supported by a current business explanation that their owners could state clearly. Some preserved an earlier process that had changed; others duplicated functions now available in the standard product. My earlier approvals had sometimes favoured keeping a familiar screen because reconsidering it would delay the project. That had made the maintenance burden less visible at the point of acceptance.
The initial proposal was to carry all eighty-six modifications into the upgrade and address simplification later. Business managers worried that removing familiar behaviour would disrupt their teams. I asked for a decision on the thirty-one items before that commitment. We compared the requirement, standard behaviour and consequences of each option with the relevant owners. IT did not unilaterally decide that a process was unnecessary because its code was inconvenient.
The fourteen-week programme cost ₹74 lakh. Nineteen of the thirty-one customisations were retired after agreed replacement processes and acceptance work; twelve were rewritten around the current requirement. The remaining fifty-five stayed outside that change scope with their existing ownership and support responsibilities. We did not call them permanently validated or report an unmeasured maintenance saving. The programme incurred real effort and changed the upgrade timetable.
One commercial manager wanted an old report retained because it was used at a weekly meeting, even though its source definitions no longer matched the current process. We agreed the question the meeting needed to answer and provided a reviewed replacement. That took longer than copying the report unchanged, but it prevented familiarity from becoming the only argument for preserving its behaviour.
The outcome was a more deliberate account of the modifications being carried forward. I learned that a CIO should not let an upgrade become a ritual of reproducing every previous compromise. Customisation can be justified, but it needs an owner who can explain the business purpose and accept the continuing responsibility. My part was to bring those choices into the programme while acknowledging the earlier decisions that had helped create the problem.
Testing whether source archives could support another development team
In 2024 we reviewed continuity arrangements for five business applications maintained with a specialist supplier. Source archives were present under the agreed deposit arrangements. A summary to management had treated that fact as evidence that another team could take over if required. I asked for an authorised verification exercise in an isolated environment, with the supplier's participation and the relevant contractual permissions reviewed before access.
Only two of the five applications initially built from the supplied materials. The other three depended on unclear component versions, missing build-tool information or instructions that assumed knowledge held by the original team. The result did not prove misconduct by the supplier or establish that a contractual release event had occurred. It showed that the technical continuity claim was broader than the evidence from the deposit alone.
We funded a ten-week, ₹62 lakh programme to document and supply the required dependencies and repeat the builds. Four of the five applications could then be reproduced in the agreed environment. One remained unresolved because a required component and its permitted use still needed clarification. I reported that application separately, with the supplier relationship and further review continuing. We did not infer that producing an executable established full functional acceptance or readiness for live manufacturing use.
The CEO asked whether the four successful builds meant the company could end supplier support. I explained that rebuildability was one part of the account. Knowledge of business behaviour, appropriate rights, security review, testing and continuing support capability still mattered. The exercise was not a production migration and did not authorise the team to use materials beyond the agreed scope.
The case changed the way I presented a software handover. A receipt can establish that materials were deposited; it cannot demonstrate every capability the company hopes to obtain from them. I wanted management to see the exact progress and the unresolved dependency, including the expense incurred. That allowed the next commercial and technical decisions to be made on evidence rather than a comforting statement that the source code was safely somewhere else.
Replacing copied contacts without hiding the tests that still needed work
A 2025 review of sixteen development and test datasets found that nine contained real customer-contact details copied from business applications. The copies had been retained because they made demonstrations and regression exercises convenient. I had previously accepted production-derived test material without requiring a sufficiently clear account of its contents and purpose. Calling the environment a test system had not changed the nature of the details inside it.
We restricted use of the nine datasets while the relevant owners reviewed handling, access and retention. The review did not establish a public disclosure or make a legal finding. I asked the development and process owners to identify the scenarios they actually needed to exercise. They defined sixty-five, including ordinary business flows and known boundary conditions. That gave us a basis for building fabricated test material without simply replacing a name and assuming the rest of the copied record was harmless.
The seven-week replacement programme cost ₹27 lakh. Fabricated datasets supported fifty-eight of the sixty-five defined scenarios. Seven required a separate controlled approach with further specialist review, and remained outside the completion claim. The other seven original datasets were outside the identified real-contact subset; their ordinary ownership and review obligations continued. We did not use the exercise to declare every test environment free of sensitive material.
Developers were concerned that losing familiar examples would make defects harder to reproduce. I accepted that useful test coverage had to be preserved, and I funded the scenario work instead of issuing a deletion instruction and treating the problem as closed. Decisions about existing copies followed the appropriate retention and handling process. The replacement data was labelled for testing so that it would not be mistaken for an operational customer account.
The outcome was a clearer connection between test purpose, permitted material and demonstrated coverage. I reported fifty-eight scenarios supported by the new approach and seven still requiring another method. The lesson was that a privacy-conscious correction also needs an honest quality account. Removing real details is not an excuse to overstate what the resulting tests establish or to leave the development team without a workable way to examine the remaining cases.