One of the riskiest assumptions you can make about a controls migration project is that because the existing system is still running, it must be stable. Most outdated systems are full of workarounds, fail-safes, and, in some cases, even semi-functional code left over from “temporary” patches that may have been put in place over the years.
The logic governing interlocks, sequences, and controls is probably only partially documented, and the PLC application may have exceeded the capacity of the processor years ago.
Map Everything Before You Touch Anything
The initial step to take before upgrading any control system is to conduct a complete physical and digital I/O audit. This means walking every cable tray, documenting every field device, and tracking every communication path from sensor to HMI. It sounds tedious because it is – but legacy systems accumulate years of undocumented field modifications, workarounds, and custom logic that never made it back into the as-built drawings.
You perform a physical audit of all I/O to verify that what is in the field maps to the existing control system’s understanding of what is in the field. This means that you will be analyzing technical manuals, following drawings, and examining digital capture images to audit field instruments, junction boxes, and I/O modules in the system.
The more complete your audit, the more smoothly you can ensure enhancements to the safety system, cyber intruder systems, or IIoT systems, etc. This audit also gives you the input you need for proper control systems design – mapping communication dependencies and wiring architecture before commissioning, rather than discovering surprises during a 48-hour cutover window when the pressure is on and the plant is down.
Simulate Before You Commission
After the audit is done with and new PLC code is under development, a digital twin simulation becomes the best tool to avoid issues reaching the plant. A simulation of the plant’s control logic on a PC allows you to run real operational scenarios – startups, faults, edge cases – on the new control against the digital model of the existing physical assets.
This naturally flows into Factory Acceptance Testing (FAT), where you shrink the commissioning chaos by proving as much as possible ahead of time in a controlled environment. FAT with simulation is much more complete than FAT against relays or even a benchtop I/O box because you can stress the new HMI, alarms and interlocks under conditions that are much closer to “real” before the operators even arrive.
Operator training is sometimes left out of the FAT process. Don’t make that mistake. The best HMI and interlock designs on paper often turn out to be the most confusing and unusable in a real plant. The great thing about digital twin simulations is that the operators can start getting accustomed to the new code months before it goes live on the plant floor. This very inexpensive training can identify many interface problems that even the engineers didn’t notice.
Phase The Migration, Don’t Flip A Switch
A “big bang” cutover, where you decommission the old system and start up the new one simultaneously, is the highest-risk approach. It’s also the most common, because phase migration is harder to schedule. Upgrading subsystems incrementally is far safer to execute, as the plant is never fully dependent on an untested system. Failures are contained rather than catastrophic. Improved hardware makes this easier.
Wiring conversion and termination – for example, between legacy field wiring and I/O – can now be done with prefabricated “swing-arm” kits rather than full re-termination. Prefab kits reduce what used to be two maintenance days of labor to a few hours. Same goes for new network installation. Run the old serial and new Industrial Ethernet network in parallel, validate I/O communication for a week on the new Ethernet network, then cut over. Never decommission the legacy serial plant network until the new network has been proved stable under load.
Build The Rollback Plan Before You Need It
A cutover plan without a rollback procedure is half a plan. Before you go live, you need clearly defined “point of no return” milestones and a rollback process with a hard time limit attached to it. Not because you expect things to go wrong, but because having that safety net is exactly what lets a team move decisively when something does.
Work out the answers before you’re under pressure. At what point in commissioning do you formally hand over to the new system? What would make you reverse that decision – and are those triggers technical, operational, or both? If you had to roll back right now, how long would it take? Who makes the call?
Site Acceptance Testing will tell you a lot, but it can’t fully simulate production load. There’s always a chance something surfaces after go-live that testing didn’t catch. The teams that handle those moments well aren’t the ones who react fastest on the day – they’re the ones who already agreed on the answer weeks before.
The Upgrade Itself Isn’t The Risk
When a control system upgrade goes wrong, the upgrade itself is rarely to blame. The technical steps are well understood, well documented, and in most cases well executed. The real culprit is almost always what happened – or didn’t happen – in the weeks and months before cutover. Audits that were incomplete or out of date, code that was never properly stress-tested, schedules that treated the entire cutover as a single event rather than a sequence of smaller, manageable steps.
A well-planned cutover should feel like an anticlimax. Two valves, an hour. That’s it. If it takes longer, or something unexpected comes up, the preparation wasn’t thorough enough. There’s also a framing issue worth correcting. Most teams treat the new system as the source of risk – the unknown quantity that needs to be watched carefully. But the real risk is what’s being replaced. The old control system, with its age, its quirks, its undocumented workarounds, is the liability. The upgrade is how you retire it. The technology isn’t the threat. Staying on the old system is.
