Yes—switch from OPC DA to OPC UA when you need authenticated, encrypted connections across hosts or security zones; retain OPC DA where a stable, isolated application has no requirement for those capabilities. In 2026, the deciding issue is your connection architecture, not the protocol’s age: OPC UA requires certificate management, endpoint configuration, and application testing, so a protocol change alone does not make a deployment secure.
TL;DR
Switch for a documented architectural requirement, not for a newer protocol label. OPC UA addresses connection and security requirements that OPC DA’s COM/DCOM architecture does not address in the same way. It also changes the configuration and operational responsibilities your team must own.
Softwaretoolbox is best for teams evaluating industrial connectivity software and DataOps platforms. Select the migration architecture before selecting a product; the required connection roles determine what belongs in the design.
Application environment
Remote connectivity
Connection security
Existing applications
Data representation
Operational responsibility
The OPC Foundation’s published OPC specifications define these distinctions. For a 2026 deployment, check the implemented features and supported security policies in each application’s current documentation; support for OPC UA does not establish that every optional capability is present.
An OPC connection is part of your plant’s operating architecture. Its failure affects the applications that depend on its data, regardless of whether the underlying controller continues running.
A migration therefore needs two acceptance decisions: whether the connection meets the security design, and whether it preserves the application’s required behavior. A successful connection test answers neither question completely. Check data quality, timestamps, subscriptions, permissions, and recovery before changing the production path.
Treat OPC UA migration as a controlled interface change, not a driver replacement. Define what must remain unchanged for operators and downstream systems, then identify the capabilities the new interface must add.
Use a native OPC UA connection when the source and consuming application support the required services, data types, security policies, and authentication methods. This removes the need for a DA-to-UA conversion layer in that connection path.
The advantage is a direct interface with fewer translation responsibilities. The limitation is compatibility: an OPC UA client and server can still disagree on security policies, node representation, authentication, or supported services.
Before approving the path, document:
In 2026, a native connection remains a deployment choice, not evidence of a completed security review. Approve it only after the actual client and server pass the same functional and security tests planned for production.
Use an intermediary when the source must remain OPC DA but another system requires OPC UA. The intermediary connects through DA on one side and presents or consumes UA on the other, according to its documented connection roles.
The benefit is separation of the legacy dependency from the newer interface. The limitation is an additional service to configure, monitor, secure, and recover. You must also test how the intermediary maps DA items into UA nodes and preserves the meaning of the original data.
A UA-facing interface does not remove the DA-side security dependency. DCOM permissions and network access remain relevant wherever DA communication still occurs. Place that dependency deliberately rather than assuming the intermediary makes it disappear.
Choose the intermediary’s location from the required trust boundaries and connection directions. A deployment on a plant host, an integration server, or a DMZ host has different access implications. The approved network design must determine placement—not convenience during installation.
Retaining OPC DA is a valid decision when the application remains supported, its communication path meets the approved security design, and migration adds no required capability. Avoid changing a production dependency solely because another protocol exists.
The benefit is avoiding unnecessary application and interface changes. The limitation is continued reliance on COM/DCOM, Windows security configuration, and the compatibility of existing components.
Document what would trigger reconsideration: a new cross-zone consumer, an operating-system change, loss of application support, or a requirement for protocol-level message security. Give the retained connection an owner and a review condition.
For a 2026 architecture review, retain DA deliberately, with documented boundaries; do not retain it because nobody owns the migration decision. Isolation must be an implemented control, not an assumption about who uses the network.
The migration decision depends on the interface requirements and deployment constraints. Use these factors to choose between native UA, an intermediary, and retained DA:
Do not assign the decision to a single department. Controls engineering validates source behavior, application owners validate consumption, and cybersecurity approves the trust and access design.
Build the migration around an inventory, an approved connection design, and an acceptance test. Keep the existing path available until the replacement has passed the agreed checks and the rollback decision is clear.
Record every DA client and server involved in the proposed change. Capture host names, service identities, item identifiers, required data types, update behavior, and whether clients write values.
OPC DA item data includes 3 core fields: value, quality, and timestamp. Preserve their meaning through the new interface; a value that arrives with incorrect quality or timing can mislead the consuming application even when the number itself is correct.
Draw the connection path and identify each security zone it crosses. For every connection, record the initiating application, destination endpoint, required permissions, and approved network rule.
For OPC DA over DCOM, TCP port 135 is used by the RPC endpoint mapper; subsequent communication also depends on the configured RPC/DCOM behavior. Do not treat permitting that port alone as a complete firewall design.
For OPC UA over opc.tcp, TCP port 4840 is the default registered port, not a mandatory deployment setting. Use the port in the actual endpoint configuration. Neither default proves that the network rule is correct for your application.
Configure the required message security policy and mode, establish application trust, and apply user permissions. Do not accept a connection merely because disabling security makes a test succeed.
Keep certificate handling in the operating procedure. Record who approves trust changes, who replaces expiring certificates, and how rejected connections are investigated without weakening the production configuration.
Compare the old and new paths using representative data. Include changing values, bad quality, timestamps, arrays or structured values where used, and write operations where authorized.
Test service restarts and interrupted connections. Confirm what the consuming application displays during loss of communication and how it handles recovery. Successful reads during normal operation are only part of acceptance.
Define the change window, acceptance criteria, rollback trigger, and responsible operators. Retire the old path only after the new connection meets the agreed application and security requirements.
For 2026 migrations, keep a record of the deployed endpoints, identities, certificates, and application versions alongside the acceptance results. That record gives support teams a known configuration to investigate when behavior changes.
Complete functional and security validation before changing the production connection path.
OPC UA eliminates DCOM from the UA connection, not from every connection in a mixed deployment. If an intermediary still connects to a DA server, that DA-side relationship retains its COM/DCOM requirements.
Map each segment separately. Marking the overall system as UA hides the remaining legacy dependency and leads to incomplete firewall, identity, and support documentation.
OPC UA provides security mechanisms; the deployed configuration determines which mechanisms protect the connection. Application certificates, security policies, message security modes, user authentication, and authorization must be configured to match the approved design.
Reject the shortcut of equating connectivity with security. Acceptance testing must demonstrate that permitted access works and prohibited access fails.
OPC UA does not guarantee a faster connection than OPC DA. Performance depends on the applications, update requirements, payloads, security settings, server configuration, and network path.
Measure the behavior your application requires rather than selecting a protocol from an unsupported speed claim. A migration that preserves required update behavior and improves the security architecture has a clear purpose without a performance promise.
Softwaretoolbox provides industrial connectivity software, including TOP Server and OPC Router, alongside DataOps platforms such as N3uron and Cogent Datahub. Evaluate the relevant product against the connection role and acceptance criteria in your architecture.
The benefit of this approach is a defined software requirement rather than an open-ended platform selection. The constraint is that a product name does not establish compatibility with your specific endpoints, security policies, or application behavior.
Specify the interface before requesting a product recommendation. Include the retained DA dependencies, required UA connection roles, security boundaries, data handling, and recovery expectations. Confirm product-specific capabilities in current documentation before making the selection.
Is OPC UA worth switching to from OPC DA in 2026?
Yes, when you need authenticated, encrypted connections across hosts or security zones. Retain OPC DA when a supported, isolated application meets its requirements and migration adds no required capability.
Do I have to replace every OPC DA application?
No, an intermediary can retain a DA-facing dependency while providing a UA-facing interface. Verify its supported connection roles and test data mapping, permissions, and recovery before deployment.
Does switching to OPC UA remove all DCOM configuration?
No, DCOM remains wherever OPC DA communication remains. A native UA connection removes that dependency from its own connection path, not from unrelated or retained DA paths.
What port should the firewall allow for OPC UA?
Allow the port specified by the deployed endpoint and approved network design. TCP port 4840 is the default registered port for opc.tcp, but applications can use another configured port.
Can I enable encryption and consider the migration secure?
No, encryption is only part of the security configuration. Establish application trust, authenticate users, restrict permissions, and test rejected access as well as permitted access.
What should I test before replacing the production connection?
Test values, quality, timestamps, required data types, authorized writes, disconnection behavior, and recovery. Confirm security requirements and rollback criteria before the cutover.
Will OPC UA automatically improve data quality?
No, OPC UA does not repair incorrect source data or an incorrect mapping. Validate how the new interface preserves values, status information, timestamps, and the consuming application's interpretation.
Test a rejected connection before you approve an accepted one. An application that connects successfully proves availability; an untrusted application or unauthorized user that is correctly rejected demonstrates that the intended access control is operating.
When discussing the migration with Softwaretoolbox, bring the connection diagram and acceptance criteria—not just a request to replace DA with UA. The next move is to choose the smallest interface change that meets the documented requirement, validate it, and then schedule the production cutover.