Connecting Legacy PLC to IIoT: What Actually Works in Production

Replace or retrofit? It depends on what's actually at risk

The first choice isn't technical, it's a risk decision. If the controller is a PLC-5-era system, or anything where spare parts are getting hard to find, the honest answer is often to replace it. Adding IIoT connectivity to a controller you already don't fully trust just adds a second thing that can fail on top of the first. Improving the connectivity of a machine you haven't modernized is a bit like putting new wheels on a broken car.

But that's the exception, not the rule. Most "legacy" PLCs in the field aren't actually failing, they're running processes reliably and have been for years. They just weren't designed to talk to anything outside the panel. For that much larger population of machines, replacement is usually unnecessary cost and risk. The practical path is retrofit: leave the control logic alone, and add a translation layer beside it.

A common pattern that comes up again and again: keep the old PLC doing what it's always done, running the equipment and either install a second, modern PLC purely to collect data, or swap out the processor while reusing the existing I/O. The old side stays serial or fieldbus; the new side connects to the IIoT platform over Ethernet.

The protocols and gateways people are actually using

There are many different legacy industrial protocols still in use: Modbus (RTU and TCP), DH+, Modbus Plus, ControlNet, DeviceNet, ASI, plain serial. No single adapter can talk to all of them, which is why there are so many gateway products on the market. In practice, the tools that keep coming up are:

• Protocol gateways from the major vendors Schneider, Rockwell, and Siemens all sell transitional hardware aimed at bridging their own legacy protocols to Ethernet-based systems.
• Third-party gateways like Prosoft's protocol converters, RedLion's DA-series units, and RTA gateways, which specialize in exactly this bridging problem and often support a wider protocol list than a single vendor's own hardware.
• Node-RED as a lightweight bridge, reading Modbus TCP from the PLC, converting values into a clean internal representation, and publishing over MQTT. It's a popular choice precisely because it's cheap to prototype with and forces you to define your own tag names rather than exposing raw PLC registers directly.
• Siemens Industrial Edge, for shops already inside the Siemens ecosystem, bundling edge compute with the connectivity layer.

Do PLCs expose this data by default? Generally, yes, but "available" and "accessible without extra work" are different claims. Some values sit in registers you can poll directly. Others require additional logic in the PLC program to move internal data into a readable location, and how much of that is needed depends heavily on the specific controller, its program structure, and which protocol you're using to reach it. Assuming zero PLC-side changes are needed is a common planning mistake.

The rule almost everyone agrees on: don't touch the control loop

Once you get past which tool to use, there's clear agreement on where the gateway or edge device should sit and what it should or shouldn't be allowed to do:

• Handle the legacy protocol at an industrial gateway or edge computer inside the plant, not in the cloud. Every extra cloud-side special case for an old, unusual protocol becomes more work to maintain over time.
• Keep that connection read-only unless there's a specific, separately reviewed reason for the IIoT platform to write back into the control system. Reading production data and writing to a running process are very different risk levels, and mixing them up is how small integration projects turn into safety incidents.
• Never expose the PLC, an HMI, or a raw Modbus/serial link directly to the internet. All outbound data should leave the plant through a controlled, secure path using an authenticated, encrypted protocol and nothing from outside should be able to reach into the plant network at all.
• Normalize the data at the edge, not downstream, attach units, a quality flag, and a proper source timestamp before the value ever leaves the plant. Skipping this step means every legacy machine becomes a permanent one-off exception for whoever consumes the data later.
• Buffer locally. Old controllers and old networks weren't built for aggressive polling, and connectivity to the outside world isn't always reliable. Local buffering absorbs both problems.

None of this is unusual, it's the same "translate at the edge, don't disturb the process" approach that shows up in almost every well-run OT/IT project, no matter which gateway hardware is being used.

Before you connect anything, know what you actually need

There's a discovery step that's easy to skip and expensive to skip: figuring out, machine by machine, which protocol is really in use, what the register or tag map looks like, the data types and word order, the scaling, the update rate, and the timestamp source and whether any of it can be read without modifying PLC logic. Modbus TCP support and a known register list are necessary, but they're not automatically sufficient; the values you actually care about aren't always mapped, and polling too aggressively can visibly affect an older controller's scan time or an already-strained network.

And sometimes the PLC simply doesn't expose anything useful. In those cases, the practical move isn't to fight the controller it's to tap the signals that actually tell the machine's story: cycle start/stop, spindle or run status, alarm states, part counters, energy meters, or an external sensor bolted on where the controller gives you nothing. The goal isn't total visibility into every register; it's identifying the minimum set of signals that describe what the machine is actually doing, and building from there.

Connectivity solves the wire problem. It doesn't solve the meaning problem.

This is the part that rarely gets enough attention in "how do I connect my PLC" discussions, and it's usually the actual bottleneck.

A gateway can hand you a stream of values. It cannot tell you that is hydraulic pressure on press line 2, that is a motor running state, or that matters at all. That kind of context what a tag means, what units it's in, what a normal range looks like, which machine it belongs to is usually scattered across PLC comments, electrical drawings, old spreadsheets, historian files, and the memory of the one engineer who set up the line years ago. Multiply that across hundreds or thousands of tags and dozens of machines, and tag mapping not the gateway, ends up being the biggest cost of a connectivity project. It's also a weak point: if the one person who understands the original logic isn't around, the project stalls.

This is where AI-assisted tag mapping earns its place. Rather than having engineers manually inspect every register from scratch, an AI system can analyze tag names, program comments, engineering documents, and historical data patterns, then propose standardized mappings for human review:

The AI isn't making unsupervised decisions about machine data, it's compressing the discovery work so engineers spend their time on validation and edge cases instead of manually cataloguing every signal on every PLC. Once a mapping pattern is approved, it becomes reusable: the same motor-running-state pattern doesn't need to be re-derived from scratch on the next line, or the next site.

Being able to reuse that work is what turns one successful integration into a foundation for the whole plant, data that can be compared across lines, less dependence on what one engineer happens to remember, and a shorter path to what actually matters: condition monitoring, predictive maintenance, energy tracking, and production performance analysis that work consistently across the plant, not just on the one machine someone happened to document well.

How INSUS approaches it

We treat legacy connectivity as an industrial execution problem, not a one-off integration task. In practice that means:

1. Identify a priority machine, line, or equipment family rather than trying to do everything at once.
2. Assess the available PLC interfaces, protocols, and whatever technical documentation actually exists.
3. Establish a secure, read-first gateway and edge connection inside the OT zone.
4. Extract the available tags and any related engineering context.
5. Use AI to classify, group, and propose standardized tag mappings.
6. Validate the proposed mappings with the engineers and operators who actually know the equipment.
7. Publish only the approved, structured data to the IIoT or analytics platform.
8. Reuse the validated mapping model across similar machines and sites, so the second and third machines are much cheaper and faster to connect than the first.

The point isn't to make old equipment look modern for its own sake. It's to make production assets that are already working reliably, visible, measurable, and improvable without introducing the operational and financial risk of an unnecessary rip-and-replace program.

Modernization without disruption

The choice was never really "leave it disconnected" or "replace everything." Protocol gateways and edge integration solve the wire problem. AI-assisted tag mapping solves the meaning problem. Applied together, with proper OT/IT boundaries and engineering validation in the loop, they turn a plant's oldest, most valuable-but-silent machines into a real source of data without touching the control logic that's kept them running for years in the first place.

Start with the machine that matters most, prove the value, and scale the pattern from there.
From legacy connectivity to scalable industrial intelligence, INSUS helps manufacturers make existing machines ready for the next generation of operations.