Walk into any E&P shop that grew through acquisition and ask the production engineers how many browser tabs they have open. The answer is rarely fewer than six. One per SCADA platform, one per historian, one for the in-house dashboard somebody built to make sense of the other ones. The team has learned to live with it. Most of them don’t realize there is another way.
Every deal you close comes with somebody else’s SCADA stack. After enough deals you don’t have a SCADA strategy. You have an archaeological record.
The natural shape of the problem
Vendor sprawl is not a technology failure. It is the predictable result of how upstream growth works.
A company picks up producing assets. Each asset was operated by somebody before, and that somebody picked their own SCADA vendor. Maybe a former operator on the deal used Ignition with a particular automation contractor. Maybe the legacy wells came with Totalflow or older RTU platforms that nobody has touched in fifteen years. Maybe the cloud-era assets were on whichever SaaS telemetry tool the prior operator’s pumper preferred. Maybe a corner of the portfolio still has OSI PI (or AVEVA PI now) because it came from a larger operator’s divestiture.
None of that was a mistake at the time. Each choice was reasonable for the asset and the operator who made it. The problem is that you, today, own all of them at once.
By the time the portfolio crosses a few basins, the platform count is usually well into the double digits. There is no common tag namespace. There is no consistent polling frequency. There is no shared concept of asset hierarchy across the systems. The well that everyone in the office refers to by its lease name shows up under three or four different identifiers depending on which screen you are looking at.
This is not unusual. This is the normal state of a growing operator.
The cost isn’t where you think it is
Most companies measuring the cost of vendor sprawl reach for the license fees. That is the visible number. It is also the smallest one.
The real cost lives in three places, and none of them shows up on an invoice.
Engineering time lost to context switching. A production engineer who needs to investigate a deferred well across the portfolio has to log into a different system, learn its quirks, find the right tag, export the data, and reformat it before they can even start the actual work. Multiply that by every engineer doing it every day. The hours are not small.
Analytics you cannot run. Cross-asset benchmarking. Portfolio-level anomaly detection. Comparative artificial lift performance across basins. None of these are technically hard. They are blocked by the fact that the underlying data is not normalized. The teams who could do this work spend their time wrangling instead.
Integrations you have to rebuild every time. Add a new tool to the stack, whether it’s a production accounting system, an allocation engine, or a surveillance platform, and you get to write the connector for every SCADA system you own. Not once. Every time. The marginal cost of the next acquisition includes this work, and nobody puts it on the deal model.
A separate, harder-to-measure cost is what doesn’t happen at all. The surveillance program that gets scoped down because the data isn’t ready. The autonomous optimization project that stays in pilot because it can’t reach the wells outside the original Ignition footprint. The benchmarking exercise that gets shelved because tying tag names to wells across vendors is its own project. These don’t show up as line items. They show up as initiatives that quietly disappear.
Replacing the SCADA vendors is not the answer
Every operator we talk to has had at least one conversation about consolidating onto a single SCADA platform. Some have started the project. Almost none have finished it. The math doesn’t work for legacy assets, and the disruption is not worth it for assets that already work.
The right move is almost always to leave the SCADA layer alone and build a data abstraction layer above it.
The shape of the layer is well understood. A common destination (a warehouse or lake, depending on your stack). A normalized model on top of the raw ingested data. An asset hierarchy that lives in one place and is the source of truth, not whichever SCADA vendor you happened to acquire first. A tag dictionary that maps every vendor’s naming convention to the same semantic concept.
Modern assets feeding this layer through MQTT and Sparkplug B where the equipment supports it. Legacy assets feeding it through API extraction, file export, or vendor-specific connectors where they don’t. The point is that the destination is the same and the model on top of the data is the same, regardless of where it came from.
This is the same pattern that makes data lake centralization actually work in practice. You don’t centralize by replacing the source systems. You centralize the layer above them, where the consumers actually live.
Where the hard work actually is
The ingestion is the easy part. We say this often and it remains true. Most of the SCADA vendors in the wild have some form of API or export mechanism, and the tools to pull data out of them are mature.
The hard work is two things, and they are both unglamorous.
Tag normalization. A tubing pressure tag from one Ignition instance, a differently named tag from a SaaS vendor, and a third name from a Cirrus Link bridge can all refer to the same physical measurement on the same physical well. Resolving that mapping, keeping it current as new wells come online, and surfacing it in a way the downstream consumer can rely on is the work that makes everything else possible. dbt is the right place to do this at scale, because the mapping logic is versionable, testable, and documented in a way that survives team turnover. We covered the broader case for PPDM as the model on top of this, and the tag-to-well mapping is one of the places where the discipline pays off most.
Asset contextualization. Tags belong to wells. Wells belong to pads. Pads belong to fields. Fields belong to basins. This hierarchy lives in your land system, your production database, and (theoretically) your well master. None of those agree with each other on the first try. The work of getting them to agree is what makes cross-asset analysis possible at all. We wrote about this specifically for reconciling land and production data, and the same patterns apply to operational data.
These are not technology problems. They are domain problems. They get easier the more time you spend with the data and the people who know it, and they don’t get any easier by buying a different tool.
What the unlock actually looks like
It is worth being concrete about what becomes possible once the data abstraction layer is in place, because the abstract pitch (“unified data”) doesn’t move anyone.
A production engineer can rank every well in the portfolio by deferral, or by performance against type curve, or by whatever metric matters this week. In one query. Across every vendor. Without a data engineering ticket.
An allocation analyst can compare reported volumes against SCADA-derived volumes for any well in the portfolio without first asking three different SCADA admins for export files.
The autonomous workflows everyone is trying to deploy (predictive failure detection, optimization, automated dispatch) have one feed to pull from instead of N. The same point that Jeff made about the data foundation that makes autonomy work better applies here: the algorithms aren’t the constraint. The data is.
A new acquisition gets integrated in weeks, not quarters, because the only new work is plugging the new SCADA system into the existing abstraction layer. The downstream consumers don’t know or care that a new vendor showed up.
None of this requires the SCADA vendors to consolidate. It requires that the layer above them be deliberate.
The question worth asking
Most VPs of engineering and operations leaders we talk to know they have vendor sprawl. The question is whether it’s worth doing anything about right now.
The right question is not whether your SCADA data is accessible. Most of it is, somewhere. The right question is whether it is accessible in one place, in a common format, in a way your engineers can actually use without a data engineering degree.
If the answer is no, the cost is the work that isn’t getting done. That cost compounds with every acquisition. The longer you wait, the bigger the abstraction layer has to be when you finally build it.
The teams that win this don’t start by trying to fix everything. They pick the cleanest vendor in the portfolio, prove the abstraction pattern on that subset, and then onboard the harder vendors over the next two or three quarters. The first working pipeline buys you the credibility to expand.
The browser tabs aren’t going to close themselves.
Further Reading
- Your SCADA Data Is Already in Snowflake. That Doesn’t Mean It’s Reliable.
- Bringing SCADA Data Into Your Data Warehouse Without Breaking Either
- What the PPDM Model Actually Gives You (and What It Doesn’t)
- Stop Centralizing Everything: Your Data Lake Is Not a Strategy
- The Data Foundation That Makes Autonomy Work Better
- Reconciling Land and Production Data: Why It’s the Hardest Problem in Upstream Data