From PLC to AI: How to Make Legacy Factory Systems Smart Without Ripping Them Out

Your Equipment Isn’t the Problem

There’s a PLC on your factory floor that’s been running reliably since 2007. It controls a critical process, it does exactly what it was designed to do, and the thought of replacing it makes your production manager visibly uncomfortable.

I get it. That PLC isn’t the problem.

The problem is that it speaks Modbus RTU over serial, your MES was built in 2016 expecting Ethernet/IP, your ERP vendor just rolled out an AI-powered demand forecasting module that needs real-time production data, and somewhere between these three systems is a production supervisor with a clipboard updating a spreadsheet every shift.

We see this constantly. It’s the reality for the majority of UK manufacturers we work with across the North West and beyond. Deloitte’s 2025 survey found that 92% of manufacturers believe smart manufacturing is their primary driver of competitiveness — yet only 29% have adopted AI or machine learning at scale. The gap isn’t ambition. It’s integration.

The good news: bridging that gap doesn’t require replacing a single machine on your shop floor.

A Bridge: Not a Bulldozer

The industry has moved away from “rip-and-replace” and with good reason. The cost, the downtime, the risk to proven production processes, none of it is justified when the equipment itself works perfectly well. What doesn’t work is the communication layer around it.

The modern approach uses a middleware architecture, a translation layer that sits between your legacy equipment and your modern platforms, converting industrial protocols into formats that AI, cloud, and enterprise systems can consume.

I explain it to clients like this: imagine two colleagues who speak different languages. Neither needs to learn a new one. You just need someone in the middle who understands both.

In practice, this architecture has four layers. I’ll walk through each, because understanding them is the difference between making a good investment and getting sold something you don’t need.

Layer 1: Edge Gateways

Small, industrial-grade computing devices installed alongside your existing PLCs and SCADA systems. They connect using the protocols those machines already speak: Modbus RTU, Modbus TCP, Profibus, PROFINET, EtherNet/IP, BACnet, or whatever proprietary protocol your equipment happens to use.

The important bit: edge gateways read data from your equipment. They don’t modify control logic, don’t interfere with existing processes, and don’t introduce risk to proven operations. Your PLC continues running exactly as it always has. The gateway just listens.

Our approach is to integrate directly with existing machine controllers wherever possible, but we also supplement with IoT sensors, vibration, temperature, power monitoring, environmental, to fill the gaps where the built-in electronics don’t capture what we need. It’s rarely one or the other. Most real-world deployments use a combination of both.

That’s usually the first thing production managers want to know, and the answer that lets them relax.

Layer 2: Protocol Translation

This is where the real work happens. The gateway converts legacy protocol data into modern industrial standards:

OPC UA is the gold standard for machine-level communication. It doesn’t just move data, it describes what the data means. A raw register value of “1247” from a Modbus PLC becomes something useful: “Spindle speed, Machine 7, Line 3, 1247 RPM, normal range 1100-1400.” That context is what makes AI possible later.

MQTT is a lightweight protocol built for high-volume data transport. Where OPC UA is brilliant at the machine level, MQTT is brilliant at moving data across networks, factory to cloud, site to site, shop floor to ERP.

The two work together. OPC UA handles rich machine communication. MQTT handles efficient transport. Most gateways speak OPC UA to your equipment and MQTT to everything else.

Every factory is different. Different machines, different ages, different protocols, different quirks. That’s why we build bespoke integration layers, custom-designed around each client’s specific equipment and processes. Generic, off-the-shelf middleware rarely handles the messy reality of a real production floor. A purpose-built system fits your factory exactly — not one you have to work around.

Layer 3: The Unified Namespace

This is the concept that stops your integration turning into spaghetti.

Without it, every system talks directly to every other system. Point-to-point connections multiply, and within a year you’ve got a web of custom integrations that nobody fully understands and everyone’s afraid to touch. I’ve seen factories where a single software upgrade breaks three other systems because nobody mapped the dependencies.

A Unified Namespace solves this. It’s a central MQTT broker where every system publishes its data once, using a consistent structure based on the ISA-95 standard:

Enterprise / Site / Area / Line / Cell / Device

So your data might look like:

AcmePlastics/Northwich/Production/Line3/CNC7/SpindleSpeed
AcmePlastics/Northwich/Production/Line3/CNC7/ToolWear
AcmePlastics/Northwich/Quality/Line3/DefectCount

Any system that needs data subscribes to the topics it cares about. Your MES subscribes to production data. Your ERP subscribes to output metrics. Your AI models subscribe to sensor readings. Your energy management subscribes to power consumption.

No system needs to know about any other system. No point-to-point mess. No integrations that break when you upgrade something. The namespace is the single source of truth, and every system, old or new, participates equally.

Layer 4: AI Services

With clean, real-time data flowing through a unified namespace, AI moves from theoretical to practical:

Predictive maintenance, consuming vibration, temperature, and power data from legacy sensors, spotting degradation patterns weeks before failure. This is where we see the fastest payback for most clients.

Quality prediction, correlating process parameters across multiple machines to identify conditions that produce defects. Catching problems at the source rather than at final inspection.

Anomaly detection, monitoring the entire data stream for patterns that deviate from normal operation. The kind of cross-system issues that are invisible when each machine is monitored on its own.

These services can run on local edge hardware for time-critical decisions or in the cloud for heavy analytics. Most real-world implementations end up hybrid, edge inference for immediate responses, cloud processing for strategic analysis.

What This Actually Looks Like

I’ll give you a concrete example, because the architecture diagrams only tell half the story.

