SCADA vs OPC vs IoT Platform vs Data Historian (2026)

If you are weighing SCADA vs IoT platform vs data historian as a single buying decision, you are framing the question wrong — and that framing is what wastes the average industrial-modernization budget by 30 to 60 percent. These four categories solve four different problems. SCADA supervises and controls a running process. OPC standardizes how anything else talks to that process. An IoT platform contextualizes data into asset models and feeds enterprise analytics. A data historian compresses decades of engineering signals at fidelity that neither SCADA nor a typical cloud store can match. The 2026 question is not “which one wins.” It is “which layer in my stack needs which tool, what does each cost to run, and where do the responsibilities cleanly hand off.” This article gives you a side-by-side decision matrix, five reference diagrams, and the migration patterns we see working in real brownfield plants.

Why the four categories exist (different problems, not the same problem)

The four categories exist because no single system optimizes for control, interoperability, contextualization, and long-term retention at the same time. Trying to collapse them produces brittle, expensive stacks that miss in every dimension.

Control software is hard real-time. Operators expect a tag value to change on a screen within 250 milliseconds of the field event, and they expect an alarm to acknowledge in under a second even when the WAN is down. That hard-determinism budget is incompatible with cloud round-trips. SCADA — and the PLC layer below it — owns this requirement and is not going anywhere.

Interoperability is a different problem. A modern plant has Siemens S7, Allen-Bradley CIP, Modbus, BACnet, IO-Link, and proprietary drives. Without a standard surface, every consumer needs its own driver matrix. OPC — first Classic DA/HDA/AE, now overwhelmingly OPC UA with PubSub — is that standard surface. It does not store, supervise, or analyze. It translates and exposes.

Contextualization is what an IoT platform does. A raw tag named B07_TMP01 means nothing to a reliability engineer. The same value, mapped under SiteA / Boiler-07 / Economizer / Inlet-Temp with units, asset class, and parent hierarchy, is queryable across a fleet. Platforms like AWS IoT SiteWise and Azure IoT Operations build that ISA-95 hierarchy and expose it to dashboards, ML, and mobile apps.

Long-term retention is what historians do. A PI System tag with rotating compression can hold 30 years of millisecond-resolution data in a footprint a generic columnar database cannot match, with engineering-aware interpolation, summaries, and analytics built in. Historians are about fidelity over decades, not about real-time control.

Once you internalize that these are four problems, the architecture question stops being “pick one” and becomes “compose the right layers.”

SCADA — what it is and what it isn’t

SCADA (Supervisory Control And Data Acquisition) is the real-time supervisory software layer between PLCs and human operators. Its job is to acquire tag values, render them on graphical mimics, evaluate alarms, accept operator commands, and journal short-term events. It is not, despite what some cloud marketing implies, “legacy” — it remains the only safe place to run sub-second supervisory loops.

A canonical SCADA system has five blocks: protocol drivers (Modbus TCP, EtherNet/IP, S7, embedded OPC UA), a tag database and polling engine, an alarm and event engine, a short-term trending buffer, and HMI screens. Inductive Automation Ignition, AVEVA System Platform (formerly Wonderware), and Siemens WinCC are the dominant commercial stacks; Rockwell FactoryTalk View and GE iFIX cover much of North American discrete manufacturing.

What SCADA does well — and other categories do poorly — is deterministic supervision. Polling cycles run at 100 to 1000 milliseconds. Alarms latch and route to operator stations on local LANs that survive cloud outages. Operator commands are journaled with user, time, and value. An IoT platform asking “did anyone start pump 3 this morning?” cannot answer authoritatively; SCADA can.

What SCADA does poorly is long-horizon analytics and multi-site context. The trending buffer is hours, not years. The tag database is flat — there is no native concept of an asset hierarchy that survives across sites. There is no MQTT broker, no Kubernetes-native deployment, and no first-class mobile experience. That is why every serious 2026 architecture pairs SCADA with at least one of the other three categories.

Common mistake: trying to use the SCADA’s trend log as a historian. Trend logs are circular buffers tuned for screen rendering, not for engineering analytics. After a year, you cannot reconstruct an event timeline reliably.

OPC — protocol/middleware layer

OPC is not a system. It is a family of specifications maintained by the OPC Foundation that standardize how heterogeneous industrial devices and applications exchange data. If SCADA is the supervisor, OPC is the wiring diagram that lets everything else read from the supervisor’s tag database — or directly from the PLCs.

