OPC UA Migration Archives

1. Why OPC UA migration has become urgent in 2026 For most of the past decade, migrating from OPC Classic to OPC UA was sensible but deferrable. If legacy systems were working, the case for disrupting them was difficult to make in a capital planning meeting. That has changed, and it has changed on three fronts simultaneously. The cybersecurity front. OPC Classic's dependence on Microsoft COM/DCOM is now a documented, actively managed vulnerability. CVE-2021-26414, a critical DCOM authentication bypass, forced Microsoft to issue the mandatory KB5004442 hardening patch - enforced by default on all supported Windows systems from June 2023 onward. This patch broke OPC Classic connections in many industrial environments, leaving operators choosing between running a known vulnerability unpatched or accepting integration failures. CISA, ENISA, and the German BSI all identify DCOM-based OT communication as an active risk factor. This is a structural problem with no fix that does not involve leaving OPC Classic. The regulatory front. The NIS2 Directive (EU, effective October 2024) requires operators of essential services including manufacturing, energy, water, and transport to implement encrypted communications and proper access controls for industrial systems, or face significant penalties. NERC CIP (North America) demands Electronic Security Perimeters that DCOM's dynamic port ranges make extremely difficult to configure cleanly. FDA 21 CFR Part 11 (pharmaceuticals) requires audit trails that unauthenticated OPC Classic communications cannot credibly provide. The operational front. Every modern industrial architecture - cloud data pipelines, digital twins, AI-driven predictive maintenance, IIoT platforms, is built around OPC UA, not OPC Classic. Each new integration with a cloud historian, an analytics platform, or a MES application now requires either a bespoke OPC Classic connector (expensive, fragile, non-standard) or OPC UA. The longer OPC Classic remains in place, the more expensive every adjacent modernisation project becomes. The question for most industrial organisations in 2026 is not whether to migrate, but which approach fits their environment, and how to do it without disrupting production. 2. What you are migrating from: OPC Classic (DA, HDA, AE) explained OPC Classic is not a single protocol. It is a family of three distinct specifications, each serving a different data function. Understanding this is essential because each one has its own migration path and challenges. OPC DA (Data Access) is the most widely deployed. It provides real-time read/write access to process values from PLCs, DCSs, RTUs, and other automation devices. OPC DA servers expose a tag-based address space - a flat or hierarchical list of data items, each identified by an ItemID string. Most SCADA systems, historians, and MES platforms were built to connect to OPC DA. OPC HDA (Historical Data Access) provides access to time-stamped historical data stored in process historians. It allows clients to query past values, perform interpolation, and retrieve trend data over time windows. The OPC HDA query model differs structurally from OPC UA Historical Access making HDA one of the technically more demanding aspects of migration. OPC AE (Alarms and Events) handles alarm notifications and event subscriptions. OPC AE servers send notifications when process conditions change, alarms activate or clear, or operator actions occur. Mapping OPC AE to OPC UA Alarms and Conditions (A&C) requires careful attention, as the underlying data models are structured differently. All three share the same fundamental constraint: they rely entirely on Windows COM/DCOM for both local and network communication. This means OPC Classic systems require Windows on both ends, consume large dynamic port ranges (49152–65535) that defeat precise firewall rules, carry no built-in message encryption, and offer no cryptographic identity verification for connecting applications. 3. What you are migrating to: what OPC UA delivers OPC UA (Open Platform Communications Unified Architecture) is an IEC international standard (IEC 62541) that was designed from the ground up to be everything OPC Classic is not. Platform independence. OPC UA runs on Windows, Linux, macOS, embedded systems (including 8-bit microcontrollers), cloud infrastructure, and edge devices. PLCs and RTUs from vendors including Siemens, Beckhoff, Rockwell, and many others now ship with native OPC UA interfaces. Unified data model. Where OPC Classic separates real-time data (DA), historical data (HDA), and alarms (AE) into three incompatible specifications, OPC UA unifies them in a single object-oriented information model. Process values, historical records, alarms, events, and diagnostic data all live in the same address space, accessible through the same OPC UA interface. Built-in security. OPC UA includes mandatory AES-128 or AES-256 encryption, X.509 certificate-based mutual authentication for both applications and users, message signing to detect tampering, and role-based access control (RBAC) at the data node level. These are not optional add-ons, they are core parts of the specification. Firewall-friendly architecture. OPC UA uses a single, configurable TCP port (default: 4840). This makes precise firewall rules straightforward and Electronic Security Perimeter configurations achievable: a significant advantage over DCOM's unpredictable port ranges. Cloud and IIoT readiness. OPC UA's PubSub communication model supports MQTT, AMQP, and UDP multicast transport, making it natively compatible with cloud IoT platforms (Azure IoT Hub, AWS IoT Greengrass), industrial message brokers, and large-scale IIoT data pipelines. Active development and ecosystem. Unlike OPC Classic - which is in maintenance-only status - OPC UA continues to evolve. OPC UA FX (Field eXchange, 2023) extended OPC UA to controller-to-controller communication at the field level. Over 160 companion specifications define interoperable information models for specific industries and machine types, from machine tools (umati) to offshore oil and gas (MDIS) to pharmaceutical manufacturing. 4. OPC Classic vs OPC UA: The full comparison Dimension OPC Classic (DA / HDA / AE) OPC UA Platform Windows only (COM/DCOM) Windows, Linux, macOS, embedded, cloud Security No native encryption; relies on Windows DCOM security AES-256 encryption, X.509 certificates, RBAC - built in Data model Three separate, incompatible specs (DA, HDA, AE) Single unified information model covering all data types Network ports Dynamic DCOM port range (49152–65535) Single configurable port (default 4840) Firewall compatibility Very difficult Straightforward Cloud / IIoT support Not designed for it Native (PubSub, MQTT, AMQP, REST) Authentication Windows user accounts / DCOM security X.509 certificates, username/password, tokens Active development Maintenance only Actively developed - FX, companion specs, cloud initiative IEC standard No IEC 62541 Regulatory alignment Poor (NIS2, NERC CIP, FDA) Strong alignment with all major OT compliance frameworks 5. Three OPC UA migration approaches There is no single right way to migrate from OPC Classic to OPC UA. The correct approach depends on the size of your installed base, your operational risk tolerance, your available budget, and your compliance timeline. Three proven approaches exist, and they are not mutually exclusive. 6. Approach 1: Wrapper-based migration (recommended for brownfield) Best for: Organisations with significant OPC Classic installed bases, high-availability requirements, and limited tolerance for downtime during migration. The OPC UA Wrapper is a software bridge that inserts itself between existing OPC Classic infrastructure and the rest of your architecture. It requires no changes to existing OPC Classic servers, no PLC modifications, and no process downtime. How the Wrapper component works (OPC Classic servers → OPC UA clients) The Wrapper connects to your existing OPC Classic DA, HDA, or AE servers using the standard DCOM interface exactly as any OPC Classic client does. It then re-exposes the data from those servers as a fully compliant OPC UA server. Any OPC UA client - a cloud platform, a modern historian, an MES application, an AI analytics tool - connects to the Wrapper using OPC UA with full encryption, certificate authentication, and RBAC. That client never touches DCOM. The security result is immediate and significant: DCOM communication is contained to the local machine or a tightly controlled local segment. Every external connection operates on OPC UA. The DCOM attack surface including vulnerabilities like CVE-2021-26414 is isolated rather than network-wide. How the Proxy component works (OPC UA servers → OPC Classic clients) The reverse direction is equally supported. Where legacy OPC Classic client applications, older SCADA systems, HMI platforms, reporting tools need to access modern OPC UA servers, the Proxy component presents the OPC UA server as if it were an OPC Classic server. The legacy client connects via its familiar OPC Classic interface; the Proxy handles the OPC UA side transparently. This bidirectional capability is what makes the Wrapper suitable as a long-term migration platform, not just a temporary patch. Both old and new clients can coexist in the same architecture, each seeing the interface they expect. OPC UA Wrapper: full feature set Feature Description OPC Classic DA → OPC UA Exposes OPC Classic DA servers as OPC UA servers - real-time data with full address space mapping OPC Classic HDA → OPC UA HA Exposes OPC Classic HDA servers with historical data read capability through OPC UA Historical Access OPC Classic AE → OPC UA A&C Maps OPC Classic Alarms and Events to the OPC UA Alarms and Conditions information model OPC UA → OPC Classic (Proxy) Presents OPC UA servers as OPC Classic servers for legacy clients Automatic address space mapping Intelligently maps OPC Classic tag structures to OPC UA node hierarchies without manual configuration OPC UA security Full OPC UA security: encrypted channels, certificate management, security mode selection (None / Sign / Sign & Encrypt), user identity configuration Windows Service deployment Wrappers run as Windows background services - no user session required, survives reboots Read/write capability Full read and write of OPC DA item values in real time Logging and diagnostics Configurable log levels for all connection events, errors, and data operations supports audit requirements Intuitive configuration UI GUI-based configuration tool - no scripting or SDK knowledge required Download OPC UA Wrapper 7. Approach 2: Phased protocol replacement Best for: Organisations with medium-sized installed bases who want to progressively eliminate OPC Classic entirely over a 2–5 year horizon aligned with system refresh cycles. Phased replacement treats OPC UA migration as an ongoing programme rather than a single project. Each time an OPC Classic server reaches end-of-life, undergoes a scheduled upgrade, or is part of a broader system replacement, it is replaced with a native OPC UA interface. The OPC UA Wrapper handles the transition period bridging old clients that have not yet been updated alongside new OPC UA clients. A practical phased roadmap looks like this: Phase 1: Immediate risk reduction (months 1–3). Deploy the OPC UA Wrapper in front of all OPC Classic servers that are accessible from the wider OT or IT network. All new client connections use OPC UA. DCOM is contained. Compliance posture improves immediately without touching any existing servers. Phase 2: New client migration (months 3–12). All new integration projects - cloud connections, MES upgrades, analytics platforms - connect via OPC UA only. No new OPC Classic clients are introduced. The OPC Classic installed base stops growing. Phase 3: Server-by-server replacement (12–36 months). As OPC Classic servers reach planned refresh cycles, replace them with native OPC UA servers , either through vendor firmware/software upgrades where available, or through new hardware deployments. The Wrapper bridges the remaining OPC Classic servers throughout this phase. Phase 4:OPC Classic retirement (36–60 months). Once all servers are native OPC UA, the Wrapper layer can be decommissioned. The full OPC UA security model operates end-to-end. 8. Approach 3: Greenfield OPC UA development Best for: New system deployments, major brownfield overhauls where existing systems are being replaced anyway, and software vendors building OPC UA interfaces into their products. For organisations building new OPC UA interfaces from scratch, whether device manufacturers embedding OPC UA into PLCs and RTUs, or software vendors adding OPC UA connectivity to their platforms. The correct approach is native OPC UA development using an SDK toolkit. Integration Objects provides both an OPC UA Client Toolkit and an OPC UA Server Toolkit for .NET development environments. These toolkits provide a fully certified OPC UA implementation - handling the protocol stack, security layer, address space management, and session handling, so development teams can focus on their application logic rather than the specification complexity. 9. OPC UA migration challenges and how to solve them Every OPC UA migration encounters a predictable set of technical challenges. Here is how each one is addressed in practice. Challenge What makes it difficult Recommended solution Address space mapping OPC Classic uses flat or semi-hierarchical tag-based addressing (e.g., "Plant1.Reactor2.Temperature"). OPC UA uses an object-oriented node hierarchy with typed references. The structures do not map 1:1 Use the OPC UA Wrapper's automatic address space mapping, which preserves the OPC Classic tag hierarchy as a browseable OPC UA node tree - no manual mapping required Security certificate management OPC UA requires X.509 certificates for each client-server connection. In large deployments, managing certificates manually across dozens of applications is impractical Implement an OPC UA Global Discovery Server (GDS) as a central Certificate Authority. It issues, distributes, and renews certificates automatically across all OPC UA applications OPC AE to OPC UA A&C migration OPC Classic Alarms and Events and OPC UA Alarms and Conditions use different data models. Alarm conditions, sub-conditions, and event types do not map directly Use the Wrapper's AE-to-A&C mapping layer, which translates OPC AE alarm structures to their OPC UA equivalents. Verify all alarm mappings in a test environment before production deployment OPC HDA to OPC UA Historical Access The HDA query model (raw, processed, at time) differs from OPC UA HA in both API structure and query capabilities Use the Wrapper's HDA bridging capability, then validate historical query results against known reference data from the original historian Firewall and network reconfiguration Moving from DCOM dynamic ports to a single OPC UA port requires firewall rule changes which need IT security team involvement and change management processes This is actually a security improvement: work with your network security team to define precise rules for the OPC UA port (default 4840 / 4843 for HTTPS). Document the change as part of your IEC 62443 or NIS2 compliance evidence Legacy client compatibility Older OPC Classic client applications (SCADA, HMI, reporting tools) cannot be replaced immediately and must continue working during migration Deploy the OPC UA Proxy component: legacy OPC Classic clients connect to the Proxy, which presents OPC UA servers as OPC Classic servers. No changes to legacy client applications are required OPC UA security modes — choosing the right policy OPC UA supports multiple security policies (None, Sign, Sign & Encrypt) and algorithms (Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss). Choosing incorrectly creates either security gaps or unnecessary performance overhead For all production connections: use Sign & Encrypt with Aes256_Sha256_RsaPss or Aes128_Sha256_RsaOaep. Reserve Security Mode: None for isolated test environments only 10. OPC UA migration and regulatory compliance OPC UA migration is not just a technical upgrade, in many jurisdictions and sectors it is becoming a compliance requirement. Here is how migration maps to the frameworks most relevant to industrial operators. NIS2 Directive (European Union) Applicable to medium and large operators of essential services across manufacturing, energy, water, transport, and healthcare sectors in the EU. NIS2 (effective October 2024) requires appropriate technical cybersecurity measures including encrypted communications and access controls for OT systems. Migrating to OPC UA - with its AES-256 encryption and certificate-based authentication - directly addresses the encrypted communications requirement. The OPC UA Wrapper allows EU operators to demonstrate compliance progress on existing infrastructure without a full replacement programme. NERC CIP (North America: energy sector) NERC CIP standards require bulk electric system operators to maintain Electronic Security Perimeters with precise, auditable communication controls. DCOM's dynamic port requirements make this technically challenging to achieve cleanly. Replacing DCOM-exposed OPC Classic connections with OPC UA Wrapper-mediated connections reduces the Electronic Security Perimeter to a single, configurable port significantly simplifying NERC CIP compliance for OT network boundaries. IEC 62443 (global: industrial cybersecurity) IEC 62443 Zone and Conduit models require defined, controlled communication paths between security zones. OPC UA provides the encryption, authentication, and access control primitives that IEC 62443-compliant conduit design requires. The Wrapper approach - containing DCOM to a local zone and exposing only OPC UA at the conduit boundary - is a practical implementation of IEC 62443 conduit security for brownfield environments. FDA 21 CFR Part 11 / EU Annex 11 (pharmaceuticals) Both regulations require electronic records to be trustworthy and traceable, with audit trails for all significant system operations. OPC UA's session-level audit logging, recording connection events, data access, and write operations, supports the audit trail requirements. User authentication via OPC UA certificates or username/password over an encrypted channel supports the individual user accountability requirements of both regulations. 11. Migration by industry Manufacturing (EU and North America) Manufacturing organisations face a dual pressure: NIS2 compliance timelines (EU) and the growing expectation from Tier 1 customers that supply chain OT networks meet minimum cybersecurity standards. The OPC UA Wrapper provides an immediate, demonstrable improvement in security posture without the capital expenditure of a full system replacement, making it straightforward to present to management as a compliance investment with defined ROI. Oil and gas (global: North America, Middle East, North Sea) Wellsite and refinery environments combine decades-old process control infrastructure with modern requirements to stream data to cloud historians, AI analytics platforms, and corporate data warehouses. OPC Classic servers are common in these environments - as are strict uptime requirements that make any migration involving process downtime very difficult to justify. The Wrapper-based approach, which requires no changes to existing servers, is the appropriate migration path for most upstream and downstream oil and gas deployments. Energy and utilities (North America - NERC CIP) NERC CIP Electronic Security Perimeter requirements directly motivate migration away from DCOM. Utilities that have historically run OPC Classic across their OT network for SCADA-to-historian communication can use the OPC UA Wrapper to replace those wide-area DCOM connections with single-port OPC UA connections improving both security posture and NERC CIP auditability simultaneously. Pharmaceuticals (US - FDA 21 CFR Part 11; EU - Annex 11) Batch manufacturing systems using OPC Classic for process data collection face increasing scrutiny in regulatory audits over the adequacy of their audit trails. Deploying the OPC UA Wrapper adds encryption and session-level logging to existing OPC Classic data flows, providing the traceability evidence that 21 CFR Part 11 and Annex 11 auditors require. 12. How to get started OPC UA migration does not need to start with a full programme plan. The most effective approach is to begin with a contained deployment that delivers immediate security benefit and builds organisational confidence in the migration path. Step 1: Identify your highest-exposure OPC Classic connections. Start with OPC Classic servers that are accessible from the IT network, from cloud platforms, or from remote access VPNs. These carry the most DCOM exposure risk and will deliver the most immediate security improvement. Step 2: Deploy the OPC UA Wrapper on those connections. The Wrapper is a plug-and-play deployment - no changes to existing OPC Classic servers, no PLC modifications. Configure the OPC UA side with Sign & Encrypt security. New client connections to those servers now use OPC UA. Step 3: Configure address space and verify data integrity. Use the Wrapper's configuration tool to review the automatically mapped address space. Validate that data values, historical records (if using HDA), and alarms (if using AE) are being correctly bridged. Integration Objects provides step-by-step configuration documentation and video tutorials for this process. Step 4: Establish your certificate management process. Even for a small initial deployment, putting a certificate management process in place from the start saves significant operational overhead later. For larger deployments, implement a Global Discovery Server. Step 5: Plan the broader migration roadmap. With the Wrapper in place and working, plan the phased replacement of remaining OPC Classic servers aligned with system refresh cycles and budget planning. 13. Frequently asked questions Related reading: OPC UA Migration cluster OPC UA Security: The Complete Guide :understanding what you are migrating to OPC Classic Security Risks: How the OPC UA Wrapper Eliminates DCOM Vulnerabilities: the security case for migration How to Configure OPC UA Wrapper Address Space: step-by-step configuration guide OPC UA Wrapper: Cost, Control, and Compliance: the business case OPC Tunnelling with OPCNet Broker - No DCOM: alternative for remote OPC Classic access without DCOM What is OPC UA?: foundational guide to the OPC UA standard