Most manufacturing plants in the United States run on equipment that predates the smart factory era. A 2003 CNC mill, a PLC installed during the Clinton administration, a packaging line that speaks a serial protocol nobody under forty has heard of.

These machines still make good parts, which is exactly why nobody wants to rip them out. The problem appears when the business asks for data: OEE dashboards, downtime analysis, energy monitoring, predictive maintenance. Suddenly the plant discovers that its most productive assets are also its most silent ones.

The good news is that you do not need a capital project to make legacy equipment talk. What you need is a structured approach to connectivity. Here is how to do it, step by step.

Step 1: Audit what you actually have

Before buying anything, walk the floor and build an asset inventory. For every machine you want data from, record four things: the controller make and model, the communication interface it exposes (Ethernet, RS-232/485, proprietary fieldbus, or nothing at all), the protocol it speaks, and the firmware version.

This sounds tedious, and it is. It is also the single highest-value activity in the entire project. Plants that skip this step end up buying gateways that cannot talk to half their equipment, or discovering mid-project that a critical machine only exposes data through a maintenance port the vendor locked years ago.

A typical brownfield audit in a mid-sized US plant surfaces somewhere between five and fifteen distinct protocols: Modbus RTU and TCP, Allen-Bradley DF1 and EtherNet/IP, Siemens S7, Fanuc FOCAS, GE SRTP, Mitsubishi MELSEC, plus a few vendor-specific oddities. Write them all down. This list drives every decision that follows.

Step 2: Decide which data matters before you collect any of it

The instinct is to collect everything and sort it out later. Resist it. Every tag you poll consumes network bandwidth, gateway capacity, and storage, and most of it will never be looked at.

Start from the business question instead. If the goal is downtime analysis, you need machine state, fault codes, and timestamps. If it is quality, you need process parameters tied to part IDs. If it is energy, you need power draw per asset. A focused list of 20 to 50 tags per machine usually covers the first two or three use cases. You can always expand later; it is much harder to untangle a data lake full of unlabeled noise.

This is also the moment to define naming conventions. A tag called Line3_Press2_MotorTemp_degF will still make sense in five years. A tag called N7:42 will not.

Step 3: Put a protocol translation layer between machines and everything else

Here is the architectural decision that determines whether the project scales or stalls. You have two options for getting data out of legacy controllers.

The first is point-to-point integration: custom drivers, vendor utilities, or scripts that connect each machine directly to each consuming application. This works for one machine and one dashboard. It collapses at plant scale, because every new machine or application multiplies the number of connections you have to build and maintain.

The second, and the one that has become standard practice in industrial environments, is a dedicated connectivity layer: an industrial connectivity platform such as Kepware by Velotic that sits between the machines and the applications. The platform speaks the native protocol of each device on one side (Kepware alone ships with more than 150 drivers covering most controllers built in the last three decades) and presents the data through open standards on the other. Applications no longer care whether the source is a 1998 Modbus device or a brand-new OPC UA server; they see one consistent interface.

The practical benefit for legacy equipment is significant. A serial-only machine gets connected through a serial-to-Ethernet converter, the connectivity server polls it in its native protocol, and from that point on it behaves like any modern asset. No PLC reprogramming, no firmware upgrades, no downtime beyond the commissioning window.

Step 4: Normalize the data into open standards

Getting bits off the machine is only half the job. The other half is making those bits usable by systems that were never designed for factory floors: MES, historians, cloud analytics, ERP.

Two standards do most of the heavy lifting here. OPC UA provides secure, structured, vendor-neutral access for on-premises systems such as SCADA and MES. MQTT, often with the Sparkplug B specification, handles lightweight publish-subscribe messaging to cloud platforms and IIoT applications. A good connectivity layer outputs both simultaneously from the same source data; Kepware, for example, can serve a legacy Modbus tag to a local MES over OPC UA while publishing the same tag to a cloud platform over MQTT, so you are not forced to choose between the plant network and the cloud.

Normalization also means adding context. Raw register values become named tags with engineering units, scaling, and metadata about which line, cell, and asset they belong to. Do this once, at the connectivity layer, and every downstream application inherits clean data. Do it separately in every application, and you will spend years reconciling mismatched numbers between reports.

Step 5: Treat security as part of the design, not an afterthought

Connecting a 20-year-old controller to the network changes its risk profile. Legacy protocols like Modbus have no authentication and no encryption; anyone on the network segment can read or write to the device.

The mitigation is architectural. Keep native, insecure protocols confined to a segmented OT network. Let the connectivity server act as the security boundary: it talks Modbus or DF1 downward, inside the protected segment, and exposes only encrypted, certificate-authenticated OPC UA or TLS-secured MQTT upward. Disable write access for any tag that does not strictly require it. Log who connects and what they read.

This pattern, sometimes described as a secure data diode for legacy equipment, lets you extract value from old machines without extending their attack surface into the enterprise network.

Step 6: Start with one line, then scale the template

Pick one production line for the pilot. Ideally one with a mix of old and new equipment, a clear business question, and a supervisor who wants the data. Connect it, build the first dashboard, and measure the result for four to six weeks.

Then, and this is the part most projects miss, turn what you built into a template: the tag naming convention, the driver configurations, the security settings, the documentation. Rolling out to the second line should take a fraction of the time the first one did. Plants that follow this pattern typically connect their remaining lines in weeks rather than months.

The bottom line

Legacy machines are not a barrier to plant data; unmanaged protocol diversity is. Audit your assets, define the data you need, translate everything through one connectivity layer, normalize into OPC UA and MQTT, secure the boundary, and scale from a pilot. The machines that have been quietly making parts for twenty years have plenty to say. You just need to give them a common language.