OPC Classic — DA (Data Access), HDA (Historical Data Access), AE (Alarms & Events) — runs over DCOM and is still the install base in many older sites. OPC UA, released formally in 2008 and steadily extended through 2026, replaces COM with platform-neutral TCP and HTTPS, adds a rich information model, and supports PubSub over MQTT and UADP. OPC UA over MQTT — including via Sparkplug B — is what most greenfield 2026 architectures default to.

The two things people confuse: OPC UA is a protocol plus information model, not a product. You consume it through an OPC UA server (sometimes called a tunneler or aggregator). Kepware KEPServerEX, Matrikon FLEX, Software Toolbox TOP Server, and Ignition’s built-in OPC UA module are common implementations.

OPC UA’s information model is what makes it more than just a protocol. You can model an asset with nested folders, typed variables, methods, and references — close to an object-oriented schema. Companion specifications layer industry-specific semantics on top: OPC UA for Machinery, for Robotics, for Pumps. This is what gives OPC UA a foot in the IoT-platform world: the same model that exposes tags also exposes structure.

A common misconception: an OPC server replaces a SCADA. It does not. The OPC server exposes data but does nothing about supervision, alarms, or operator action. If you remove the SCADA and just leave OPC, you have a wire, not a system.

IoT platforms — cloud-anchored, contemporary

An IoT platform is a cloud-anchored (or hybrid) software stack that ingests industrial data at scale, contextualizes it into an asset model, persists it across tiers, and exposes it to applications: dashboards, ML, twins, mobile, and ERP integration. Where SCADA is screen-centric and historian-centric is signal-centric, an IoT platform is asset-centric.

The reference platforms in 2026: AWS IoT SiteWise (with the new asset-modeled twin builder), Azure IoT Operations (the successor to Azure IoT Hub for industrial), Siemens Insights Hub (formerly MindSphere), PTC ThingWorx, GE Proficy Plant Applications, Cognite Data Fusion, and a long tail of open-source-anchored stacks built on EMQX, Apache Pulsar, TimescaleDB or InfluxDB, and Grafana.

A platform typically has five tiers. The edge runs a gateway (often a Kubernetes node or a hardened embedded device) with OPC UA and MQTT clients, store-and-forward buffering, and edge compute for filtering, aggregation, and inference. Ingest is a broker — MQTT 5 or Kafka — with schema validation (Sparkplug B is the de facto standard) and a rules engine. Storage is tiered: hot time-series, warm Parquet, cold object storage. Modeling holds the ISA-95 hierarchy and live twin state. Applications consume from both raw history and the twin.

The platform’s strength is breadth: dashboards across sites, ML on aggregated data, mobile reach, low-friction integration with SaaS analytics. Its weakness is determinism — cloud-routed commands are not safe for sub-second control. Its second weakness is cost at scale. Cloud egress and ingest pricing for one million tags at one-second cadence runs into six and seven figures annually if you are careless about edge-side aggregation.

A platform is most valuable when you have multi-site data, want enterprise-wide analytics, or need to expose a twin to non-OT consumers (planners, executives, ML engineers). It is least valuable as a replacement for SCADA or as the sole long-term store of high-cadence engineering data.

Data historians — time-series with engineering features

A data historian is a purpose-built time-series database with engineering-specific features: rotating compression, deadband filtering, interpolation, summaries, and a tag model that supports decades of high-cadence data. AVEVA PI System is the long-time market leader; Aspen IP.21, Honeywell Uniformance PHD, Inductive Automation Tag Historian, eDNA, GE Proficy Historian, and Canary Labs fill the rest of the install base.

What separates a historian from a generic time-series store like InfluxDB or TimescaleDB is engineering pedigree. PI’s swinging-door compression algorithm preserves significant inflection points while discarding statistically uninteresting points — a 100-millisecond stream of a stable temperature compresses to a handful of values per hour without losing event detail. PI’s calculation engine (Asset Framework analyses, formerly Performance Equations) lets engineers define derived tags (flow integrals, efficiencies, KPIs) that recompute automatically as upstream data lands.

Historians are also tag-model-aware. PI’s Asset Framework provides hierarchy, templates, and event frames. eDNA’s services do the same in a slightly different shape. A historian queried by an engineer is fast and intuitive in ways a generic time-series store rarely is.

What historians do poorly is breadth. They are usually single-vendor licensed software, deployed on-premises, with limited native cloud-elasticity. They are not where you build a global multi-tenant SaaS analytics product. Their licensing is by tag, by feature, or by core — often a six-figure annual line item for a mid-size plant.

