Every refinery has them. Control systems installed during a previous decade, historians running on hardware that hasn't been manufactured in years, SCADA platforms tied to proprietary protocols, and process data siloed behind interfaces that predate the modern web. The question of what to do with these systems is one of the most consequential, and consistently misframed, decisions in downstream industrial operations.
The dominant instinct in technology circles is to advocate for replacement. Rip out the old, put in the new, start fresh. The dominant instinct inside refineries is the opposite: leave what's working alone, because the cost and risk of touching live systems are too high. Both instincts are understandable. Both lead to bad outcomes when applied without nuance.
The better question isn't "replace or integrate?" It's this: what does this system do, what does it connect to, and what does a failure cost?
Why Blanket Replacement Is Usually the Wrong Answer
Legacy process control systems, DCS, SCADA, historians, are not like enterprise software. You don't swap a DCS the way you swap an ERP. These systems are deeply embedded in process control, often tied to physical instrumentation, and frequently the last line of defense between normal operations and an unplanned shutdown.
The uptime expectations in a refinery environment are not compatible with the risks of wholesale replacement. A refinery that processes hundreds of thousands of barrels per day cannot absorb the learning curve, commissioning risk, and integration complexity that comes with replacing a DCS during a normal operating window. Even well-planned replacements carry the potential for process interruption that no technology benefit justifies outside of a major scheduled turnaround.
There's also the institutional knowledge problem. Legacy systems accumulate years of configuration tuning, alarm rationalization, and control logic that reflects hard-learned process behavior. That knowledge doesn't automatically transfer to a new system. Some of it gets lost in translation. Some of it nobody documents until it's gone.
Why Leaving Legacy Systems Completely Untouched Is Also Wrong
The counterargument, "if it's not broken, don't touch it," treats operational stability and operational visibility as the same thing. They're not.
A DCS that reliably controls your process but can't share data with your maintenance management system, your planning layer, or your reporting infrastructure isn't fully operational. It's isolated. You're running a refinery where the people making decisions about reliability, throughput, and asset life don't have access to the data being generated by the systems controlling those outcomes.
The cost of that isolation compounds over time. It shows up in reactive maintenance patterns because nobody could see the early indicators. It shows up in manual data entry because the historian doesn't connect to the analytics layer. It shows up in audit findings because process data lives in a system nobody can query without specialized vendor support.
A Framework for the Decision
The replace-versus-integrate question is better answered by working through four things:
1. Is this system doing what it's supposed to do?
If a control system is functioning correctly and its failure risk is low, the case for replacement is weak regardless of how old it is. Stability has value. The burden of proof for replacement should be high.
2. What is the cost of its isolation?
If the system controls the process reliably but produces data that can't be accessed, shared, or analyzed without manual extraction, the problem isn't the system itself. It's the lack of an integration layer. That's a different, and usually more tractable, problem than full replacement.
3. What does failure look like?
Systems that are aging into reliability risk, where hardware obsolescence, vendor support gaps, or component availability are creating genuine failure probability, have a different calculus than systems that are simply old. For those, a planned replacement during a scheduled turnaround with a proper migration strategy is often the right answer. Waiting for an unplanned failure is the most expensive version of replacement there is.
4. Can modern integration solve the problem without replacement?
In many cases, the answer is yes. Modern integration approaches, including middleware layers, edge data collection, historian APIs, and purpose-built connectivity tools, can bridge legacy systems to modern analytics, reporting, and operational platforms without touching the control layer. The refinery gets the data visibility it needs without the risk of modifying systems that are working.
The Case for Integration-First
For most refineries, the practical path is integration-first with selective replacement driven by risk. In practice, this means:
- Building an integration layer that aggregates data from legacy systems into a unified operational data platform
- Preserving existing control infrastructure while unlocking the data it produces
- Replacing specific systems when reliability risk, vendor support gaps, or major capability requirements make a compelling case, and timing those replacements to planned shutdowns
- Treating the integration layer as the long-term asset, not any individual system it connects
This approach reduces risk, produces faster value, and builds toward a modern data architecture without betting the facility on a single large-scale replacement program.
What This Requires from Leadership
The integration-first strategy requires something that replacement programs don't: sustained commitment to incremental progress. It's harder to build a business case for "we're going to connect twelve systems over eighteen months" than for "we're replacing the DCS." The benefits are real, but they distribute over time rather than arriving at a ribbon-cutting.
It also requires honesty about which systems are genuinely stable and which are on borrowed time. The most common failure mode in this strategy is treating a system that needs to be replaced as one that just needs to be integrated, because replacement is too hard to plan for. That's a risk management failure dressed up as pragmatism.
The refineries that manage this well treat their technology infrastructure the way they treat their asset maintenance programs: with a clear inventory, honest condition assessments, and a plan that distinguishes between what needs attention now and what can wait.