


You do not need to rip out a 1990s CNC or a relay-driven packaging line to run a modern MES. The proven route is edge-first: audit what each machine actually exposes, add a gateway that normalises the signals, pilot on a read-only basis, and only add write-back once you trust the data. A Manufacturing Execution System platform can run that pilot with you and scale it into full production once the numbers hold up.
TL;DR:
- Connecting legacy machines to a modern MES starts with a thorough audit of their communication capabilities, ports, and available documentation.
- Building a centralized connectivity layer using protocol drivers and normalizing tags offers scalable, future-proof data management compared to point-to-point links.
- Using OPC UA for on-premises systems and MQTT with Sparkplug B for cloud streaming handles different machine languages and data needs effectively.
- Keeping network segregation, implementing read-only data collection, and delaying write-back until proven reliable minimizes security risks and operational issues.
- Starting with low-cost, non-intrusive pilot setups like Node-RED or ESP32 microcontrollers helps demonstrate value before investing in industrial-grade gateways.
Povezava starih strojev, or connecting legacy machines to an MES, starts with an honest audit of what each asset can tell you, not what you wish it could tell you. Skip this step and every gateway decision downstream becomes a guess.
Build a minimal asset register before you buy anything. For each machine, record:
Once you know what’s physically available, prioritise the tags that move the needle: overall equipment effectiveness (OEE) components, cycle time, stop reasons, and quality flags. These four data points alone justify most pilot projects.
Probe safely. Read-only sampling and non-intrusive polling let you confirm signal quality without touching machine logic, and you should get sign-off from the machine’s owner or maintenance lead before connecting anything, even passively. A legacy system assessment done properly gives you exactly this: a documented picture of what each asset can deliver before a single sensor is wired in.

Point-to-point integration, where each machine gets its own custom link straight into the MES, looks cheap on the first machine and expensive on the tenth. Every new device means a new driver, a new failure point, and a new person who has to remember how it was wired. Maintenance costs multiply roughly in line with machine count, not in line with value delivered.
A dedicated connectivity layer, sometimes called an industrial gateway or connectivity server, solves this by sitting between your machines and everything downstream. It typically handles:
This last point matters more than it sounds. A connectivity layer that speaks native device protocols and outputs OPC UA and MQTT scales far better than wiring each machine directly into whatever system needs it that month. Your MES pulls from OPC UA. Your cloud analytics pulls from MQTT. Neither one waits on the other, and neither one requires a separate integration project.
The operational payoff is a single canonical source of truth. When a new dashboard, a new KPI request, or a new cloud service shows up next year, it consumes the same normalised feed everyone else already trusts.
The honest answer is usually “more than one,” because your machines are speaking different languages and your consumers have different needs.
Use OPC UA for on-premises MES and SCADA integration. It’s a secure, structured, vendor-neutral standard purpose-built for exposing machine semantics to higher-level systems, and it’s what most MES platforms expect to talk to. Beckhoff’s own OPC UA documentation is a solid technical reference if your controls team wants implementation detail.
Use MQTT, ideally with the Sparkplug B payload specification, for cloud and IIoT streaming. It’s lightweight, built for intermittent connectivity, and handles thousands of publish events without the overhead OPC UA carries.
The harder problem is the machine that speaks neither. Most pre-2010 equipment communicates over Modbus RTU or bare serial links, and bridging those takes a few practical options:
Whichever route you take, get the mapping right the first time. Every register you bring in needs an explicit timestamp source, a defined unit, a scaling factor, and a quality flag showing whether the reading is live, stale, or estimated. Skipping this step is the single most common cause of MES dashboards that look plausible and are quietly wrong.
The edge layer, wherever your gateway physically sits, carries the real governance burden. It needs to buffer readings when the network drops, deduplicate repeated polls, and apply a clear replay policy so a reconnect doesn’t flood the MES with backdated values tagged as current.
Network segmentation is non-negotiable. Keep raw Modbus, serial, and proprietary protocols confined entirely to the OT network, and expose only encrypted OPC UA or MQTT traffic upward to IT and cloud systems. A machine that has never been exposed to the internet should not suddenly inherit that exposure because someone plugged a gateway in over a weekend.

Start read-only. Every signal flows from machine to MES, never the other way, until you’ve proven the pipeline is reliable over weeks, not days. Practitioners across the industry consistently flag enabling remote write-back before that governance is proven as the single largest operational risk in brownfield integration projects, and it’s an easy trap to fall into once a pilot looks successful.
Strokovni nasvet: Treat write-back as a separate project with its own sign-off, not a feature you flip on once the read-only pilot works. The two carry entirely different risk profiles.
A staged brownfield-to-cloud path beats a single cutover every time, because it lets you find problems while the stakes are still small. Four phases cover most projects:
Your pilot checklist should stay tight: pick one to three high-value machines rather than the whole floor, validate that incoming data matches what the machine’s own display or logbook shows, test that dashboards and alarms fire correctly under real conditions, and capture baseline KPIs before you claim any improvement.
Budget drivers worth knowing upfront include gateway licence costs, converter and adapter hardware, wiring and labour for machines that need physical rewiring, engineering hours for driver configuration and tag mapping, and testing time before you hand anything to production. Integrating legacy systems is often the costliest phase of an MES rollout, and phased implementation with open standards is the most consistent way to keep that cost from spiralling.
Yes, and for many teams this is exactly where to start before committing capital to a full gateway platform.
Low-code platforms and microcontrollers can enable feasible, low-cost retrofits and proofs of concept, provided you’re realistic about their limits. None of this hardware is built for industrial vibration, temperature swings, or 24/7 duty cycles the way a proper gateway is. Use it to prove the concept and win budget, then upgrade to an industrial-grade gateway once the pilot shows real value and the machine is staying connected permanently.
Running a brownfield pilot in isolation is one thing. Turning it into a permanent, reliable part of your operation without months of extra integration work is another. This kind of platform connects directly to your equipment and tracks the KPIs that matter, performance, downtime, quality parameters, and cost, so a pilot doesn’t stall once it proves itself.

A Mestric™ pilot typically covers the same ground this guide walks through: an asset audit of your priority machines, a connectivity test against your existing OPC UA or MQTT feeds, working dashboards built around your baseline KPIs, and a clear view of where bottlenecks are actually costing you money. Rather than leaving your team to stitch together Node-RED flows and a production MES separately, Such a system gives you a path where the pilot data feeds straight into a system built for the shop floor, with KPI tracking and quality monitoring already built in.
If you have read this far, you likely already have one or two machines in mind worth connecting first. Request an on-site demonstration to see on your own equipment what such a pilot could look like before you commit further budget.
The teams that succeed here spend disproportionate time on inventory and data quality before they touch a single dashboard, because a beautiful dashboard fed by wrong data is worse than no dashboard at all. The teams that struggle almost always rushed write-back before governance caught up, or scoped the pilot too broadly and lost months to engineering sprawl instead of proof. Keep the pilot small, measurable, and read-only, and let its results make the case for the wider rollout. Do not let ambition outrun your audit.
— Andraž
For deeper architecture detail, the ScienceDirect paper on OPC UA retrofitting frameworks covers layered integration academically. For protocol specifics, Beckhoff’s OPC UA overview is the clearer vendor reference. For low-cost pilot patterns, the Springer study on legacy PLC integration documents Node-RED and ESP32 approaches with their real-world constraints.