The 2026 trend is hybrid: keep the historian for the deep engineering history that survives audits, regulatory compliance, and ten-year reliability investigations; route a copy of the same data into an IoT platform’s tiered storage for fleet analytics and ML. PI’s Cloud Connect and similar features explicitly bridge to AWS, Azure, and Snowflake.

Side-by-side comparison

The table below summarizes how the four categories compare across ten engineering criteria. Treat it as a layered architecture cheat sheet, not a leaderboard.

Criterion	SCADA	OPC (UA / Classic)	IoT Platform	Data Historian
Primary purpose	Real-time supervisory control plus HMI	Protocol standardization and middleware	Cloud asset modeling, analytics, twin	Long-term high-fidelity time-series storage
Where it runs	On-premises plant LAN	On-premises or edge (server software)	Cloud anchored, edge agents	On-premises (cloud hybrid common)
Data model	Flat tag database	Information model (OPC UA address space)	Hierarchical asset model (ISA-95)	Tag plus Asset Framework hierarchy
Typical latency	100–1000 ms polling	50–500 ms subscriptions	1–60 s (edge-to-cloud)	Near-real-time write, sub-second query
Retention	Hours to days (trend buffer)	None (it is not a store)	Months to years (tiered)	Decades (with compression)
Determinism	Hard real-time for control	Soft real-time	Soft / best-effort	Soft (write side)
Vendor lock-in risk	Medium (per platform)	Low (open spec)	High to medium (cloud lock-in)	High (per historian product)
Indicative cost	$50K–$500K capex per site	$5K–$50K per server license	$0.10–$2 per device-month plus storage	$100K–$1M+ per site (PI)
Best at	Operator control, alarming	Heterogeneous protocol bridging	Multi-site context, ML, mobile	Engineering analytics over decades
Worst at	Long-horizon analytics	Anything other than protocol	Sub-second control	Cloud elasticity, multi-tenant SaaS

Notice that no row says “winner overall.” The categories sit in different cells of the architecture. The right answer for almost every real plant is two, three, or all four — composed, not chosen between.

How they coexist — the typical layered architecture

The coexistence pattern most working plants land on in 2026 has SCADA at the bottom, OPC UA as the spine, an IoT platform handling cloud-side context and analytics, and a historian handling deep engineering history. The four are not redundant — they are stacked.

At the field level, PLCs and RTUs talk to sensors and actuators over deterministic industrial buses (EtherNet/IP, PROFINET, EtherCAT, Modbus). SCADA polls those PLCs and exposes a live operator view. Sub-second supervisory loops, alarms, and operator commands stay entirely on-premises and do not depend on any cloud connection.

In parallel — not downstream — an OPC UA aggregating server pulls the same data (or sits adjacent to the SCADA, reading from its OPC UA module). The OPC layer is the seam: SCADA, IoT platform, and historian all subscribe to OPC UA rather than each writing custom drivers per PLC.

From the OPC layer, the data forks. One copy goes to the historian for long-term storage; the historian’s compression and engineering aggregations are the canonical engineering record. Another copy goes to the IoT platform’s edge gateway, which buffers, aggregates, and forwards to cloud ingest. The IoT platform’s asset model is populated from the OPC UA companion-spec metadata, so the hierarchy is consistent across systems.

Applications sit on top. Operator-facing apps run from SCADA. Engineer-facing analytics (process incidents, regulatory reports) run from the historian. Enterprise-facing dashboards, multi-site ML, and mobile apps run from the IoT platform. ERP and MES synchronize against the IoT platform’s modeled twin, not against raw SCADA tags.

This architecture has clear ownership boundaries: OT owns SCADA and the field; a control-systems team owns the OPC and historian layer; an IT / data team owns the IoT platform and downstream analytics. The seams — OPC UA, MQTT with Sparkplug B, and the asset model — are open standards, which keeps any single vendor from owning the entire stack.

For a deeper treatment of the spine in this architecture see our Unified Namespace architecture with HiveMQ and Sparkplug B guide.

Migration patterns — modernizing legacy SCADA

The most common 2026 starting point is a legacy SCADA from the 2000s — Wonderware, iFIX, RSView, an old WinCC — running on Windows Server 2012 with proprietary drivers, an aging Oracle or SQL Server trend log, and no IoT or cloud integration. Three migration patterns work; one trap pattern does not.

Pattern 1 — strangler around the SCADA. Leave the SCADA running. Stand up an OPC UA tunneler that reads from the SCADA’s existing OPC interface. Route the OPC UA feed to a new historian (or migrate the existing one to a current PI version) and to a new IoT platform edge gateway. Build new dashboards, ML, and mobile against the platform; leave the SCADA HMIs for operators. After 12 to 24 months, replace the SCADA itself if and only if there is operational justification — not because someone wrote “modernize” on a slide. This is the safest pattern.

