OPC UA vs OPC Classic: comms upgrade decision

The OPC Classic stack on a brownfield petrochem control room has been doing its job for fifteen years and the operators are happy. Then the Windows team announces that the next upgrade cycle drops support for the DCOM stack the OPC Classic server depends on, and the conversation about migrating to OPC UA stops being theoretical. This page is for the controls engineer who has to plan that migration — when to do it, what breaks, what risks live in the namespace difference, and how to size the project.

Try the simulator →

TL;DR

• OPC Classic (DA, HDA, A&E) is built on COM/DCOM. It is Windows-only, deprecated, and the security story is broken in any modern IT environment. The OPC Foundation declared it legacy years ago and is no longer evolving the spec.
• OPC UA (Unified Architecture) is the modern replacement. Cross-platform, certificate-based mutual authentication, structured address space, native server-on-PLC support on most modern CPUs, and an active spec under the OPC Foundation.
• The migration risks are not the protocol itself — they are the namespace drift between the OPC Classic flat tag space and the OPC UA structured object model, the certificate trust setup, and the application-side code that consumes the data.
• New SA projects all default to OPC UA. Brownfield SA sites with OPC Classic in production typically have a 2-5 year migration window driven by the Windows server lifecycle, not by the OPC Foundation calendar.
• The architectural choice within OPC UA is server-on-PLC versus gateway. Siemens S7-1500 has a built-in OPC UA server. Older S7-300 / S7-400 sites need a gateway approach (KEPServerEX, Matrikon, Siemens WinCC OA).

Side-by-side

Criterion	OPC Classic (DA/HDA/A&E)	OPC UA
Underlying transport	COM / DCOM, Windows-only	Binary TCP (port 4840) or HTTPS, cross-platform
Address space model	Flat tag list per server, vendor-specific naming	Object-oriented, typed, browseable, namespace-qualified
Authentication	Windows user accounts via DCOM, weak in modern environments	X.509 certificates with mutual trust, plus username/password
Encryption in transit	None natively	None / Sign / SignAndEncrypt selectable per session
Server platform	Windows server only	Windows, Linux, embedded, native on PLC
Native PLC support	None — always a gateway	Siemens S7-1500, Rockwell ControlLogix 5580 v32+, B&R, Beckhoff, CODESYS
Spec status	Legacy — no further development	Active, under OPC Foundation
Companion specs	None	Companion specs for PackML, Euromap, ISA-95, AutoML, FDI
Typical SA brownfield	Petrochem WinCC Classic + S7-300/400, water utilities, older mining	Greenfield projects, all sectors
Migration trigger	Windows server EOL or DCOM-related security audit finding	N/A
Migration window in SA	2-5 years from initial trigger	N/A
Reference	Wikipedia: OPC UA; Siemens OPC UA docs	Same

Where each one wins

OPC Classic

OPC Classic wins exactly one place: a brownfield site that already has it working, where the upgrade has not been forced yet, and where the engineering hours to migrate exceed the operational risk of running the legacy stack for another year. That is the only honest answer. OPC Classic is not winning new projects, the OPC Foundation is not extending the spec, and the Microsoft posture on DCOM is that it is a security liability to be hardened or removed.

The reason brownfield sites stay on OPC Classic is sunk cost. Fifteen years of WinCC Classic screens with their tag connections going through a known-working OPC DA server, application code on the MES side that reads through OPC HDA, alarm pipelines through OPC A&E, all of it instrumented and tuned and trusted by the operators. Replacing the OPC layer touches every one of those subsystems. The migration project is large, the testing burden is large, and on a continuously running plant the cutover window is small. So sites delay.

The delay is rational up to a point. The point at which it stops being rational is when the IT team's Windows server roadmap forces it. DCOM hardening was already pushed by Microsoft via security updates in 2022-2023, and the trajectory is toward DCOM being either fully disabled or so locked down that OPC Classic stops working in practice. SA petrochem control rooms running Windows Server 2016 are now several lifecycles past comfortable, and the IT-driven upgrade conversations are happening across the major operating companies right now.

