OT Data to the Cloud: An Architecture Guide for Engineers

Getting OT data to the cloud comes down to three moves: collect it at the source with OPC UA, move it out over MQTT, and land it in a time-series store the cloud can actually query. Everything else, the security, the buffering, the choice of database, is detail hung on that spine. This guide walks the whole path, from a PLC on the plant floor to a dashboard or an AI model in the cloud, and shows where each piece belongs and why.

First, the term itself. OT to cloud architecture is the design that moves operational technology data, the values produced by PLCs, sensors, and SCADA systems on the plant floor, into cloud infrastructure where it can be stored, analyzed, and acted on. OT is the world of control and safety. IT is the world of databases and analytics. The architecture is the bridge between them, and getting that bridge right is what separates a system you can grow from one you have to rebuild in two years.

I have spent eighteen years on plant floors, most recently leading automation at a manufacturer in the EU, and the design that survives contact with a real plant is almost always the same one. It is not the most sophisticated diagram on the whiteboard. It is the one that respects the boundary between the control network and everything else, and moves data in one direction across it.

The reference architecture

Here is the whole path on one page. Read it left to right, and every section after this is just a zoom into one of the boxes.

Five stages, in order: the source (PLCs and sensors), collection (OPC UA), an edge gateway that translates and forwards, transport (MQTT over TLS), and the cloud, where a broker hands the stream to a time-series store and then on to dashboards, analytics, and AI. The dashed line is the one that matters most, the boundary between OT and IT. Data crosses it outbound only, and nothing on the plant side ever waits on the cloud to keep running.

Collection: getting data out of the PLC

The first question every engineer asks is the practical one: how do I get data out of the PLC without touching the control logic? For most modern equipment the answer is OPC UA. It is the open, vendor-neutral protocol that Siemens, Rockwell, Schneider, and the rest expose, a standard way for equipment to publish its tags securely without a custom driver per device. An edge gateway runs an OPC UA client, subscribes to the tags you care about, and, this is the important part, never writes back. Collection stays read-only, so nothing downstream can ever reach in and command a machine.

The step-by-step of wiring an OPC UA client to a message broker, with working Python, is its own piece in this series. If you want to see the collection half running against a real server today, I built exactly that in a hands-on walkthrough on real-time monitoring without an expensive historian.

Transport: moving data to the cloud

Once the gateway holds the data, it has to leave the plant, and that is MQTT's job. MQTT is a lightweight publish and subscribe protocol built for precisely this situation: many devices, unreliable links, low bandwidth. The gateway publishes each tag to a topic. Anything in the cloud that cares subscribes to that topic. The two sides are decoupled, which is the quiet superpower here: if the cloud link drops, the gateway buffers and the plant carries on, and the data flows again when the link returns.

Two properties make MQTT the right fit across the OT/IT boundary. It runs over TLS, so the stream is encrypted end to end. And it is outbound only from the plant, so you never open an inbound hole into the control network. OPC UA to collect, MQTT to move: that split is the heart of a clean OT-to-cloud pipeline, and it is why the two protocols show up together in almost every serious design.

Storage: where historian data actually fits

In the cloud, the MQTT broker receives the stream and writes it to storage. The natural home for plant data is a time-series database, built for timestamped values that arrive fast and get queried by range. That is not the only option, though. A traditional process historian, a time-series database, and a data lake each fit a different mix of volume, retention, and who consumes the data, and choosing between them cleanly is worth an article of its own, which is next in this series.

Securing the pipeline

Security is not a layer you bolt on at the end. It is the reason the architecture is shaped the way it is. Three rules carry most of the weight. Keep collection read-only, so a compromised cloud can never issue a command to a PLC. Push data outbound only, ideally through a DMZ or a data diode, so there is no inbound path into the control network at all. And encrypt everything in transit with TLS. In eighteen years around safety systems I have never once regretted making the plant side boring and one-directional. Public OT security guidance, including CISA's, lands in the same place: the control network is the crown jewel, and the data pipeline exists to serve it, never the other way around.

The hard part: legacy OT

Most plants are not greenfield. You will meet PLCs older than the engineers who maintain them, serial Modbus links, and equipment that predates OPC UA entirely. The move is not to rip them out. It is to put an edge gateway in front of them that speaks the old protocol on one side and OPC UA or MQTT on the other. Modernizing industrial data infrastructure is almost always this incremental: one line, one gateway, one data stream at a time, with no plant shutdown and no forklift upgrade.

Putting it together

None of these pieces is exotic on its own. The value is in the composition, and in respecting that OT/IT boundary the whole way through. Collect read-only with OPC UA. Move outbound over MQTT and TLS. Land it in a store built for time-series data. Serve it to the people, and increasingly the agents, that can act on it. If you want to see this architecture as running code rather than a diagram, my Industrial RAG and OT-to-cloud pipeline turns exactly this path into something an AI agent can query, and for the wider context of why operational data stayed trapped for so long I wrote the OT/IT divide.

This guide is the map. The rest of the series fills in each leg: the OPC UA to MQTT bridge in Python, a head-to-head on historian versus time-series database versus data lake, and how a unified namespace ties the whole plant's data together. If you are designing one of these pipelines and want a second pair of eyes, I am always glad to compare notes.