![\"A](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\")
Migrating from OPC DA to OPC UA is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two decades, but it is built on Microsoft COM/DCOM, which ties it to Windows, complicates remote access, and is increasingly difficult to secure and support. OPC UA (Unified Architecture) was designed to replace it: it is platform-independent, secure by default, and carries not only live data but also metadata, history, alarms, and methods. This article explains what changes in a migration, what can stay the same, and how to plan a move without disrupting production.
| Property | OPC DA (Classic) | OPC UA |
|---|---|---|
| Transport | COM/DCOM (Windows only) | TCP, HTTPS, WebSocket (any platform) |
| Security | DCOM configuration, little built-in | Built-in: certificates, TLS, signing/encryption, user authentication |
| Data model | Flat tag lists with value/quality/timestamp | Full information model: objects, variables, methods, references |
| Data types | COM variants, limited | Rich type system with arrays, structures, enums |
| History, alarms, methods | Separate specs (HDA, A&E) | Integrated in one address space |
| Discovery | DCOM registry | Local discovery server + network discovery (LDS-ME) |
The most important practical differences are the security model and the fact that OPC UA clients and servers no longer need to run on the same Windows machine or domain.
\n\nInstall an OPC DA-to-UA gateway (from vendors such as Kepware/KEPServerEX, Matrikon, or Software Toolbox, or a UA server with DA compatibility) that exposes existing DA tags as UA nodes. Clients are switched from DA to UA against the gateway while the underlying DA servers remain untouched. This is a quick win for eliminating DCOM, but it keeps the DA layer and may carry a small performance and maintenance cost.
\n\nReplace DA servers with native UA servers. Most major vendors — Siemens, Rockwell, ABB, Schneider, Honeywell, and OPC middleware vendors — now ship UA-native products. The address space is designed from the start: structured tags, units, descriptions, and security are configured once, and all clients share the same information model.
\n\nFor large estates, migrate by area or by client: keep DA for legacy clients that cannot change, expose the same data via UA for new systems, and decommission DA segments as their consumers are retired.
\n\nOPC UA is the industry's direction of travel: secure, platform-independent, and information-rich. A migration from DA to UA is best treated as a managed project — inventory, classify, pilot, and roll out in waves — rather than a big-bang replacement. When the DA layer is removed, the plant gains a communication infrastructure that is easier to secure, easier to extend to edge and cloud, and supported by the whole ecosystem.
Follow an ASP project guide to connect the fundamentals with implementation and acceptance.
![\"Engineering](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\")
Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.
","markdown":"# Migrating from OPC DA to OPC UA\n\n> Migrating from OPC DA to OPC UA is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-06 · Updated: 2026-09-13\n- Reading time: 5 min · Language: English\n\n**Migrating from OPC DA to OPC UA** is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two decades, but it is built on Microsoft COM/DCOM, which ties it to Windows, complicates remote access, and is increasingly difficult to secure and support. OPC UA (Unified Architecture) was designed to replace it: it is platform-independent, secure by default, and carries not only live data but also metadata, history, alarms, and methods. This article explains what changes in a migration, what can stay the same, and how to plan a move without disrupting production.\n\n\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## OPC DA vs. OPC UA at a Glance\n\n| Property | OPC DA (Classic) | OPC UA |\n| --- | --- | --- |\n| Transport | COM/DCOM (Windows only) | TCP, HTTPS, WebSocket (any platform) |\n| Security | DCOM configuration, little built-in | Built-in: certificates, TLS, signing/encryption, user authentication |\n| Data model | Flat tag lists with value/quality/timestamp | Full information model: objects, variables, methods, references |\n| Data types | COM variants, limited | Rich type system with arrays, structures, enums |\n| History, alarms, methods | Separate specs (HDA, A&E) | Integrated in one address space |\n| Discovery | DCOM registry | Local discovery server + network discovery (LDS-ME) |\n\nThe most important practical differences are the security model and the fact that OPC UA clients and servers no longer need to run on the same Windows machine or domain.\n\n## Why Migrate Now\n\n- **Windows and DCOM support is shrinking.** Modern Windows versions make DCOM remote access progressively harder; some vendors are dropping DA server support entirely.\n- **Security.** DCOM configuration is error-prone and a known attack surface; OPC UA provides certificate-based authentication and encrypted communication out of the box.\n- **Platform freedom.** UA clients run on Linux, embedded devices, and cloud services — enabling edge and cloud integration without Windows servers.\n- **Richer data.** UA carries structured data, engineering units, and metadata that make integration with historians, MES, and analytics far easier.\n\n## Migration Strategies\n\n### 1. Wrapper / gateway (lowest risk)\n\nInstall an **OPC DA-to-UA gateway** (from vendors such as Kepware/KEPServerEX, Matrikon, or Software Toolbox, or a UA server with DA compatibility) that exposes existing DA tags as UA nodes. Clients are switched from DA to UA against the gateway while the underlying DA servers remain untouched. This is a quick win for eliminating DCOM, but it keeps the DA layer and may carry a small performance and maintenance cost.\n\n### 2. Native upgrade (preferred for new projects)\n\nReplace DA servers with native UA servers. Most major vendors — Siemens, Rockwell, ABB, Schneider, Honeywell, and OPC middleware vendors — now ship UA-native products. The address space is designed from the start: structured tags, units, descriptions, and security are configured once, and all clients share the same information model.\n\n### 3. Phased hybrid\n\nFor large estates, migrate by area or by client: keep DA for legacy clients that cannot change, expose the same data via UA for new systems, and decommission DA segments as their consumers are retired.\n\n## Step-by-Step Migration Plan\n\n1. **Inventory.** List every DA server, its tags, its clients, and the data flows that depend on it. Include DCOM dependencies (which machines must reach which).\n2. **Classify.** Group by risk: read-only historians vs. live control-facing clients; batch vs. continuous processes; redundant pairs that must switch together.\n3. **Choose the target.** Select the UA server product and the information model layout (folder structure, tag names, data types, units).\n4. **Map tags.** Build a mapping table: DA item path → UA node. Preserve names where possible so HMI screens and historians do not need changes.\n5. **Set up security.** Generate certificates for servers and clients, establish trust, and choose signing/encryption per data flow. Create user accounts or use the UA server's user authentication for restricted areas.\n6. **Test in a lab.** Verify data types (INT vs. UINT, REAL vs. DOUBLE), deadbands, quality semantics, and timestamp behavior against the real devices.\n7. **Pilot one area.** Migrate one non-critical line or process unit, compare live values against the DA path, and run it for a stabilisation period.\n8. **Roll out in windows.** Cut over area by area during scheduled windows, keeping the DA path available until each consumer is confirmed.\n9. **Decommission.** Remove DCOM permissions, uninstall DA servers, and archive the mapping documentation.\n\n## Common Pitfalls\n\n- **Quality and timestamp semantics.** DA quality is an integer code; UA quality is a richer structure. Ensure the gateway or server maps them consistently and that clients interpret them correctly.\n- **Data type mismatches.** A DA \"VT_I4\" may map to Int16, Int32, or UInt32 in UA depending on the server. Verify with a few representative tags before broad cutover.\n- **Deadband differences.** DA deadbands are often percent-of-range; UA supports absolute and percent deadbands per node. Reconfigure to preserve polling behavior and network load.\n- **Certificate renewals.** UA certificates expire; plan renewal with downtime or use servers that support online certificate update.\n- **Forgotten DCOM clients.** Some legacy HMIs and Excel-based tools can only speak DA. Budget for wrappers or replacement of those clients.\n\n## Summary\n\nOPC UA is the industry's direction of travel: secure, platform-independent, and information-rich. A migration from DA to UA is best treated as a managed project — inventory, classify, pilot, and roll out in waves — rather than a big-bang replacement. When the DA layer is removed, the plant gains a communication infrastructure that is easier to secure, easier to extend to edge and cloud, and supported by the whole ecosystem.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide (Migrating from OPC DA to OPC UA, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"opc-da-vs-opc-ua-at-a-glance","title":"OPC DA vs. OPC UA at a Glance"},{"id":"why-migrate-now","title":"Why Migrate Now"},{"id":"migration-strategies","title":"Migration Strategies"},{"id":"step-by-step-migration-plan","title":"Step-by-Step Migration Plan"},{"id":"common-pitfalls","title":"Common Pitfalls"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"opc-da-classic-architecture","title":"OPC Classic (DA/HDA/AE) Architecture and Legacy Integration","summary":"Before OPC UA, the OPC Foundation's OPC Classic specifications — DA (Data Access), HDA (Historical Data Access), and AE (Alarm & Events) — were the de facto…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-da-classic-architecture","markdown_url":"https://wiki.aspotomasyon.com/article/opc-da-classic-architecture.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-da-classic-architecture","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":858,"image":"https://wiki.aspotomasyon.com/assets/social/opc-da-classic-architecture-b2b34512260e.png"},{"slug":"iiot-platform-selection","title":"IIoT Platform Selection: Capabilities and Evaluation Criteria","summary":"The industrial IoT platform market is crowded and loud: every vendor claims edge-to-cloud, digital twins, and AI. Yet the platform decision is one of the most…","category":{"slug":"modern-connectivity","name":"Modern Connectivity"},"url":"https://wiki.aspotomasyon.com/article/iiot-platform-selection","markdown_url":"https://wiki.aspotomasyon.com/article/iiot-platform-selection.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/iiot-platform-selection","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":908,"image":"https://wiki.aspotomasyon.com/assets/social/iiot-platform-selection-f8961916d31c.png"},{"slug":"dcs-vs-plc-selection-guide","title":"DCS vs. PLC — A Comprehensive Selection Guide for Process Applications","summary":"Selecting the right control platform is one of the most consequential decisions in any industrial automation project.","category":{"slug":"automation-systems","name":"Automation Systems"},"url":"https://wiki.aspotomasyon.com/article/dcs-vs-plc-selection-guide","markdown_url":"https://wiki.aspotomasyon.com/article/dcs-vs-plc-selection-guide.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/dcs-vs-plc-selection-guide","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":7,"word_count":1414,"image":"https://wiki.aspotomasyon.com/assets/social/dcs-vs-plc-selection-guide-5527026a81d5.png"},{"slug":"profinet-ethernetip-industrial-ethernet-protocols","title":"PROFINET and EtherNet/IP: Industrial Ethernet Protocols","summary":"Industrial Ethernet protocols have replaced legacy fieldbus systems (PROFIBUS, DeviceNet, ControlNet, Modbus RTU) as the dominant communication technology in…","category":{"slug":"field-devices-instrumentation","name":"Field Devices & Instrumentation"},"url":"https://wiki.aspotomasyon.com/article/profinet-ethernetip-industrial-ethernet-protocols","markdown_url":"https://wiki.aspotomasyon.com/article/profinet-ethernetip-industrial-ethernet-protocols.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/profinet-ethernetip-industrial-ethernet-protocols","published":"2026-05-13T12:07:56+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1666,"image":"https://wiki.aspotomasyon.com/assets/social/profinet-ethernetip-industrial-ethernet-protocols-afc6e1014d6f.png"}],"citation":"ASP OTOMASYON. Migrating from OPC DA to OPC UA. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide"}}