Digital Twin Development for Legacy Manufacturing Plants

• The hardest work of a twin in an older factory happens in two places: pulling reliable live data off legacy equipment and safely sending changes back to it.
• A digital shadow reports what a production line is doing, in one direction only. A digital twin can also send changes back to the line.
• Four things decide whether a twin project at a mid-size manufacturer succeeds: the cost of connecting old equipment, the security risk of joining plant systems to the IT network, a shortage of engineers who can build and maintain the models, and a payback method the CFO will accept.

Where Digital Twin Development for Manufacturing Actually Starts

Every machine with an Ethernet port feeds the dashboard your team built over the last two years, and the picture on screen updates in near real time. Now a vendor is walking you through a slide deck that promises a self-optimizing digital twin of the same line. The demo looks strong, the language sounds familiar, and the budget request is large enough that the CFO wants a second opinion before you sign.

For a Manufacturing IT leader or Head of Industry 4.0 deciding whether digital twin development is worth the budget for an older plant, the gap between what you already have and what you are being sold matters more than the pitch suggests. This article addresses what a real production-line twin requires, why the hardest work in an older plant is not the part that gets demoed, and what to check before you commit budget.

What Digital Twin Development Means for a Production Line

A live dashboard is a one-way system. Signals move from the equipment to operators or software, who read them and decide what to do next. A digital twin closes the loop. It reads the same signals, decides on a change, and sends that change back to the equipment. Then it reads what happens next. The ability to write decisions back is what separates a shadow from a twin.

Digital twin development for a production line is industrial software engineering work covering three overlapping technical tasks:

• Getting live data off the floor from a mixed fleet of controllers, including equipment that predates modern networking.
• Running a virtual model that mirrors what the line is doing in real time.
• Writing decisions back to that equipment safely, on a running line.

Vendor demos usually focus on the virtual model. It renders the line in three dimensions and animates in sync with live signals, so operators, engineers, and executives are looking at the same thing. On its own, though, it cannot change how the line runs. The first and third tasks, capturing signals and writing decisions back, do that work.

A 2026 peer-reviewed roadmap on AI and machine learning for smart manufacturing calls this two-way version the harder and newer step. Most industrial deployments today are still one-way monitoring systems. Info-Tech Research Group's research on digital twin adoption in manufacturing finds four barriers that consistently stall mid-market projects: integration, security, specialist shortages, and slow payback.

The Three Technical Layers of Digital Twin Development

Getting Live Data off the Floor

Modern equipment ships with well-documented network interfaces. Older equipment does not. A brownfield plant is an existing factory with legacy machines, rather than a greenfield site built from scratch. Some speak closed languages the equipment manufacturer will not document. Others speak nothing at all until you bolt a retrofit sensor onto them. The data layer for a twin needs to translate all those different signals into one common format and timestamp them consistently. If the data stream is unreliable, every layer above it inherits the unreliability.

The Virtual Model

The virtual model is what most vendor demos focus on. It is a software representation of the equipment, its geometry, and its operating logic, kept in sync with the live signals from the floor. Done well, the model is more than a picture. It lets engineers test a change on the model before running it on the machine, which is where most of its practical value comes from. The system the team developed with Analog Devices ran a physical device and its simulator side by side, so engineers could reproduce sensor behavior on the simulator without touching the hardware. A model that only renders the current state without supporting that kind of testing is a visualization, not a working part of a twin.

Sending Changes Back to the Line

The third layer is the one most projects underestimate. Writing a new target value or command to a running machine requires a control path that respects the equipment's safety limits (the ranges beyond which the machine will damage itself or the product), the operators' authority to override, and the plant's uptime commitments. The write also needs the model's decision to be trustworthy enough that the plant is willing to let it act. That is a separate problem from the technical one of getting the write to succeed. Most current systems stop at read-only, which is what makes them shadows.

Three Obstacles to Sending Commands to Older Equipment

The Equipment Itself

Legacy PLCs and machine controllers were built to be trusted local systems, with limited or no support for remote command from outside the plant network. Retrofitting them to accept external commands usually means adding a gateway and negotiating access with the equipment manufacturer. Some machines will never accept remote commands at all. The workaround for those is to send commands to an operator interface and let a human confirm the change, which is safe but slower and not autonomous.

The Safety Limits the Machine Operates Within

The second is the safety limits the equipment operates within, meaning motor speeds, temperature bands, pressure limits, and tool paths that cannot be exceeded without damage. A twin that writes decisions back to the line must check its own outputs against those limits before it acts. The plant also needs a way to interrupt or reverse a decision that is heading toward a bad outcome. Creating that control layer is a specialist job. The engineers who can do it well are a small group in the industry, and their time is booked far in advance.

What Happens When the Network Drops

The third is what happens when the network drops. A twin that acts on the line needs to keep the data on each machine when the connection to the cloud fails, hold the last safe command in place, and match everything up with the cloud once the link is back. Our team develops parts of Invenda's Luna platform, the Swiss-built system that runs more than 7,500 connected retail screens across 22 countries. When a machine loses its link to the cloud, transactions continue locally and sync automatically once the link returns. The complication is that machines in the fleet can run different combinations of components, so the sync logic has to hold across all of them. Invenda's screens are retail hardware rather than production equipment, but the sync problem has the same shape.

What to Check Before You Start a Twin Project

• Integration cost, in real numbers. Walk the plant with the software development firm you're considering, and count the equipment that will need retrofitting for reliable data extraction or command acceptance. Ask for a per-machine estimate, a total, and what the estimate assumes if a machine turns out to be more constrained than the initial walk-through suggested. A firm that cannot give a range at this stage is guessing about the rest of the project too.
• Security architecture, before the demo. The connection between plant systems and IT networks is the surface an attacker uses to reach production. Ask them to describe the network segmentation, the authentication for machine commands, and the audit trail for every write to the equipment. If those answers arrive as generic assurances about their security posture, keep looking.
• The engineers who will do the work. The engineers who can design and maintain a twin that closes the loop are a small and known group in the industry. Ask the firm to name the engineers who will lead the model design, the control-path work, and the ongoing operations. If the answer is a role or a department, the firm is telling you they have not staffed the project.
• A payback method you can defend to Finance. The partner should propose a way to measure the twin's operational impact before the build starts, whether that is predictive alerts that come before a failure, yield improvement, energy reduction, or a combination. Vague promises of Industry 4.0 transformation do not survive a CFO review. A baseline metric, measured before the twin goes live and again six months after, gives the CFO a number to defend the investment against.

Conclusion

One question separates real capability from a good slide deck: ask each prospective partner to walk you through a live client where they close the loop on a running line, and to introduce you to the engineer who built the control path. A team that can answer both parts of that request has done the work before, and belongs on your shortlist. If you want an honest view of what a twin project would look like at your site, talk to Accedia's IoT team about your plant.