A great deal has happened across the tech landscape over the last three decades, while comparatively little has changed in SCADA, an industry that as a whole remains deeply conservative.
Industrial automation's conservative streak is something we appreciate fully whenever automation touches personal safety. More recently, though, that same caution is creating new risk for operators running assets on SCADA: every year without uplift, disaster moves a little closer. New technology has emerged, and it isn't IoT or IIoT, which mostly complements rather than replaces SCADA, and is mostly used on non-critical assets. Surprisingly, basic SCADA from three decades ago still runs in places today. A second generation has long since emerged and is used across manufacturing, heavy industry, and building management worldwide. If you're not at least on that second generation, the exposure is real, in the same way an antique car is wonderful to drive but isn't built to today's safety standards.
As systems evolved through the 90s, vendors added new functionality onto old platforms to keep ageing products viable, with mixed results. Bolting on new capability without revisiting the fundamentals constrains what developers can do going forward, since starting again from scratch is rarely an option. Some legacy products get rebranded “next generation” with new packaging while the underlying dependencies on old technology remain untouched, fine for a while, questionable after a decade.
The clearest distinction in newer SCADA platforms is the use of object hierarchies for organising data points and metadata, rather than the flat file structures older systems rely on that limit definitions to a single point. Object hierarchies allow the fundamental data structure to expand without the bewildering customisation that befuddles even skilled programmers. If a next-generation platform lacks this, it's worth looking elsewhere.
In the past, when SCADA was effectively the only available technology, it had to be stretched well beyond its original design, loading production recipes, generating asset performance reports, even autonomously controlling entire systems, simply because there was no alternative. Today there are genuine alternatives, and it may be time for SCADA to step back into its original role: real-time operational management of critical systems, while purpose-built software handles batch management, process historian and production reporting, analytics, asset performance management, production management, manufacturing execution, and advanced process control. In short, SCADA should carry fewer business applications, not more, even though simplifying an operational SCADA system by removing functionality can feel risky. The place to start is by weighing the benefits.
Upgrading to modern SCADA brings the same benefits as adopting any modern software unconstrained by obsolete architecture, particularly relevant given the vulnerabilities baked into ageing operating systems. Isolation alone can no longer serve as the default security strategy it has for decades, so systems need to be current to detect and avoid threats while matching the skills of a modern workforce. The vendor support available for new platforms is itself a real advantage. In some cases, a straightforward evaluation leads to a decision to replace the old SCADA entirely, and for most legacy systems running over two decades, that point has simply arrived.
The instinct toward extreme caution before replacing industrial software comes from its fragility, the potential for sudden failure, and the unease that creates, reasons that, ironically, underscore the urgency of replacement rather than arguing against it. Software systems don't have independent agency; in a well-managed environment, including the OS and networks, they can be remarkably deterministic and reliable, which is part of why they've endured. Rigorous testing at inception addressed confidence and repeatability early on, but poorly structured code introduced later erodes that same confidence. We don't tolerate that kind of risk in bridges or aircraft; industrial automation has tolerated it for budget and risk-tolerance reasons alone.
Understanding how we ended up with ageing SCADA systems helps reframe SCADA as a renewable technology asset rather than a fixed one. Projects have traditionally launched with capital funding for new systems alongside new physical assets. When the physical asset keeps functioning, funding to replace the control system behind it often falls short, while individual assets get upgraded piecemeal, leaving the software largely untouched to reduce transition risk. Spread across an entire asset base, the cost of a software upgrade is relatively modest, even though replacing a single tangible asset is often perceived as lower risk than replacing software that could affect the whole system.
Systems implemented three decades ago have outlived their intended lifespan for reasons unrelated to reliability. Many run on unsupported operating systems, blocking essential updates and cyber safety improvements, and when updates are eventually forced through, they often arrive at high cost and without the usual quality control. The more pressing concern is the dwindling pool of people willing to support 30-year-old systems, particularly among engineers starting their careers, who are naturally drawn to modern technology. The window to retire these systems, while people who understand them are still in the workforce, is closing. The case for next-generation SCADA includes enhanced interoperability, object hierarchies with instantiation, unified development environments that enforce standards, room to move past legacy constraints, and software chosen for its specific purpose rather than stretched to fit everything.
A separate threat comes from the need to modify otherwise stable systems for new operational and business requirements. A mindset that resists change for the sake of stability quietly underutilises assets and erodes their value over time, and today's best practice means reassessing every constraint that limits asset performance, not assuming the current limit is the real one.
Overhauling a SCADA system gets expensive fast, especially where custom code extends well beyond standard capability. If modern SCADA doesn't readily offer a needed function, it's worth asking why, and whether consolidating previously custom-built capability into a single application would be simpler and more reliable. Vendors in this sector built their reputation on quality control, learning over time what belongs in SCADA and what belongs elsewhere. Whether the wider industry has absorbed that same lesson is a fair question, sometimes it's the user base, not the vendor, holding back the next leap forward.
Letting go of years invested in refining an operational system is genuinely hard, and the achievements built on it are real. But embracing change is the first step toward reshaping that view, even if discarding years of work in pursuit of something better feels uncomfortable. The fundamental principles, at least, remain intact. Modern development platforms give vendors more flexibility than ever, with the focus shifting toward functionality, interoperability, and performance, though a one-size-fits-all cloud solution still needs to be approached carefully, since performance, and the true cost of data, are usually the first casualties.
Once the need for action is clear, the question that follows is almost always “what's the cost of the new software,” which obscures the more significant issues underneath. The real hidden cost sits in development and lifecycle management, not the sticker price. Financing should follow the software's expected lifespan, not just the assets it manages, covering external and internal costs, support fees, internal quality spend, engineering effort, reconfiguration, documentation, and standards management.
A “set and forget” mindset for another three decades is no longer realistic, software lifecycles are shrinking as product cycles shorten and options multiply. Next-generation SCADA is already well established, and that should be reassuring to anyone used to older systems, since most of us are already comfortable updating corporate software regularly, even if that comfort hasn't always extended to the industrial systems managing critical assets, often for reasons like fear of change, timing concerns, perceived cost, a maintenance-over-replacement mindset, distrust in reliability, or simply a belief the current system works fine.
A well-managed Industrial Control System matters, and we're not suggesting hasty updates with every vendor release. Systems Lifecycle Management deserves real consideration, an ongoing process with regular, strategically planned events, not a reactive scramble after failure. Excessive caution with mission-critical systems is, at this point, the riskiest course available. We've navigated changes like this before, and the pace of change in OT systems is only accelerating. If you're still running Gen 1 SCADA, the time to act is before the knowledge to maintain it disappears. If you're already on Gen 2, the question becomes whether you're actively planning your Systems Lifecycle approach for what comes next.