A manufacturer running 12 CNC machines across two production lines. Mix of ages and vendors, some on Modbus, some on PROFINET, two older units on proprietary serial protocols. The MES captures basic job tracking from manual operator entry. The ERP receives end-of-shift summaries via spreadsheet upload. Maintenance is reactive — when something breaks, it gets fixed.

After integration: edge gateways on each machine, reading spindle speed, feed rate, vibration, power draw, and tool usage through existing protocols. Data flows through protocol translation into a unified namespace. The MES receives production data automatically. The ERP sees live output and quality metrics. A predictive maintenance model flags early-stage spindle bearing wear on one machine, three weeks before it would have failed mid-run.

No machines replaced. No production interrupted during installation. No operators retrained on new equipment. The factory just became visible. And that visibility unlocked maintenance savings, quality improvements, and planning accuracy that simply weren’t possible before.

Documented outcomes across similar UK implementations: 32% productivity gains, 28% reduction in operating costs, and 3-5x return on investment.

Plain English Access to Factory Data

One of the things we’re most excited about, and already building for our own clients, is natural language interfaces on top of factory data.

We’re working with a manufacturing client in the North West who captures huge amounts of operational data but historically had no way for their team to do anything useful with it. Using machine learning and natural language processing, we’ve built interfaces that let their shop floor staff, people who aren’t technical, ask questions of their own data in plain English:

“What was the average cycle time on Line 3 last Tuesday?”
“Which machines had the most unplanned stops this month?”
“Show me the defect rate trend for the paint shop this quarter.”

This matters because it puts operational data in the hands of the people who actually understand the production process. Today, getting these answers means finding someone who can query a database or build a report. With a natural language interface, anyone with the right permissions can just ask.

Siemens is pursuing the same direction with its Industrial Copilot for Operations, a generative AI tool for the shop floor that can interpret sensor logs, generate maintenance reports, and suggest root causes. It’s designed to run on-premises, which addresses the data sovereignty concerns that rightly keep many UK manufacturers from sending production data to public cloud services.

The Role of AI Agents in Integration

A recent development we’re seeing in our own work: agentic AI systems that can automate parts of the integration process itself.

One of the most time-consuming parts of any legacy integration project is discovery, identifying every data point from every machine, understanding what each register value means, mapping relationships between systems. Traditionally, that’s an engineer with a manual and a lot of patience.

AI agents are starting to change this. They can explore protocol structures, identify data semantics from context, and auto-configure integration mappings. We’re using AI agents in our own development and infrastructure work and the productivity gains are real — but I’ll be honest, this is still emerging technology for industrial applications. It points to a future where integration becomes significantly less labour-intensive, but we’re not fully there yet.

Common Concerns: Honest Answers

“Will this affect our production?”
No. Edge gateways read data passively. They don’t modify PLC logic, don’t inject commands, don’t interfere with control systems. Installation happens during scheduled maintenance windows, but the gateway itself is non-intrusive.

“Our machines are too old.”
If it has any electronic controller, even a decades-old PLC on serial Modbus, it has data we can extract. For purely mechanical equipment with no electronics, retrofit IoT sensors (vibration, temperature, power monitoring) can be added without touching the machine itself.

“We don’t have the IT skills in-house.”
Almost nobody does, and that’s fine. The intersection of industrial automation protocols and modern IT platforms is specialist territory. That’s exactly where we operate. Your team focuses on understanding the insights, we handle the plumbing.

“What about security?”
Good question, and one we take seriously. Edge gateways sit on a segregated OT network with no direct internet access. Data flows outbound only, factory floor to data platform, with no inbound connections to production equipment. OPC UA has built-in encryption and authentication. Done properly, this is actually more secure than the current practice of engineers plugging laptops directly into PLCs for diagnostics.

“What does it cost?”
A focused pilot, one production line, edge gateways deployed, data pipeline established, initial analytics delivered — typically runs in the tens of thousands, not hundreds of thousands. Payback periods of 6-18 months are standard for predictive maintenance. And for UK manufacturing SMEs, the Made Smarter programme offers grant funding that can significantly reduce the initial outlay. Most of the manufacturers we speak to haven’t heard of it, it’s worth checking whether you’re eligible.

Where to Start

If this sounds relevant to your operation, here’s the pattern we recommend:

Start with your biggest headache. Not your most complex system, the machine that breaks most often, the line with the highest scrap rate, the bottleneck everyone mentions in production meetings. Go where the value is obvious and measurable.

Get data flowing first. Before any AI model can help, you need clean, contextualised data from your production environment. Edge gateways and protocol translation come before anything clever.

Structure it properly from day one. Build your unified namespace even if you’re starting with a single line. Adding more machines, more lines, or more sites should be incremental, not a redesign.

Deliver a quick win. A predictive maintenance alert that prevents a breakdown. A quality trend that spots a drifting parameter. A real-time OEE dashboard that replaces a manual spreadsheet. Something tangible that demonstrates value to the people on the shop floor, not just the board.

Then expand from evidence. Once you’ve got real numbers from a real pilot, the business case for rolling out further writes itself.

The Machines Work. Let’s Make Them Talk.

Your factory equipment has been working for years, decades, in some cases. The machines aren’t the problem. The silence between them is.

Modern integration technology lets you give every machine a voice, connect every system into a single coherent picture, and apply AI to the data, all without replacing the kit you’ve already paid for.

The tools are proven. The standards are mature. The business cases are well documented. And for UK manufacturers, programmes like Made Smarter can help fund the first step.

At OneTek, this is what we do. We connect legacy and modern systems into intelligent, unified operations, bridging the gap between shop floor equipment and the business platforms that need its data. If you’ve got machines that can’t talk to each other, let’s have a conversation.