End-of-life SCADA software or applications: risks and solutions

Industrial supervision software, known as SCADA software, is a key component of industrial information systems across a wide range of sectors, including industry, energy, building management, water and the environment. However, a large number of installations rely on solutions that are obsolete or becoming obsolete: applications frozen in time, software vendors that have gone out of business, or software abandoned by its publisher, and systems not kept up to date by the operator. The case of SOFREL PCWin2, whose end-of-life has been officially announced by its publisher, perfectly illustrates the challenges faced by many operators. Faced with the danger posed by operational failures and the lack of scope for development, what are the warning signs to watch out for, the risks involved and the strategies to adopt?

Warning signs to watch out for

1. Software that is no longer being updated (or rarely so) due to a lack of regular new releases from the publisher.
2. The publisher ceasing trading or the official announcement that sales and support are being discontinued. This is the case with SOFREL PCWin2 and Schneider Electric Citect software.
3. Software installed on an old operating system (OS) that may be incompatible with the latest OS versions.
4. The absence of a security patch management policy by the publisher, which is nevertheless essential in Europe with the NIS2 regulatory context.
5. Dependence on rare or unavailable skills: integrators who no longer have a firm grasp of the solution, loss of in-house expertise.
6. A lack of interoperability with new communication-enabled equipment and industrial control system components.
7. An application that has not been updated, with obsolete process diagrams and business logic that no longer reflect the reality on the ground.
8. An application that has undergone numerous changes, with unstructured or ill-considered patches that ultimately weaken the entire application. 
9. Incomplete or outdated documentation that turns every intervention into a risk.

All these indicators point to risks that could jeopardise operations: 

• Unpatched security vulnerabilities provide entry points for cyber-attacks
• A loss of internal and/or external expertise undermines day-to-day management of the solution
• A lack of support poses a risk to service continuity and overall operations
• An application that is out of step with the reality on the ground leads to operational losses
   

When should you start a migration, and what solutions should you consider?

The golden rule: plan ahead. As soon as one or more warning signs are identified, it is advisable to launch a modernisation project without delay, rather than waiting for a failure to force an urgent migration, which is always more costly and risky.
What strategy should be adopted for this migration? Three approaches are possible depending on the context. 

1. Migration to an identical version involves switching to a more recent version of the existing software, where possible. It offers functional continuity (provided the software’s upward compatibility is properly ensured by the vendor), a (often) streamlined change management process, and controlled costs. Please note that this approach can sometimes perpetuate dependence on the software vendor and limit the benefits of modernisation.
2. Migration with transformation involves partially rethinking the existing architecture whilst retaining the existing software: redesigning synoptic diagrams, modernising communication protocols, and integrating with IT systems (databases, web, cloud). This is often a good compromise — provided, however, that the cost of the update remains reasonable and that internal skills are retained.
3. Finally, complete replacement. This total overhaul, based on new standards and a modern architecture, represents a significant investment in terms of cost, potential complexity and change management. Nevertheless, this alternative paves the way for the long-term viability of the application and sustainable alignment with current and future technical requirements.

Whatever approach is chosen, the success of a SCADA modernisation project depends on a structured preliminary planning phase: an audit of the existing system, definition of functional requirements, selection of the target solution, a migration plan and change management. 

>> Key steps detailed in this article

The Topkapi supervision solution offers a practical solution for software replacement, featuring an open architecture, extensive interoperability and a dynamic approach to continuous development, ensuring longevity and scalability for years to come. It is a choice worth considering for any project involving the refurbishment or replacement of end-of-life SCADA software.