“Why are we replacing everything when only the servers have reached end of life?”
That question stopped a project meeting I attended several years ago.
The plant was meeting production targets. The control applications were stable, operators knew the HMI, and there was no reliability crisis driving urgent change. The immediate problem was much narrower: the compute platform was nearing the end of vendor support.
Yet the proposed response had become a full DCS replacement, with new controllers, engineering tools, operator graphics, testing, training and almost two years of project work.
Nobody in the room believed every part of the system had reached the end of its useful life. They had simply accepted that changing one layer meant changing the rest.
That assumption has shaped industrial automation for decades. I have seen infrastructure worth a few hundred thousand dollars trigger programmes costing $20 million to $50 million once application migration, engineering labour, factory acceptance testing, commissioning, shutdown planning and production risk were included.
The hardware was a rounding error. The cost lived in every dependency around it.
Once an application is tied to a particular runtime, the runtime depends on a specific compute platform, and the engineering environment follows one supplier’s lifecycle, a routine refresh becomes difficult to contain. Each change pulls on the next until a server replacement turns into a plant-wide migration.
Many organisations now treat this as a normal part of control-system ownership. It is largely the result of architectures that force unrelated parts of the system to share the same lifecycle.
A simple exercise makes the problem visible.
Choose one critical application and ask:
If the compute platform supporting this application had to be replaced next year, what else would have to change?
Write down every dependency in the answer: application modifications, supplier services, engineering tools, licence transfers, factory acceptance testing, operator training and shutdown requirements.
That list tells you where flexibility has been lost. It also shows where future projects are likely to consume time and capital without adding new operational capability.
This is where open architecture changes the modernisation model.
O-PAS supports clearer separation between applications, runtimes and infrastructure so that each layer can evolve on a more appropriate lifecycle. The value comes from reducing the number of changes that must travel together.
Infrastructure can be refreshed when it reaches the end of support. Applications can be improved when operations need new capability. Engineering tools can evolve without automatically forcing a wider migration.
The operational difference is straightforward. A compute platform reaches end of life, the replacement is completed during a planned maintenance window, the environment is validated, and the applications return to service before Monday morning. Operators come back to the same control strategies, graphics and procedures because those elements did not need to change.
Six months later, the plant adds advanced control to improve throughput. That work proceeds as a focused improvement project rather than as another consequence of hardware obsolescence.
Over time, the plant still modernises, but it does so through measured changes instead of recurring replacement programmes. Each project addresses the problem that actually exists, and each successful step removes another dependency from the next one.
The strongest modernisation programmes will come from plants that make routine lifecycle events routine again. They will preserve engineering effort for changes that improve safety, reliability and production rather than spending it repeatedly on escaping old dependencies.
Which dependency in your current architecture would create the most value if you removed it during your next planned upgrade?
For a practical introduction to incremental modernisation, application portability and lifecycle independence, visit OPAcommunity.com.