The bottom line
Most IIoT projects stall not because the technology fails, but because OT and IT teams operate with different standards, priorities, and risk tolerances. Convergence only works when there is a defined data architecture that bridges both worlds - not a pilot that sits in a corner.
In This Article
What OT/IT Convergence Actually Means
OT (Operational Technology) refers to the systems that run physical plant operations: PLCs controlling manufacturing lines, SCADA systems monitoring utilities and processes, DCS systems in continuous process industries, and the industrial networks - Profibus, Modbus, EtherNet/IP - that connect them.
IT (Information Technology) refers to the enterprise systems: ERP for business processes, cloud analytics platforms, databases, and the corporate network and internet-connected infrastructure that business functions run on.
Convergence means connecting these two worlds so that operational data - machine states, process parameters, production counts, energy consumption - flows into business intelligence without manual extraction. In theory, this enables real-time production visibility, AI-driven optimisation, and predictive capabilities that were previously impossible. In practice, 68% of IIoT projects stall before reaching production scale. (Source: Gartner IoT Survey, 2024)
OT/IT convergence is not a technology problem with a technology solution. It is an architecture and governance problem that technology can solve - once the architecture and governance are right.
The 68% Failure Rate - and Why
The stall rate is not because the technology does not work. OPC-UA, MQTT, and modern cloud IoT platforms are mature, reliable, and capable. The stall happens because organisations underestimate the non-technical dimensions of OT/IT convergence: network architecture, security model, organisational ownership, and the fundamentally different operational priorities of OT and IT teams.
OT teams prioritise uptime above all else. A PLC that controls a production line cannot be patched, restarted, or modified during a production run - and often cannot be touched at all without a planned maintenance window. The IT team's instinct to push updates, enable remote access, and connect systems to the internet is incompatible with this constraint until specific security measures are in place.
The result is a predictable standoff: IT wants to connect OT systems to the cloud. OT refuses because it represents a security and uptime risk. Neither side is wrong - but without a defined architecture that addresses both concerns, the project stalls in the design phase.
Three Architecture Mistakes That Cause Stalls
The first mistake is connecting OT directly to the cloud. Sending PLC data straight to an Azure IoT Hub or AWS IoT Core without an edge layer is architecturally fragile and operationally risky. Edge computing - a local gateway that buffers data, applies protocol translation, and manages the OT-to-cloud handoff - is not optional. It is the architectural keystone that makes everything else reliable.
The second mistake is ignoring network segmentation. OT networks must remain operationally isolated from IT networks. Data flows one way - from OT to IT - through a defined and monitored DMZ. Any architecture that places OT and IT systems on the same network segment, or that allows bidirectional traffic without explicit security controls, will be rejected (correctly) by the OT team and the plant engineering function.
The third mistake is treating the data flow as the end goal. Getting sensor data into a cloud platform is a means, not an end. Projects that focus on the data pipeline without a defined analytical use case - a specific decision that will be made differently because of the data - consistently fail to demonstrate value and lose executive sponsorship before they reach scale.
An edge layer is not optional in OT/IT architecture. It is the component that makes the connection between plant-floor systems and cloud analytics secure, reliable, and operationally acceptable to the OT team.
The Protocol Problem
Industrial communication protocols are not standardised. A manufacturing plant built over 20 years will typically have PLCs communicating over Modbus (1979 standard, still in use), Profibus, DeviceNet, EtherNet/IP, and possibly PROFINET - each requiring a different driver and a different approach to data extraction.
OPC-UA (OPC Unified Architecture) was designed to solve this: a modern, secure, platform-independent protocol that abstracts the underlying industrial protocol and presents a consistent interface to any consuming application. For new equipment, OPC-UA is the right standard. For existing equipment, OPC-UA connectivity often requires a middleware gateway - a Kepware or similar industrial connectivity platform - that translates legacy protocols into OPC-UA.
MQTT is the complementary protocol for the other side of the edge: the connection from edge gateway to cloud. Lightweight, publish-subscribe, and optimised for high-frequency data with intermittent connectivity, MQTT is the de facto standard for IIoT data transport. Together, OPC-UA on the OT side and MQTT on the cloud side, with an edge gateway translating between them, form the protocol backbone of a practical OT/IT architecture.
Building Convergence That Sticks
A convergence programme that reaches production scale has four non-negotiable components: a joint OT/IT steering team (not separate workstreams), a defined edge architecture agreed before any connectivity work begins, a pilot scope limited to one asset or one production line with a specific analytical use case, and a security model reviewed by both OT engineering and IT security before any data leaves the OT network.
The pilot scope discipline is critical. Every successful large-scale IIoT deployment started as a small, well-defined pilot that proved the full stack - from sensor to insight - on a single asset or line. Trying to connect an entire plant at once is how 68% failure rates happen. One line. One use case. Full stack. Prove it. Then scale.
The organisational model matters as much as the technical architecture. Assign a dedicated convergence engineer whose role sits between OT and IT - someone with enough OT knowledge to earn the plant engineering team's trust, and enough IT knowledge to build the cloud integration. Without this bridge role, the organisational standoff will outlast the technology project.
OT/IT convergence fails when it's treated as an IT project. The shop floor has constraints enterprise IT doesn't - legacy equipment, 24/7 uptime, safety-critical systems that can't tolerate a failed update. The architecture decisions have to account for all of it from day one. The companies that get this right involve the OT team from the first design session, not the first deployment.