Millions of industrial systems still run on OPC Classic. It works. It’s proven. So why is everyone talking about migrating to OPC UA?
The short answer: OPC Classic was built for a different era. It’s tied to Windows, has no built-in security, and can’t keep up with the demands of modern connected factories. OPC UA fixes all of that — and adds capabilities that OPC Classic never had.
But migration isn’t a flip-the-switch event. This guide covers exactly what’s different between the two, why the move matters, and how to plan a migration that doesn’t blow up your production.
Table of Contents
A Brief History
OPC Classic was born in 1996. The OPC Foundation created it to solve a real problem: every hardware vendor had their own proprietary protocol, and getting devices to talk to software was a nightmare. OPC Classic gave the industry a common standard.
It worked well for its time. But it was built on Microsoft’s COM and DCOM technology, which locked it to Windows. That made sense in 1996 when Windows dominated every layer of industrial computing. It doesn’t make sense anymore.
OPC UA (Unified Architecture) arrived in 2006. The OPC Foundation designed it from scratch to fix the limitations of OPC Classic while keeping the core idea alive: vendor-independent data exchange. In 2016, it became the international standard IEC 62541.
OPC Classic: What It Includes
OPC Classic isn’t a single specification. It’s a family of separate standards, each solving a different problem:
OPC DA (Data Access) handles real-time data — reading and writing values like temperatures, pressures, and equipment states. This is by far the most widely used OPC Classic spec.
OPC HDA (Historical Data Access) provides access to archived historical data. Think trend charts and production logs.
OPC A&E (Alarms and Events) manages alarm notifications and event tracking.
OPC DX (Data eXchange) was designed for server-to-server communication but never gained wide adoption.
Each of these required its own separate implementation. Developers had to include foundational OPC code over and over again for each interface. If you needed DA, HDA, and A&E in one system, you were writing and maintaining three separate integrations.
OPC UA: What Changed
OPC UA takes everything OPC Classic offered — data access, historical data, alarms, events — and combines it into a single, unified framework. One codebase. One set of services. One address space.
But OPC UA isn’t just a repackaged version of OPC Classic. It’s a fundamentally different architecture with major improvements in every area.
Platform independence
OPC Classic only runs on Windows because of its dependency on COM/DCOM. OPC UA runs on anything: Windows, Linux, macOS, embedded systems, even microcontrollers. According to the IEC 62541 specification, OPC UA’s communication stack was specifically designed for multi-platform implementation, including portable ANSI C, Java, and .NET.
This matters because modern industrial architecture doesn’t live on Windows alone. Edge devices run Linux. Cloud platforms run Linux. PLCs have embedded operating systems. OPC UA works across all of them.
Built-in security
This is the biggest gap between Classic and UA.
OPC Classic has essentially no security. DCOM offers some basic authentication, but it’s hard to configure and not designed for industrial environments. Data travels unprotected, and there’s no encryption, no certificate management, no audit trail.
OPC UA was designed with security as a core requirement, not an afterthought. The IEC 62541 Part 2 security model covers application authentication using X.509 digital certificates, message encryption and signing at the transport layer, user-level authentication and authorization (down to individual data points), security audit trails with traceability between client and server logs, and role-based access control.
The German Federal Office for Information Security (BSI) performed a systematic security analysis of OPC UA and found no systematic errors in the specification. For facilities handling sensitive industrial data or operating critical infrastructure, this level of built-in security isn’t optional anymore — it’s mandatory.
Rich information modeling
OPC Classic uses a flat data model. You get tags with values, and that’s about it. Register 40001 might be a temperature. Or a pressure. Or anything. You need external documentation to know what you’re looking at.
OPC UA introduces an object-oriented information model. Data isn’t just a number — it comes with context, structure, and meaning. A temperature transmitter in OPC UA is represented as an object with its current value, engineering units, alarm limits, quality status, and relationships to other objects. Clients can browse the server and discover all of this at runtime without any prior programming.
The IEC 62541 standard describes it this way: OPC UA provides a consistent, integrated address space and service model that allows a single server to integrate data, alarms, events, and history, and provide access to them through a unified set of services.
On top of that, over 60 companion specifications define standardized information models for specific industries — robotics, machine vision, packaging, injection molding, and many more.
No more DCOM headaches
If you’ve ever configured DCOM for OPC Classic, you know the pain. Firewall exceptions, user permissions, authentication settings, timeout values — and when something breaks (which it does), troubleshooting is a nightmare. DCOM was never designed for industrial use.
OPC UA communicates over standard TCP/IP using a single registered port (4840). No DCOM. No COM. No Windows dependency. Connections work through firewalls with a single port rule, and there’s no need for the complex permission matrices that DCOM requires.
Client-server and publish-subscribe
OPC Classic only supports client-server communication. A client connects to a server and polls for data.
OPC UA supports both client-server and publish-subscribe patterns. The Pub/Sub model allows one-to-many data distribution without direct connections — which is essential for cloud integration, large-scale data collection, and scenarios where dozens of consumers need the same data.
Side-by-Side Comparison
| Feature | OPC Classic | OPC UA |
|---|---|---|
| Standard | Multiple separate specs (DA, HDA, A&E) | Single unified standard (IEC 62541) |
| Platform | Windows only (COM/DCOM) | Any OS (Windows, Linux, embedded) |
| Security | None built-in | Encryption, certificates, access control, audit |
| Data model | Flat (tags and values) | Object-oriented with semantic meaning |
| Communication | Client-server only | Client-server + Pub/Sub |
| Discovery | Limited | Automatic server and service discovery |
| Firewall friendly | No (DCOM uses dynamic ports) | Yes (single TCP port 4840) |
| Data encoding | COM binary only | Binary, XML, JSON |
| Scalability | Limited by DCOM | From microcontrollers to enterprise |
| Industry 4.0 ready | No | Yes (RAMI 4.0 recommended standard) |
| Companion specs | None | 60+ industry-specific models |
Why Migrate Now?
You might be thinking: “My OPC Classic system works fine. Why change?”
Here’s why the clock is ticking:
Security threats are growing. Cyberattacks on industrial control systems have increased dramatically. OPC Classic has no defense. Every year you wait is another year of exposure.
Windows dependencies are shrinking. Microsoft has ended support for older Windows versions that many OPC Classic systems depend on. Running unsupported operating systems in production is a liability.
Industry 4.0 demands it. The RAMI 4.0 reference model requires IEC 62541 OPC UA for the communication layer. If your products or systems need to be Industry 4.0 compatible, they need OPC UA.
Integration is getting harder. Cloud platforms, edge computing, and IIoT applications don’t speak DCOM. Every new integration with an OPC Classic system requires custom bridging, which costs time and money.
The OPC Foundation has moved on. OPC Classic specifications are in maintenance mode. All new development focuses exclusively on OPC UA.
Migration Strategies
There are three main approaches to migration. Pick the one that fits your situation.
Strategy 1: Wrapper / Gateway approach
Best for: Organizations that need to keep existing OPC Classic systems running while connecting them to new OPC UA infrastructure.
An OPC UA wrapper sits between your existing OPC Classic servers and new OPC UA clients. It translates OPC Classic data into OPC UA format, making legacy servers look like UA servers to modern clients.
This is the fastest, lowest-risk option. You don’t touch your existing systems. You don’t need downtime. And you immediately get OPC UA’s security benefits on top of your Classic data.
The drawback: you don’t get the full power of OPC UA’s information modeling. The wrapper maps Classic tags to UA variables, but you’re still limited by the flat data structure of the original system.
Strategy 2: Phased migration
Best for: Most organizations. This is the recommended approach.
Instead of replacing everything at once, you migrate in stages aligned with your normal equipment refresh cycles. The plan looks like this:
First, install wrappers on existing OPC Classic servers to provide UA access. This gives you immediate interoperability.
Second, when new equipment is purchased or old equipment is replaced, require native OPC UA support. Most major PLC and device manufacturers now offer built-in OPC UA servers.
Third, gradually retire OPC Classic connections as the underlying hardware and software gets updated. Over time, the wrappers disappear because the original Classic servers have been replaced with native UA systems.
This approach spreads cost over time, minimizes risk, and lets you run Classic and UA side by side during the transition.
Strategy 3: Full replacement
Best for: New installations or small systems where a complete cutover is practical.
If you’re building a new plant, new production line, or replacing a small legacy system entirely, go straight to OPC UA. There’s no reason to install OPC Classic in any new project today.
This gives you the full benefit of OPC UA from day one: rich information models, built-in security, cross-platform support, and cloud-ready architecture.
Step-by-Step Migration Plan
Regardless of which strategy you choose, follow these steps:
Step 1: Audit your current system. Identify every OPC Classic server and client. Document what data they exchange, which OPC specifications they use (DA, HDA, A&E), and what applications depend on them.
Step 2: Assess compatibility. Check which of your existing devices and software already support OPC UA. Many modern PLCs (Siemens, Rockwell, Beckhoff, Schneider) already have OPC UA servers built in — you may just need to enable them.
Step 3: Prioritize. Start migration with the systems that have the highest security risk or the worst DCOM problems. These give you the biggest immediate return.
Step 4: Deploy wrappers where needed. For systems that can’t be upgraded yet, install OPC UA wrappers to bridge the gap. Test thoroughly before connecting to production systems.
Step 5: Update your architecture. As you add OPC UA connections, design your network to take advantage of UA features: use certificates for authentication, enable encryption, implement proper access control.
Step 6: Train your team. OPC UA is different from Classic. Your engineers and IT staff need to understand certificates, security policies, information models, and the new tools. Invest in training early.
Step 7: Test and validate. Run Classic and UA systems in parallel during transition. Compare data values, check timing, verify alarm behavior. Only decommission Classic connections when you’re confident the UA path works correctly.
Common Migration Pitfalls
Don’t ignore certificate management. OPC UA’s security depends on X.509 certificates. If you don’t plan how to create, distribute, and renew certificates, you’ll end up with either broken connections or (worse) everyone auto-trusting everything — which defeats the purpose of security.
Don’t assume a wrapper is the final solution. Wrappers are a bridge, not a destination. Plan for native UA support as the long-term goal.
Don’t migrate during a production crunch. Start with non-critical systems. Build experience and confidence before touching mission-critical connections.
Don’t forget about historical data. If you use OPC HDA, make sure your UA migration plan covers how historical data will be accessed going forward. Some historians already support OPC UA; others may need upgrades.
Conclusion
OPC Classic did its job well for over two decades. But the industrial world has changed. Security, cross-platform support, cloud connectivity, and rich data modeling aren’t nice-to-haves anymore — they’re requirements.
OPC UA isn’t just an upgrade. It’s a different architecture built for a connected, security-conscious world. The good news is you don’t have to migrate overnight. Wrappers, phased approaches, and native UA support in modern equipment give you a clear, low-risk path forward.
The worst strategy is no strategy. Every year of delay makes migration harder as Classic infrastructure ages and security gaps widen. Start your audit today, pick your approach, and take the first step. Your future self will thank you.