OPC UA

OPC UA wins everywhere except brownfield delay scenarios. New projects default to it because there is no good alternative — the protocol is widely supported, the security model is what modern IT auditors want to see, the cross-platform story means a Linux-based historian or a Docker-deployed MES can connect natively, and the spec is alive and evolving with companion specs that solve real domain problems (PackML for packaging, Euromap for plastics, ISA-95 for MES integration, FDI for device integration).

The native server-on-PLC support is the single biggest practical win. A Siemens S7-1500 has a built-in OPC UA server that you enable in the project tree, configure a certificate for, and then any client on the network can browse the tag namespace and subscribe to monitored items. No gateway, no Windows box in the loop, no DCOM. Same on a Rockwell ControlLogix 5580 from firmware v32 onwards — the controller hosts an OPC UA server natively. Beckhoff TwinCAT, B&R, CODESYS-based platforms — all native OPC UA servers. The gateway approach (KEPServerEX, Matrikon OPC, Siemens WinCC OA acting as gateway) is still relevant for older controllers (S7-300, S7-400, older PLC-5 / SLC) that do not have native servers, but for any modern CPU the gateway is overhead.

The structured address space is the second big win. Where OPC Classic gave you a flat list of tags with vendor-specific naming conventions, OPC UA gives you a browseable object model — your equipment is organised as objects, the objects have typed properties, the properties have engineering-unit metadata, the relationships between objects are explicit. A client browsing the namespace can discover the structure of a tank farm without prior knowledge. That metadata makes OEE and historian integrations dramatically less brittle than the OPC Classic equivalent.

The third win is the security model. Sessions establish mutual trust through X.509 certificates exchanged on first connection and pinned thereafter. Communication can be signed (integrity only), or signed and encrypted (integrity plus confidentiality). The user identity layer can ride on top — username/password, X.509 user certificates, anonymous (turned off in production), or platform-native (Active Directory tokens). This is what an IT auditor expects to see in 2026 and what an OPC Classic site cannot deliver.

What this means in SA

SA petrochem at the major refining and synfuels operations is the densest concentration of OPC Classic in the country. WinCC Classic on Windows Server with hundreds of S7-300 and S7-400 CPUs feeding it, OPC DA gateways into MES and historian layers, OPC A&E into alarm aggregators. The migration projects on these sites are multi-year and they are happening — typically a phased approach where the WinCC Classic SCADA gets replaced by WinCC OA or WinCC Unified during a major shutdown, and the OPC layer gets switched to OPC UA at the same time. The CPU layer often stays S7-300/400 for one more shutdown cycle, with OPC UA delivered through a gateway, and the CPUs themselves get replaced with S7-1500 in a later phase to enable the native server.

SA water utilities are similar — large municipal water and bulk-supply operations have Siemens-heavy SCADA with OPC Classic in places. The migration pressure is lower because the IT discipline at municipal water utilities is more variable, and the security audit triggers that drive petrochem migrations are softer. Greenfield water projects are uniformly OPC UA with native S7-1500 servers and Linux-based SCADA platforms increasingly common.

SA mining beneficiation has more variety — Allen-Bradley sites, Siemens sites, Schneider sites, mixed-vendor sites. OPC Classic shows up on the older Wonderware / FactoryTalk Historian installations, with KEPServerEX often acting as the OPC bridge. The migration to OPC UA is happening site by site, usually triggered by a SCADA refresh project rather than a deliberate OPC migration.

SA F&B and automotive components are mostly OPC UA already. New machinery from European OEMs ships with OPC UA enabled by default. The PackML companion specification is showing up on the better-engineered packaging lines. The historian integration is typically through a managed OPC UA aggregator rather than a per-line gateway.

