Why a running plant plans its next platform before it has to, and how to make the move without betting the plant on it.
Nobody replaces a SCADA system because they want to. The application works, the operators trust it, and the plant runs on it every shift. So the decision to evolve it usually arrives from outside: a support renewal priced like a new purchase, an upgrade that needs an operating system the plant cannot run, a security review that will not pass, or the one engineer who understood the scripts retiring next spring.
When it arrives that way, it arrives late, and a late decision is an expensive one. The case for planning it early is not about technology. It is about who controls the timing.
What the plant already owns
Start with what is not at risk. Tags, PLC addressing, alarm limits and history settings are structured records. They are the real engineering in the application, the part that took years to get right, and structure survives a move. In the de-identified water treatment application we use as an example, reading the application back counted 126 operator windows, 7,553 tags, 614 alarms and 556 historized points, and every one of them was accounted for afterwards.
Screens are different. They are rebuilt, not copied, and anyone who tells you otherwise is describing a picture of a display. The good news is that a rebuild done on a plant model rather than a flat tag list comes out smaller: in that same example, eight equipment templates carry 6,800 of the 7,553 tags. One fix to a pump template reaches every pump.
Where the return comes from
I am not going to print a return figure for your plant, because I have not seen your plant. But you can build the case yourself from four costs you already know:
- The cost of staying. What the current platform will charge to stay current over the next five years: renewals, upgrades, and the operating systems and hardware it will require.
- The cost of the people. How many hours your team spends each year working around the platform rather than improving the process. Ask them; they know.
- The cost of the next change. What it costs today to add a line, a site or a web client. On a modeled application that is an instance of a template. On a flat one it is a project.
- The cost of being late. What happens if the forcing event arrives before the plan: an unplanned outage, a failed audit, a rushed migration at the worst possible price.
Put those four side by side with a fixed migration price and the case usually makes itself, or it does not, and then you have learned that cheaply.
Security is a reason, not a feature
Plants are being asked harder questions about their control systems every year, and a platform built before those questions existed answers them badly. The questions to ask of any platform are architectural: does it run on a currently supported runtime and operating system, can it be patched without stopping production, can it run with no internet connection at all, and if it uses AI, can that model be one you host inside your own network so plant data never leaves the site. FrameworX is built on current .NET and runs on Windows and Linux, and its AI tools work with a model the customer hosts. Check each claim against the documentation, ours included.
Choose for the next fifteen years
A plant lives on its platform for ten to fifteen years. The engineers who choose it will mostly have moved on by the end. So the useful test is not which platform was a good choice, but which one will still be the right one when today’s team has retired. I wrote six questions for that test in the companion article, The Business Case for Evolving a Legacy HMI and SCADA Application (https://tatsoft.com/business-case-for-evolving-a-legacy-hmi-and-scada/); the short version is to ask how the logic runs, which language your engineers will be hiring for, whether one design environment reaches the control room, the browser and the phone, and whether you can get your application back out in an open form.
Make the move without betting the plant
The reason most migrations stall is risk: nobody wants to sign a project they cannot size. So we changed the order. You send a read-only copy of the application, from any platform, and we read it back to you object by object before anyone quotes anything. If you go ahead, the migration is a fixed price quoted from that report. And if you don’t accept the result, you don’t use it and you don’t pay for the migration.
On 15 October we rebuild a legacy application live, in one hour. Watch the film first: https://youtu.be/VSTt4nkqK1s. Then send us yours: https://tatsoft.com/migrate-to-frameworx/
Aim High. Start Simple. Scale Without Limits.
Author Bio: Marc Taccolini brings three decades of industrial software experience as designer of Tatsoft FrameworX and previously InduSoft (now AVEVA Edge).