A component can be a sensible choice when a product is designed and become a difficult dependency years later. The supplier changes its range, support approaches an end and the manufacturer's installed products continue working in circumstances that do not follow the supplier's timetable. The resulting question is larger than whether another spare can be purchased. It concerns what the enterprise has promised to support, which configurations remain in use and what evidence is needed before an alternative can replace the original component.
In our fictional 2025 case, a supplier notice affected a controller family used in 260 installed units. The service team proposed ₹48 lakh of spare stock. I recommended a ₹1.1 crore redesign and transition programme with a defined pilot. Forty-four units entered that pilot; thirty-one completed the required conversion process and thirteen remained under configuration review. Those numbers describe the bounded position of the programme, not a completed transition of the whole installed base or an automatic approval for every vehicle using the product.
Stock postpones a dependency without always changing it
The stock proposal was reasonable. A familiar component can reduce immediate disruption, preserve existing service knowledge and avoid asking customers to accept a change before it is ready. Service colleagues understood the installed equipment and wanted a practical response to the notice. An engineering leader should not dismiss that proposal simply because redesign seems more strategic. Stock can be part of a useful support arrangement. The question is what it solves, for how long and which dependencies remain after the purchase.
A finite holding does not necessarily address future configuration questions, maintainability or the availability of related components. It can defer the point at which the enterprise must make a transition decision while leaving the underlying issue unchanged. That may still be the correct choice for some products or remaining service periods. The account should say so explicitly rather than describe the purchase as if it has secured support indefinitely. The value of the stock depends on the actual installed population and the commitment the business intends to make.
Redesign also has costs and uncertainty. A replacement can require development, testing, customer coordination and a period in which two support arrangements remain active. The enterprise may spend more before it knows whether every intended configuration can move. Those consequences should not be hidden behind a general statement about future readiness. In my case, the ₹1.1 crore was a development and transition commitment. It was not a claim that the programme had already produced lifetime savings exceeding the stock-only alternative.
The decision therefore needed a comparison of responsibilities, not merely two purchase prices. What would the stock route leave unresolved? What would the redesign route require from customers and service teams? Which installed units could enter a pilot, and what evidence would determine their treatment? Those questions allowed management to examine a real choice. A cheaper immediate response and a more expensive engineering response can both be defensible in different circumstances; neither should inherit the conclusion from its label alone.
The installed base is not one configuration
An installed count is useful for scale but can conceal variation. The 260 units did not become a single technical configuration because they shared a controller family. The pilot therefore had to preserve the actual installation context and the qualified release process. Thirty-one conversions were completed, while thirteen remained under review. Keeping both groups visible prevented the completed work from implying that the same treatment was already suitable for the remaining units or for the rest of the installed population.
The pending group creates practical work. Customers want to know what will happen, service teams need to support the current arrangement and engineering must explain the unresolved configuration question. A programme report that simply emphasises completed conversions can make that work disappear from the executive discussion. The answer is not to treat every pending unit as a failure. It is to retain its status, the owner of the next decision and the resources needed to reach a supported conclusion.
Qualified product and vehicle owners retained the release decisions. A replacement controller did not constitute a blanket approval of the body, vehicle or carried load, and the case is not a public retrofit instruction. This distinction matters when a programme moves from development into customer communication. The enterprise should describe what has actually been assessed and released, without allowing the availability of a new component to imply that every application can use it unchanged. Engineering confidence must remain attached to the configuration it supports.
There is also a commercial boundary to explain. A customer may reasonably understand product support differently from a supplier's component warranty or catalogue period. The manufacturer needs to examine the actual commitment and communicate the transition without assuming that the upstream notice automatically settles its downstream responsibility. Appropriate commercial and professional colleagues have a role in that assessment. The CTO contributes the technical dependencies and alternatives, rather than deciding contractual obligations from the component's availability alone.
Put support life into the original selection
The strongest response begins before an end-of-support notice. Component selection should consider the intended installed life, the configuration record, access to relevant technical material and the practical options if supply changes. Those questions do not require predicting every future event. They make the dependency visible while the enterprise still has meaningful choices. A component can remain the right selection even with a limited support horizon, provided the product plan accounts for that horizon instead of treating it as someone else's later problem.
The installed configuration record is part of that preparation. Without it, the enterprise may know how many products it delivered but struggle to identify which changes belong to which units. A transition then becomes a broad investigation at the moment customers need a clear answer. Maintaining the record has a cost, and the service process must keep it useful as products change. That cost belongs within the support model rather than being justified only after a supplier notice reveals why it matters.
Directors can ask whether long-lived products depend on short-lived support assumptions, whether management has identified the significant cases and whether the financial plan includes a credible response. They do not need to choose the replacement controller. They need an account that distinguishes spare stock, development, qualified release and customer commitment. The thirteen pending pilot units are relevant to that account because they show the programme's actual boundary, not because every unresolved item should become an individual board decision.
The installed product has a life beyond the component catalogue that first made it possible. A manufacturer should understand how it intends to support that life and what it will do when a dependency changes. My lesson was to compare stock and redesign as different commitments, with the installed configurations and unfinished work visible. That makes the support decision more honest for customers and more useful for the enterprise than treating a spare purchase as a complete strategy or a new controller as a universal answer.