The SA-specific operational point: on a mining or petrochem site at distance from major fibre routes, the round-trip latency on encrypted OPC UA sessions over a marginal network link can become noticeable. The encryption overhead is small but the certificate handshake at session establishment is not, and on a flaky link with frequent reconnects the cumulative latency adds up. The fix is to use Sign-only mode rather than SignAndEncrypt where the network is trusted (between an on-site PLC and a same-network historian), and SignAndEncrypt only across boundaries where the threat model demands it.

Common mistakes when picking

• Treating the migration as a like-for-like swap. It is not. The address space model is different — flat versus structured — and the application code that consumes the data has to be rewritten or wrapped, not just repointed at a new server. Plan the rewrite, do not assume the existing code carries.
• Ignoring the certificate trust setup. OPC UA mutual trust is a real piece of work on a multi-server, multi-client site. Each pair of endpoints needs a one-time exchange of certificates and an explicit trust decision. Get this wrong and the post-cutover punch list will be full of "client cannot connect" tickets that are all certificate problems.
• Using anonymous authentication in production. Tempting because it works on day one without identity setup. Wrong because it leaves the server open to anyone on the network with a UA client. Set up proper identity from the start, even if it is just a service account per client.
• Forgetting the namespace versioning. When the PLC tag database changes — a structure rearranged, a tag renamed, a new device added — the OPC UA address space changes too. Clients with hard-coded NodeId references break. Use BrowseName-based references in client code where stability matters, or accept the breakage and version your address space deliberately.
• Mixing OPC UA security policies on the same server. Some clients support Basic256Sha256 and some are stuck on Basic256. Some require Sign, some require SignAndEncrypt. The server can be configured to accept multiple policies, but the more permissive the configuration the harder it is to audit. Pick the policies the site needs and turn off the rest.
• Underestimating the historian backfill. When you cut from OPC HDA to OPC UA history, the historical data already in the Classic historian does not migrate automatically. Plan the historian migration as a separate workstream — export, transform, import, validate — and budget the time properly.

How to test the trade-off in the simulator

Drop a Siemens S7-1500 architecture into the simulator and enable the built-in OPC UA server in the project. Connect a virtual UA client (a free tool like UaExpert from Unified Automation works for this, but the simulator has a built-in client too) and browse the address space. Now compare that experience to the OPC Classic equivalent — a flat tag list, no metadata, no browsing of structure, no engineering units in the namespace.

Wire up a small alarm pipeline. On the UA side, configure the server to expose alarm events through the built-in alarm and condition model. Subscribe a client to the alarm namespace and watch events flow through with full context. On the Classic side, you would be wiring an OPC A&E gateway and writing application code to map alarm states. The simulator makes the comparison concrete in twenty minutes and the architectural advantage of OPC UA is obvious by the end. The simulator also supports certificate trust workflows, so practising the exchange before doing it on a live site is straightforward.

Start the free tier →

Vendor reference

The authoritative spec is hosted by the OPC Foundation — the OPC UA spec is publicly available in summary form, with the full text under member access. The Siemens implementation reference is at Siemens Industry Online Support — search for "S7-1500 OPC UA" and the application examples are practical. The Rockwell implementation reference is at Rockwell Automation Support — search for "ControlLogix OPC UA Server". For an independent overview, the OPC UA Wikipedia article covers the protocol history accurately and is a useful sanity check against vendor marketing.

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. We do not commission your OPC UA migration. We are not an IT security auditor and we do not sign off on the certificate-trust architecture for a production site. The simulator is a learning tool — practise the address-space browsing, the certificate exchange, the alarm subscription, the historical-access patterns, in a sandbox where the cost of getting it wrong is zero. It does not replace a proper migration project plan, a Windows server retirement schedule, or a competent integrator who has done a few of these on real plants. Pricing implications and product details from third-party gateways change frequently — get a current quote from the relevant supplier before you commit.