Pattern 2 — replace SCADA, keep field. Replace the SCADA package (often with Ignition because of its OPC UA, MQTT, and Sparkplug B native support) while leaving PLCs and field wiring untouched. This pattern is well-suited when the existing SCADA vendor is end-of-life or licensing has become punitive. Plan 6 to 18 months and a parallel operation period.

Pattern 3 — greenfield asset, modern stack. New plant or major capacity addition. Skip the legacy SCADA decision — go with Ignition (or AVEVA’s modern System Platform) plus OPC UA plus MQTT/Sparkplug B plus IoT platform plus historian from day one. Cheapest in the long run, hardest politically (OT teams trained on legacy systems push back).

The trap pattern — sometimes pitched as “go cloud, skip SCADA” — is to replace SCADA with an IoT platform alone, routing PLC commands through MQTT to the cloud and back. This breaks the moment your WAN does. Operators cannot acknowledge an alarm. Auto-restart loops stall. We have audited four plants that attempted this in 2024 and 2025; all four reinstated SCADA within 18 months after operational incidents.

For brownfield connectivity specifics see Brownfield IoT legacy machine connectivity playbook and for the future of field-level OPC UA see OPC UA FX field-level communications analysis.

Trade-offs and gotchas

There is no architecture without trade-offs. Eight gotchas catch even experienced teams.

Gotcha 1 — assuming OPC UA is automatically secure. OPC UA supports certificate-based mutual TLS, signing, and encryption — but only if configured. Many deployments run unsigned, unencrypted UA over plaintext TCP. Treat OPC UA security as a configuration discipline, not a default.

Gotcha 2 — cloud cost math at scale. A 100-thousand-tag plant streaming at one-second cadence is 100 thousand messages per second sustained. Naive AWS IoT Core or Azure IoT Hub pricing is two to five cents per thousand messages. Do the multiplication. The answer is “edge-side aggregation, deadband filtering, Sparkplug B compression, or you go broke.”

Gotcha 3 — historian licensing surprises. PI System (now AVEVA PI) licensing has shifted toward subscription with tag-count tiers. Re-read your contract before signing a multi-year IoT platform deal that doubles your effective tag count.

Gotcha 4 — Sparkplug B is opinionated. Sparkplug B’s edge-of-network node model and birth/death certificate semantics are powerful but not what plain MQTT gives you. Treat it as a framework, not a transport.

Gotcha 5 — assuming the historian is the source of truth for events. Historians excel at signals, not at events. Use SCADA event logs or a dedicated event store (the IoT platform’s twin event journal) for operator-action audits.

Gotcha 6 — over-modeling the twin. ISA-95 hierarchies are easy to over-engineer. A model with seven levels (enterprise, site, area, line, cell, unit, equipment) is rarely what dashboards consume. Start with three to four levels and add detail when applications demand it.

Gotcha 7 — assuming the cloud platform’s analytics replace the historian’s. Cloud Parquet plus Athena or BigQuery is good for fleet-wide aggregates but loses the historian’s interpolation guarantees. For regulatory and audit queries, keep the historian authoritative.

Gotcha 8 — orphaning the SCADA. After a successful IoT platform rollout, teams sometimes neglect the SCADA. Operators are still using it daily. Keep SCADA on a current OS, patched, and supported — it is the system that prevents incidents at 2 a.m.

Practical recommendations

Recommendations vary by plant maturity, but five hold across most 2026 industrial customers.

Recommendation 1 — start with OPC UA standardization, even if you make no other change. An OPC UA aggregating server costs $10K to $40K plus integration. It immediately reduces the per-consumer driver footprint and gives you a clean migration substrate.

Recommendation 2 — separate the data plane from the control plane. Operators control through SCADA; analytics consume through OPC UA or MQTT. Do not route operator commands through the cloud. Do not route deep analytics queries through the SCADA.

Recommendation 3 — treat IoT platform and historian as complementary, not competitive. Route a copy of the data to each. Use the historian for engineering history and audits; use the IoT platform for fleet analytics, ML, and mobile applications.

Recommendation 4 — budget for edge compute. The largest single lever on long-term IoT platform cost is edge-side aggregation. A modest edge gateway with stream processing reduces cloud ingest by an order of magnitude.

