There is a big gap between the blog posts about Industry 4.0 and what actually happens when you show up to a factory with a laptop and a goal to connect their 15-year-old PLC to a cloud dashboard.

I have been on both sides of that gap. Let me tell you what the second one looks like.

The first surprise: the network

The first thing I learned is that industrial networks are not like office networks. They were not designed for internet connectivity. Many of them were designed to be isolated, and for good reason. Stability and uptime matter more than anything else on a factory floor. A network change that causes 10 minutes of downtime might mean scrapping an entire production batch.

So the first conversation is never about software. It is about network architecture. Where does the PLC sit? What VLAN is it on? Who controls the firewall? Is there any existing connectivity to the outside world, or are we starting from zero?

Half the time, starting from zero is actually the easier scenario. When there is already some half-configured network in place, you have to work around it without breaking the things that are already running.

OPC UA vs MQTT: the actual choice

If you have spent any time in this space, you have heard both of these mentioned constantly. The honest answer is: it depends on the PLC.

OPC UA is the standard for industrial data. It is structured, it handles complex data types, it has built-in security. But not every PLC supports it natively, and even when they do, getting the configuration right can take a full day. You need the right server software, the right certificates, the right node definitions.

MQTT is simpler. It is a lightweight pub/sub protocol that a lot of modern IoT gateways speak. If the factory already has a gateway or if you are adding one, MQTT is often faster to get working. But you lose some of the structure that OPC UA gives you, and you have to implement your own data modeling.

In practice, what I have done most often is use an OPC UA server running on-premise to read from the PLCs, then bridge that to MQTT for the cloud leg of the journey. You get the structured industrial data model and the lightweight cloud connectivity. It works well.

The data quality problem nobody talks about

Getting data out of a PLC is the easy part. Getting good data out is harder.

Industrial sensors drift. Tags get misconfigured. Timestamps are in local time with no timezone info. Values get stuck at their last reading when the sensor disconnects, so you see a perfectly flat line in your dashboard that looks fine but is actually a dead sensor.

I have spent more time building data quality checks than I have spent building the actual pipeline. Things like: is this value changing at all over the last 30 minutes? Is it within the expected physical range? Is the timestamp advancing or is it frozen?

These checks are not glamorous. But they are the difference between a dashboard that operations teams actually trust and one that they look at once and never open again.

Handling downtime gracefully

Industrial systems go offline. Planned maintenance, power outages, network hiccups. Your cloud pipeline needs to handle gaps in data without breaking.

The pattern I use is local buffering at the edge. Before data leaves the factory network, it gets written to a local store first. The cloud ingestion layer reads from that store. If the cloud connection drops, the local buffer keeps filling. When connectivity comes back, the buffer drains in order. No data loss, no duplicates, no gaps in the time series.

This sounds simple but there are details to get right: how large is the buffer? What happens when it fills up? Which data gets prioritized if you need to drop something? Alarms and critical process values go first. Ambient temperature readings from a non-critical area can wait.

The thing that actually determines success

It is not the technology stack. Every major cloud provider has IoT services. OPC UA and MQTT are both fine. The tooling has gotten good enough that the implementation is rarely the blocker.

What determines success is whether the operations team trusts what you built.

I have seen technically excellent systems get abandoned because the dashboards did not match what the operators already knew from experience. They would look at the data, say that does not seem right, and go back to their clipboards. Once that happens it is very hard to recover.

So I build with operators from the start. Show them data early, even before it is polished. Ask them what does not look right. Their intuition about what the data should look like is incredibly valuable, and getting them invested in the outcome early means they become your best testers.

The technology is just the beginning.