What a SCADA Upgrade Really Costs
The Quote That Hides the Real Number
A control system vendor sends a proposal to replace an ageing SCADA or DCS. The headline is the software and hardware, and it looks like a capital line a board can understand. Then the project starts, and the real costs arrive: every tag has to be remapped, every driver to every PLC and instrument has to be rebuilt or replaced, every graphic has to be rebuilt and tested, and the plant has to come down for the cutover. The licence was the small part.
This is the pattern across Australian plant, utility and resources operations with control systems that are ten, fifteen or twenty years past commissioning. The system still runs. The problem is that the vendor has ended support, the hardware is out of production, the engineers who understood it have retired, and one failed card now means a scramble on an auction site for a spare. Obsolescence is not a single event. It is a slow rise in the cost and risk of keeping the plant running, until a forced upgrade on the vendor's timetable costs far more than a planned one would have.
This article is for the plant managers, engineering managers and the finance and executive teams who have to decide when and how to fund a control system upgrade. Having worked on industrial control and data platforms for BHP, Rio Tinto and Senex Energy while employed by previous consulting and engineering firms, across an 18 year career in operational technology, I have seen the same thing repeatedly: the upgrade that was deferred because the quote looked expensive ended up costing more, because it happened in a crisis instead of on a plan.
Why Obsolescence Is a Cost, Not an Event
The instinct is to treat a working control system as a solved problem. It runs the plant, so why spend money on it. The cost of obsolescence is invisible until it is not, and by then the business has lost the ability to plan the spend.
An unsupported system carries a running cost in several forms at once. Spare parts move from a catalogue to a grey market, and prices rise as stock dwindles. The knowledge needed to maintain it concentrates in fewer and fewer people, and each one who leaves raises the risk. Security exposure grows, because an unsupported system stops receiving patches, which matters enormously for anything that falls under the Security of Critical Infrastructure Act 2018. And the system becomes a wall: new instruments, new analytics and new reporting cannot be added because nothing modern can talk to it.
Planned Upgrade vs Forced Upgrade
| Metric | Deferred until failure | Planned on a lifecycle | Improvement |
|---|---|---|---|
| Timing | Set by a card failure or a vendor cut-off | Set by the business, during a planned outage | Controlled |
| Spares | Grey-market prices, no guarantee of supply | Sourced and staged before cutover | Secured |
| Downtime | Unplanned, during peak if unlucky | Scheduled into a shutdown window | Minimised |
| Data foundation | Carried over as-is, problems and all | Rebuilt clean as part of the project | Improved |
The point of naming these costs is that they let you compare the real alternatives. The honest comparison is not upgrade now versus spend nothing. It is a planned upgrade now versus a rising maintenance and risk bill followed by a forced upgrade later, on worse terms. Once a board sees the second number, the first one stops looking expensive.
Where the Money Actually Goes
The single biggest misconception about a control system upgrade is that the software and hardware are the cost. On most projects they are a minority of the total. The money goes into the work of migration, and that work is driven by the size and state of the existing system.
Tags are the unit that matters. A plant with tens of thousands of tags has tens of thousands of points that must be identified, mapped, reconfigured and tested in the new system. Drivers and communications to every PLC, instrument, analyser and third-party system have to be rebuilt, and each non-standard or legacy device is its own small project. Graphics and HMI screens have to be rebuilt and, critically, re-tested against the live process so an operator is not fighting an unfamiliar interface during a start-up. Alarms have to be carried across, and an obsolescence upgrade is the ideal moment to rationalise them rather than copy a bad alarm system into a new one.
Where a Control System Upgrade Spends
Then there is downtime, which is often the largest single number and the one most sensitive to planning. A cutover done into an existing shutdown window costs the plant nothing in lost production. The same cutover forced by a failure, outside a planned outage, is priced at the plant's full production rate for every hour it is down. The difference between a planned and an unplanned upgrade is, in large part, this one line.
Scoping It Honestly
A credible upgrade project starts with a scope that counts the real drivers rather than accepting a vendor's platform quote. That means an audit of the existing system: a full tag count, an inventory of every driver and interface, a review of the graphics and alarm configuration, and an honest assessment of what documentation survives and what has to be reverse engineered from the running system.
That audit is also where the most common nasty surprises hide. Undocumented logic in a PLC. A third-party interface nobody remembers building. A safety system that is entangled with the control system and has to be handled with far more care. Finding these before the project is quoted is the difference between a fixed, defensible number and a project that doubles once it is underway. This is the same discipline we apply to connecting modern systems to legacy infrastructure without a rip and replace: you survey what is really there before you commit to a design.
How Urgent Is Your Obsolescence Risk?
The audit output is the business case. It turns a vague "the system is old" into a costed list: this many tags, this many drivers, this much graphics work, this much downtime, against this rising maintenance and risk bill if nothing is done. A board can decide on that. It cannot decide on a feeling that the plant is getting old.
The Security and Compliance Dimension
For a growing number of Australian operations, deferring a control system upgrade is no longer only a maintenance decision. If your plant is a responsible entity under the Security of Critical Infrastructure Act 2018, you carry obligations to manage risk to that system, including a Critical Infrastructure Risk Management Program where the rules apply to your sector. An unsupported, unpatchable control system is difficult to defend against those obligations.
Control system security is itself a discipline with its own standard, the ISA/IEC 62443 series, which covers the security of industrial automation and control systems. An obsolescence upgrade is the practical moment to bring a plant toward that standard: to segment the control network properly, to remove the flat architecture where the business network and the plant floor share a cable, and to put in place the monitoring that an unsupported system cannot support. We go deeper on the obligations in our guide to the SOCI Act, CIRMP and AI on critical infrastructure. The upgrade is expensive. A security incident on an unsupported control system, in a regulated sector, is a different order of expensive.
The Opportunity Inside the Upgrade
Here is the part that changes the economics, and the part a vendor replacing like-for-like will not tell you. A control system upgrade is the once-in-fifteen-years moment when every tag, every interface and every piece of data in the plant is already on the table being reconfigured. It is the cheapest time you will ever have to fix the data foundation, because the migration work is happening anyway.
A like-for-like upgrade carries every existing problem into the new system: the same bad tag naming, the same trapped historian data, the same inability to report without a manual scramble. An upgrade scoped with the data in mind rebuilds the foundation so that, once the new system is live, the plant's data is genuinely usable. That is the difference between spending a large sum to stand still and spending a slightly larger sum to unlock everything that comes after.
An Obsolescence Upgrade That Also Fixes the Data
Once the foundation is clean, the things that were impossible on the old system become straightforward. Historian data that was locked away can be reported on in Power BI without building a second historian. Analytics and AI become viable, because the data arriving is reliable by design rather than reconstructed by hand. This is the argument we make in full in our piece on why agentic AI needs a real data foundation: the model is never the hard part, the data underneath it is, and an obsolescence upgrade is your best chance to build that data right.
Planned Upgrade vs Running to Failure
Choosing the Path: Like-for-Like, Re-platform or Phase
Once the audit is done, three broad paths present themselves, and the right one depends on the state of your plant rather than on a vendor's preference. A like-for-like replacement, staying with the same vendor's current generation, is the lowest-engineering option and the easiest to justify when the existing system is well understood and well documented. Its weakness is that it tends to carry old problems forward, and it locks you further into one vendor's licensing and roadmap.
A re-platform, moving to a different or more open architecture, costs more up front in design and testing but buys you independence and a clean data model. It makes most sense when the existing system is poorly documented anyway, so you are reverse engineering regardless, or when the business wants to break a vendor dependency that has become a commercial problem.
A phased approach, upgrading the system area by area across several outages, suits large or continuous plants that cannot take a single long shutdown. It is more expensive in total because you run two systems in parallel for a period, but it removes the big-bang risk of cutting over an entire plant at once. Whichever path you take, two rules hold. Keep the safety instrumented system separate and treat it with its own rigour, never entangled with a convenience upgrade. And test the new configuration against the live process before cutover, because an operator meeting an unfamiliar graphic during a start-up is where good upgrades turn into incidents.
Getting the Decision to the Board
The reason good upgrades get deferred is that they are presented as an IT or engineering cost, and compared against doing nothing. Framed that way, doing nothing always wins until the day it catastrophically loses. The job is to present the real comparison: a planned, scoped upgrade against a rising maintenance bill, a growing security and compliance exposure, and a forced upgrade later on worse terms.
That is a risk and continuity conversation, and it belongs at board level, not buried in a maintenance budget. We set out how to have that conversation in our guide to AI advisory for Australian boards. The ongoing support side, keeping a plant system healthy and improving rather than just reacting to failures, is covered in our piece on what a plant system support arrangement should actually cover. Projects of this kind fail more often from scoping and sequencing than from technology, a pattern we examine in why industrial analytics projects fail.
How to Start
You start with the audit, not the vendor quote. Count the tags, inventory the drivers, review the graphics and alarms, and assess the risk you are carrying today. That document tells you how urgent your obsolescence really is, what a credible upgrade would cost, and what rising bill you are paying to defer it. It also tells you whether the upgrade can double as the moment you fix the data foundation.
Solve8 works with Australian plant, utility and resources operations to scope control system obsolescence honestly, count the real cost drivers, and design an upgrade that fixes the data foundation rather than carrying old problems into new software. If your control system is past its supported life and the vendor quote only tells you half the story, the next step is a scoping conversation about what your plant actually needs. You can see how we approach AI consulting and operational technology work across asset-heavy Australian operations, or get in touch to scope your control system risk.