This article is part of a series examining the most common pitfalls operators encounter when modernizing legacy SCADA systems in oil and gas pipeline operations.
There is a version of SCADA modernization that looks, from the outside, like a success. The new platform is installed. The go-live date is met. The screens are cleaner, the hardware is under warranty, and the IT department is satisfied. And then, over the following months, the operational team begins to notice that nothing has actually changed. The same blind spots. The same workarounds. The same frustration from controllers who expected more from a system that cost significantly more to deploy.
This is the signature outcome of treating SCADA modernization as a technology exercise rather than an operational transformation. It is the most common pitfall in SCADA upgrade projects, and it carries consequences that range from underwhelming return on investment to, in the most serious cases, direct contribution to safety incidents.
The Technology Swap Mindset
When a pipeline operator decides to modernize its SCADA system, the natural starting point is the technology itself. Which platform will replace the existing one? What hardware needs to be upgraded? How will the data be migrated? These are legitimate questions. They are also the wrong questions to lead with.
The technology swap mindset treats SCADA modernization as an infrastructure project. The goal, implicitly or explicitly, is to arrive at a state where the new system does what the old system did, on newer hardware, with vendor support still active. Scope is defined by the components being replaced. Success is defined by go-live.
What this framing misses entirely is that a SCADA system is not a piece of infrastructure. It is an operational capability. Its value is not in the hardware or the software license. It is in how that technology is configured, maintained, integrated, and operated to support the specific requirements of the people running the pipeline.
When modernization is scoped as a technology swap, the configuration logic, screen layouts, alarm structures, workflow assumptions, and data architecture of the legacy system are carried into the new platform largely unchanged. The result is a new system that behaves like the old one, carries the same inefficiencies and unresolved issues, and has consumed a capital budget without delivering meaningful operational improvement.
At first glance, a one-by-one SCADA and automation system replacement based on the original specifications might seem to be the quickest and least costly solution. However, the opportunity to improve the business case and the entire pipeline system’s value with more flexible and efficient operation and maintenance, advanced business system integration, increased safety and security, and enhanced legal compliance would be lost that way. This observation, presented at the Pipeline Technology Conference, reflects a well-documented pattern across the industry: the fastest path through a modernization project is often the path that delivers the least.
What This Pitfall Looks Like in Practice
The technology swap mindset manifests in predictable ways across SCADA modernization projects.
The most visible sign is configuration migration without re-evaluation. Rather than asking whether the existing configuration reflects current operational requirements, teams export the legacy configuration and import it into the new platform. Every threshold, every alarm, every display layout that was set at original commissioning and never formally reviewed is carried forward as though it were intentional. The new system inherits every accumulated shortcut and undocumented workaround from the old one.
A second sign is the treatment of SCADA as a standalone technology system rather than an integrated operational one. Database development work, software updates, and configuration changes are treated as routine IT activities. This creates a dangerous condition in which technical work is performed on a system that is simultaneously being used to operate live pipeline infrastructure.
A third sign is the compression or elimination of operational validation work. Factory acceptance testing, site acceptance testing, and operator training are treated as overhead rather than as core deliverables. The technology is commissioned. The operational capability is not.
Case Study: Olympic Pipe Line Company, Bellingham, Washington (1999)
On June 10, 1999, a 16-inch gasoline pipeline operated by Olympic Pipe Line Company ruptured near Whatcom Falls Park in Bellingham, Washington. About 237,000 gallons of gasoline were released into a creek. About one and a half hours after the rupture, the gasoline ignited and burned approximately one and a half miles along the creek. Two 10-year-old boys and an 18-year-old young man died as a result of the accident. Eight additional injuries were documented. A single-family residence and the city of Bellingham’s water treatment plant were severely damaged. Total property damages were estimated at at least $45 million.
The National Transportation Safety Board conducted a three-year investigation and issued its findings in report NTSB/PAR-02/02. The probable cause determination is specific and documented. Among the five contributing factors the NTSB identified, two are directly relevant to the failure mode described in this article.
The first is the SCADA finding. The NTSB cited Olympic Pipe Line Company’s practice of performing database development work on the supervisory control and data acquisition system while the system was being used to operate the pipeline, which led to the system’s becoming non-responsive at a critical time during pipeline operations. Post-incident analysis conducted by Olympic and the SCADA software vendor found no coding defect in the SCADA software itself. The system did not fail because the technology was faulty. It failed because it was being treated as a development environment while simultaneously serving as the operational control system for a live pipeline.
The second finding concerns the Bayview terminal. The NTSB cited Olympic Pipe Line Company’s failure to test, under approximate operating conditions, all safety devices associated with the Bayview products facility before activating the facility. Pressure relief valves were installed and configured during construction but were not validated under conditions that reflected actual operations. When those valves failed to perform as expected on the day of the incident, controllers had no reliable means of preventing the pressure surge that caused the rupture.
This is commissioning treated as a technology exercise. The components were installed. The system was activated. The operational validation, which would have required testing under conditions that approximated real operations, was not completed to the standard required.
The NTSB findings also identified inadequate employee training as a contributing factor throughout the investigation. Controllers operating the pipeline that day were working within the constraints of a SCADA system that had known prior performance issues, had not been fully validated at the new terminal, and became non-responsive at the moment it was needed most.
Taken together, the Bellingham investigation documents what happens when the operational integrity of a SCADA system is subordinated to the technical execution of infrastructure work. It is important to state clearly that the 1999 Bellingham incident was caused by a convergence of multiple failures over several years, and it is not accurate to reduce it to a single cause. But the SCADA findings in the NTSB report are specific, documented, and directly traceable to a pattern of treating a critical operational system as a technology tool.
The Pattern the Industry Recognizes
The Bellingham incident is an extreme and tragic example of where the technology-first mindset can lead. But the underlying pattern, treating SCADA modification and configuration work as a technical activity rather than an operational one, is documented repeatedly across the industry.
Practitioners working in pipeline SCADA consistently report the same failure modes in modernization projects that approach the work as technology replacement. Configuration is migrated without operational review. Alarm structures that accumulated over years without rationalization are carried into the new platform unchanged, creating the same alarm floods on newer hardware. Safety device testing is compressed or deferred. Operator training is scheduled as a post-go-live activity rather than as a prerequisite.
A SCADA and automation system revamp project needs systematic requirement engineering, for which the existing system with its documentation, its installation locations, its architecture, and its functionalities can only be considered as a starting point. The existing system is not the specification. It is the starting point for an analysis of what the operation actually requires.
This distinction is fundamental. An operator who begins a modernization project by documenting current configurations is doing something different from an operator who begins by documenting current operational requirements. The former is describing what the system does. The latter is describing what the system should do. Only one of those starting points produces an outcome that reflects the genuine needs of the operation.
Why Operators Fall Into This Trap
The technology swap approach is not a product of negligence. It is a product of how modernization projects are typically scoped, budgeted, and managed.
Capital projects in oil and gas are evaluated on timelines, cost estimates, and defined deliverables. A technology replacement project has clear, measurable deliverables: hardware installed, software licensed, data migrated, system commissioned. An operational transformation is harder to scope, harder to cost, and harder to defend in a capital approval process because it requires upfront investment in assessment, design review, testing, and training before a single piece of hardware is purchased.
The result is a structural tendency to scope modernization as the former and hope it delivers the results of the latter. It rarely does.
Schedule pressure compounds this. When projects run behind, the activities that get compressed first are the ones that are hardest to defend in a project management context: detailed operational requirements review, alarm rationalization, extended factory acceptance testing, and structured operator training. These activities have no tangible deliverable that appears on a project schedule. They are also the activities that determine whether the system that gets commissioned actually works as an operational tool.
The Correct Starting Point
A SCADA modernization that delivers genuine operational improvement begins with a question, not a platform selection. The question is: what do we need this system to do that our current system does not do?
Answering that question requires input from the people who operate the pipeline every day. Controllers, engineers, and maintenance technicians carry operational knowledge that no vendor proposal, project scope document, or engineering review captures. They know which configurations are deliberate and which are workarounds. They know which alarms reflect genuine operational requirements and which were set at commissioning and never reviewed. They know where the current system slows them down during incident response and where it fails to give them the information they need.
That knowledge has to be gathered, documented, and reflected in the requirements that define the new system before the technology selection is made. The existing system is a starting point for that analysis. It is not the specification.
From there, the project needs to treat operational validation with the same rigor applied to technical delivery. Factory acceptance testing should validate not just that the system functions but that it functions under conditions that reflect real operational scenarios. Safety devices need to be tested under approximate operating conditions before the system goes live. Operator training needs to be completed before go-live, not scheduled as a follow-on activity.
These are not additional steps. They are the steps that determine whether the project delivers an operational capability or an infrastructure upgrade.
Conclusion
The Bellingham investigation remains one of the most thoroughly documented cases of SCADA system failure in the pipeline industry. The NTSB findings are specific: database development work performed on a live operational system caused that system to become non-responsive at a critical moment. Post-incident testing confirmed the software itself was not defective. The failure was operational, not technical. Safety devices commissioned at a new terminal were not tested under operating conditions before the terminal was activated. The NTSB findings identified inadequate employee training as a contributing factor throughout.
These were not the result of negligence. They were the result of a consistent pattern of treating a SCADA system as a technology asset rather than an operational one.
That pattern is not unique to 1999. It is present in modernization projects today, in organizations that would never describe themselves as taking that approach. The language of technology replacement, platform migration, and system upgrade shapes how projects are scoped, budgeted, and executed in ways that consistently subordinate operational requirements to technical deliverables.
The starting point for any SCADA modernization is not the technology. It is the operation the technology is meant to serve.
PipeCom is a certified SCADA systems integrator serving pipeline operators across Canada, the United States, and Latin America. For more insights on SCADA integration and operational technology, visit pipecom.com.