Five pitfalls when connecting legacy manufacturing equipment

A building materials manufacturer thought one section of its plant contained around 3,000 connected assets. When automated discovery was introduced, the count passed 15,000. The equipment had not suddenly appeared; the manufacturer had been operating with a much narrower picture of its own network than reality justified.

Any manufacturer planning to connect older machines to MES, analytics or enterprise systems should take that discrepancy seriously. A gateway can retrieve information without revealing whether the surrounding network is resilient, the data is understandable or an old controller can tolerate new traffic. Those are the mistakes that can turn a modest integration project into long-term operational debt.

1. Trusting the existing asset inventory

An equipment register may identify the machines on a line without accounting for the controllers, embedded PCs, remote-access devices and instruments that communicate around them. Some have been installed by suppliers, others added during years of upgrades. An integrator working from an incomplete list can easily overlook the systems most vulnerable to disruption or the network paths that already exist.

Andrea Carcano, co-founder and CEO of Nozomi Networks, describes asset discovery as an uncomfortable first step for many manufacturers. “Installing this kind of technology is like turning on the lights in a dark room,” he says. “Suddenly you start to see things you did not expect. Once the light is on, you then have a journey to fix what you discover, and depending on the findings that journey can take years.”

Because an incomplete inventory can leave plant teams blind to the equipment most likely to disrupt production, discovery needs to capture far more than IP addresses. Teams should record equipment ownership, control-system dependencies, firmware, protocols, existing connections and the operational consequence of losing each asset, while choosing discovery techniques that do not introduce new risk. Passive monitoring cannot identify every silent device, but intrusive active scanning can destabilize sensitive controllers. The National Institute of Standards and Technology (NIST) recommends testing such tools before deployment and using planned outages for potentially disruptive scanning.

Buyers should ask who will verify the inventory with plant engineers, how undocumented connections will be handled and whether the supplier can assess equipment without jeopardizing production. A discovery exercise that produces a longer spreadsheet, but no understanding of the process has not solved the problem.

2. Assuming a connected machine has a reliable network

The network that comfortably supplies daily machine-utilization figures may be wholly unsuitable for moving high-volume camera images or supporting decisions that must return to the equipment within a production cycle. Older plant networks have often been extended incrementally, with new switches, wireless links and applications introduced without revisiting the capacity or resilience of the entire route.

Samuel Pasquier, vice president of product management, industrial IoT networking at Cisco, draws a distinction between proving connectivity in a lab and running an application across a factory. “It is very easy to do a proof of concept in a lab,” he says. “But when you start to deploy in production, the network becomes super critical because your environment is much wider, much bigger. You need to interconnect things so you can have more information.”

Before buying gateways or edge platforms, manufacturers need to specify what the connection must deliver. A historian feed might tolerate brief delays; machine vision, mobile equipment or time-sensitive monitoring may not. Network design should account for bandwidth, latency, interference, connection loss and how information is buffered or recovered when systems become unavailable.

The acceptance test should run with normal production traffic, not just on an empty line at commissioning. Ask what happens if a switch fails, an industrial PC restarts or a link to the cloud disappears. Where the process depends on timely action, establish which functions continue locally and which can safely wait.

3. Mistaking raw machine tags for usable data

A number such as 1,025 might be a cycle count, a temperature or a setting, depending on the equipment that produced it. Extracting that value through a legacy protocol does not tell a maintenance application what it represents, which product was running or whether the machine was producing, idle or undergoing setup. Such information can be obvious to the operator and invisible to a new software system.

Aron Semle, CTO of HighByte, uses the example to explain why connectivity alone cannot support repeatable analytics. “I sometimes put a number on a slide and ask the audience what it means,” he says. “There is no answer. That is effectively the context an LLM has if you just give it raw industrial data.”

A useful connection needs an agreed data model, not just a list of addresses to poll. Asset identity, engineering units, timestamps, product or batch reference and operating state may all be necessary to interpret a measurement correctly. Plant specialists must validate those relationships, particularly when a machine’s original documentation is incomplete or its logic has changed over time.

Suppliers should be asked to demonstrate a small set of genuinely usable information, from source tag to downstream application, rather than a dashboard containing hundreds of unexplained values. The test is whether an engineer unfamiliar with that controller can understand what the information means and judge whether it is trustworthy.

4. Building another integration that cannot be reused

A gateway installed to feed one maintenance dashboard can become the first of a dozen overlapping connections, each with its own naming conventions and mappings. That arrangement may satisfy an immediate project, but every software replacement or additional factory then requires somebody to rediscover how the original integration works.

Semle has watched that accumulation play out across manufacturing estates. “If you look across ten, 15 or 20 years, you find little pieces of connectivity between all these different systems,” he says. “Then you go to the next plant, and it has a completely different OT stack, or perhaps the same stack implemented differently. You end up with this spaghetti architecture across many factories.”

An event-driven architecture using MQTT can reduce unnecessary point-to-point dependencies, while a unified namespace can provide consistent structures for shared operational information. Neither removes the hard work of translating older protocols and agreeing what each data item means. Magnus McCune, CTO of HiveMQ, argues that the unified namespace is fundamentally a governance pattern: “Every site, every system and every AI agent cannot keep naming and integrating data in its own structure. Site one cannot be completely different from site two.”

Eli Lilly offers a practical example, having developed an Equipment Connectivity Platform using MQTT and Sparkplug B to bring stand-alone laboratory and manufacturing instruments into a standardized connection with higher-level systems. For a buyer, the question is whether the next machine or site will be cheaper and simpler to integrate than the first, with common models and clear ownership rather than another custom interface.

5. Treating security as something to add afterward

The controller that has worked reliably for 20 years may be the one least able to tolerate a firmware change or unplanned restart. Putting a gateway beside it can give the business valuable information, but it may also create an access path into equipment designed long before current cybersecurity expectations. The network connection changes the plant’s risk profile, rather than merely completing a data-engineering task.

Nick Haan, field CTO at Claroty, explains why standard IT remediation cannot always be applied in production. “Updating a PLC means downtime,” he says. “Some producers may only have a downtime once every two, three or four years and do the updates then. In between, they cannot do updates. That means you need other ways to protect those devices.”

Those protections should be designed before connectivity is approved. Segment older assets from unnecessary traffic, restrict which applications and users can reach them, control supplier remote access and monitor unexpected communications. The IT security team must understand the exposure, while OT engineers establish what can be changed safely and what the production consequences would be if a control blocks traffic.

A supplier should therefore provide a clear communications diagram, access and credential arrangements, a plan for patching or compensating controls and a tested response if its solution fails. The cheapest connection can become an expensive one if it introduces an outage that the plant cannot recover from quickly.

Connecting legacy equipment is rarely a matter of making old machines behave like new ones. The sounder approach preserves the control systems that already run production while building a managed way to understand and use their information. Successful projects can be judged by how safely the connection operates, how useful the data becomes and how readily the same approach can be repeated elsewhere.