Recommendation 5 — write the seam-of-responsibility document. The single biggest cause of cost overruns is unclear ownership between OT, control-systems, and IT teams. Define on paper: who owns the SCADA, who owns the OPC server, who owns the historian, who owns the IoT platform, and who arbitrates the seam between them.

For protocol-level comparisons that inform recommendation 4 see Sparkplug B vs OPC UA PubSub comparison and DDS vs MQTT vs OPC UA industrial messaging protocols.

FAQ

Is SCADA dead in 2026?
No — and the framing is misleading. SCADA owns the real-time supervisory and HMI layer that no cloud platform can replace deterministically. What is dying is monolithic SCADA used as a poor man’s historian, asset model, and analytics platform. Modern SCADA (Ignition, AVEVA System Platform 2024) is leaner, sits behind an OPC UA seam, and lets the cloud handle what the cloud handles well. Plants that tried to replace SCADA outright with an IoT platform have almost universally reverted.

Can an IoT platform replace a historian?
For some use cases yes, for engineering authoritativeness usually no. Cloud time-series tiering can hold years of data and serve dashboards and ML. But engineering analytics that depend on swinging-door compression semantics, calculated tags, and event frames are still natively a historian feature. The 2026 pattern is “both — historian authoritative on-prem, IoT platform for fleet analytics and cloud-side ML.” Hybrid bridges from PI Cloud Connect, Aspen InfoPlus.21 to Snowflake, and Honeywell Uniformance to Azure make this routine.

What does OPC UA actually give me that MQTT does not?
OPC UA is a protocol plus a typed information model. MQTT is a transport. OPC UA defines the schema of a pump, motor, or robot through companion specifications; MQTT defines no schema at all — Sparkplug B is what adds payload semantics on top. In practice, modern stacks use both: OPC UA at the device-to-edge boundary for modeling, MQTT (with Sparkplug B) for edge-to-cloud transport. They are complementary, not competitive.

How does PI System compare to AWS IoT SiteWise in cost?
Very different cost shapes. PI is on-premises subscription, priced by tag count and feature tier; a mid-size plant runs $150K to $500K annually. SiteWise is cloud usage-priced: per-asset-per-month plus ingest and storage; the same tag footprint can range from $80K to $400K annually depending on cadence and aggregation. Below 10K tags SiteWise is usually cheaper; above 200K high-cadence tags PI often wins on total cost. The right question is rarely cost in isolation — it is fit, retention requirement, and engineering team familiarity.

Do I need both OPC UA and MQTT?
Often yes, in different segments of the stack. OPC UA at the device-to-edge layer carries the typed model. MQTT (typically with Sparkplug B) carries efficient pub-sub transport from edge to cloud. Some all-MQTT stacks (Ignition with MQTT Engine, HiveMQ-based architectures) compress this into a single transport — but the modeling problem still needs to be solved, usually by Sparkplug B or by maintaining an OPC UA address space on the edge.

What is the right migration order for a 20-year-old SCADA plant?
The Pattern 1 strangler order: first, install an OPC UA tunneler against the existing SCADA’s OPC interface; second, stand up a modern historian (or migrate the existing one to current versioned hardware); third, deploy an IoT platform edge gateway reading from OPC UA; fourth, build the asset model and connect dashboards, ML, and mobile to it; fifth — only if operationally justified — replace the SCADA itself. This sequence delivers value early and avoids the cliff of a big-bang SCADA replacement.

Further reading

• Unified Namespace architecture with HiveMQ and Sparkplug B (2026)
• Brownfield IoT legacy machine connectivity playbook (2026)
• OPC UA FX field-level communications analysis (2026)
• Sparkplug B vs OPC UA PubSub comparison (2026)
• DDS vs MQTT vs OPC UA industrial messaging protocols (2026)

References

• OPC Foundation — OPC UA Specification Part 1 to Part 14, including PubSub and companion specifications. https://opcfoundation.org/
• AVEVA — PI System documentation, PI Cloud Connect, Asset Framework reference. https://docs.aveva.com/
• Inductive Automation — Ignition 8.1 and Ignition 8.3 platform documentation, MQTT Engine, OPC UA module. https://docs.inductiveautomation.com/
• Siemens — Insights Hub (formerly MindSphere) industrial IoT platform documentation. https://documentation.mindsphere.io/
• AWS — IoT SiteWise user guide and asset model reference. https://docs.aws.amazon.com/iot-sitewise/
• Microsoft — Azure IoT Operations and Azure IoT Hub industrial reference architectures. https://learn.microsoft.com/en-us/azure/iot-operations/
• ANSI/ISA-95 — Enterprise-Control System Integration multi-part standard. https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95