A source archive is the beginning of a software handover

The supplier had delivered the source archives. The files were substantial, organised and available to our team. That made the handover look complete from a distance. In the agreed receiving environment, however, only eight of eleven components built successfully. Two required commercial dependencies whose continuing use needed proper arrangements. Another needed a generator version absent from the delivery. We had received something important without yet receiving the practical capability the transition was intended to provide.

The distinction was uncomfortable because the supplier could demonstrate its own working build. It was tempting to treat our difficulties as an internal setup matter and close the commercial milestone. Some of the work was indeed ours to do. But the purpose of the handover was not simply to preserve a set of files while the knowledge and conditions needed to use them remained elsewhere. I wanted a receiving-team result that showed what we could reproduce, which permissions supported that work and what still depended on another party.

## Define what the receiving team must be able to do

The transition began in September 2025 with an ₹86 lakh budget. We needed to understand the dependencies and tools behind the delivered components, including the conditions under which they could be used. Engineers could identify that a build expected a library or generator. They could not settle every contractual right associated with it. Legal and commercial colleagues therefore owned the relevant arrangements, while the technical team made the missing requirements concrete enough for those colleagues to assess. Possession of a file was not treated as a complete account of permission.

I found it useful to describe the intended capability in ordinary terms. Could the receiving team reproduce the agreed software in the agreed environment? Could it identify the inputs and tools required? Could it run the relevant tests and understand which result corresponded to the proposed release? Could it distinguish a dependency it was entitled to maintain from one that still required a supplier relationship? These questions gave the transition a practical shape without pretending that every component had to become independent of every external service or commercial licence.

The sponsor's concern was that keeping the milestone open would prolong a transition already consuming management attention. That was a real cost. A handover can become an endless exercise if nobody defines the required result and the boundary of further work. I did not ask for an abstract assurance that all future maintenance would be effortless. I asked for the specific receiving capability the programme had been funded to establish. The three blocked components showed where that capability was incomplete, and the team needed a bounded plan to resolve each condition.

We also had to avoid turning the issue into a contest over whether the supplier had acted in good faith. The archive could be genuine and the handover still be insufficient for its intended use. The useful discussion concerned the missing dependency, the owner who could resolve it and the evidence needed afterwards. That approach made it easier to recognise our own preparation gaps as well. If our receiving environment differed from the agreed conditions, we needed to state that rather than assign every difficulty to the party delivering the files.

## Separate build capability from release acceptance

The dependency and tooling issues were resolved through the authorised route, and all eleven components eventually built in the agreed environment. That was a meaningful result. It did not establish that every feature was ready for customers. In twenty-six defined device tests, twenty-four passed and two did not. The two affected features remained deferred. I wanted that result stated beside the successful builds, because a transition report that stopped at compilation would encourage colleagues to infer a wider readiness than the engineering evidence supported.

Engineering quality head Mira Zervathi retained the acceptance decision, with manufacturer involvement where the tests concerned hardware relationships. The approaching end of the supplier engagement did not change the test criterion. Nor did the fact that a feature had worked in a previous demonstration establish that the receiving team's version met every required condition. Reproduction and acceptance are connected stages. A useful handover should make it possible to perform the latter, but it should not collapse the two merely to create a simpler completion message.

The project finished at ₹94 lakh, an ₹8 lakh overrun against the ₹86 lakh budget. I reported the overrun separately from the feature deferrals. Combining them into one vague statement about transition difficulty would conceal two decisions: the extra expense required to establish the build capability and the scope that still could not proceed. Directors and executives need to see both if they are to assess the result fairly. An honest account can recognise that a useful capability was obtained while acknowledging that it cost more and supported less immediate release than originally expected.

I also avoided describing the outcome as a complete transfer of intellectual-property rights or permanent freedom from suppliers. Those claims depend on the actual agreements and the continuing technical relationships. A company can gain a much more useful maintenance position while still relying on licensed components, external expertise or manufacturer cooperation. The point is to understand those dependencies and manage them deliberately. A dramatic claim of independence would have obscured the very conditions the handover work had helped us uncover.

## Rehearse the handover before the relationship ends

In retrospect, the receiving-environment rehearsal should have occurred earlier. The final archive carried commercial significance, so a technical problem discovered at that point became a debate about closing a relationship. Earlier reproduction work could have exposed the same questions while the supplier team and our receiving colleagues still had more time to resolve them. That would not remove every dependency or prevent every overrun. It would make the uncertainty visible before the calendar made it harder to discuss without defensiveness.

I now want transition planning to include a practical sequence of receiving work, with evidence appropriate to each stage. The team should know what a successful delivery enables and what it does not yet establish. That sequence also helps commercial colleagues write a milestone they can assess without becoming software engineers. An archive arriving on time is observable. A reproducible build and a defined test result are also observable when the programme prepares the evidence in a form the wider organisation can understand. The technical detail should support the decision rather than hide it.

The case has relevance beyond supplier transitions. A team can inherit a product internally, acquire software through a business transaction or take responsibility after an original developer leaves. In each case, the visible artefact may be easier to transfer than the conditions needed to use it. That does not justify endless documentation for every small application. It asks leaders to identify the capability that matters and test whether the recipient has obtained it. The proportionate evidence will depend on the product, its obligations and the consequences of being unable to maintain it.

For board service, I would bring questions about that capability and its limits. What will the company be able to do after the transition? Which dependencies and rights remain? Has the receiving team demonstrated the result, and which features still await acceptance? What extra spending or ongoing relationship does the plan assume? Those questions preserve management's responsibility for implementation while helping directors assess whether a contractual or organisational milestone corresponds to a usable operating outcome. The source archive matters, but the company is usually paying for something more consequential than possession of the archive itself.