Somewhere on your plant floor there is a controller that a supplier stopped making before some of your operators were hired. It still runs. That is the problem, because "still runs" is doing a lot of work in that sentence. The processor is fine until the day a power supply pops, and then the replacement module has a months-long lead time, the programming software only runs on a Windows version IT killed years ago, and the one laptop that can still talk to it lives in a drawer with a sticky note that says DO NOT UPDATE.
Most plant managers know they are exposed here. What surprises them is where the exposure actually sits. It is not the metal. You can buy new metal. The thing you cannot reorder is the fifteen or twenty years of process logic living inside that program, most of which was never written down anywhere else.
The hardware is the cheap part of the loss
A programmable logic controller (PLC) is a rugged industrial computer that reads sensors and commands the motors, valves, and variable frequency drives (VFDs) on your line. Swapping the box is a solved problem. Vendors sell migration kits and conversion tools that promise to translate an old program onto a new platform automatically. Those tools are useful and I use them. But they translate syntax, and not always even that: retentive versus non-retentive timers and reset conditions rarely map cleanly, so even a simple timer can come across wrong.
What no tool can translate is intent. It will convert a timer that waits four and a half seconds before opening a diverter. It cannot tell you that the four and a half seconds exists because a specific chute used to plug at three seconds, and somebody, on a bad night shift a decade ago, tuned it by hand until the jams stopped.
That number is process knowledge. Multiply it by every fudge factor, every interlock somebody added the week after an incident, the "temporary" bypass from a shutdown in 2016 that is still in there, and you have the real asset. A rushed migration copies the boxes and discards the reasons, and three weeks after commissioning you are chasing a product-quality drift nobody can explain, because a compensation that used to happen invisibly is gone.
The risk is the logic nobody wrote down
When people call a control program "undocumented" they usually picture missing manuals. The deeper problem is that the program is the documentation, written in a dialect only the original integrator spoke. Rung comments are sparse or wrong. Tag names like AUX_7 and SPARE_TMR_12 turn out to be load-bearing. There is a routine everyone is scared to touch because the last person who understood it retired and does not answer his phone.
Get an offline backup of that program early, because on some systems just getting the legacy software onto a machine that can still drive the programming cable is the first real fight. But a backup only gives you the code, and the code tells you what the logic does, not what the process does. For that you need the old controller powered and running, so you can watch the sequences step, force an output, trend a loop under real load. Right up until cutover, that controller is the most honest specification of your process you will ever have. Mine it while it is alive.
You will also find logic that is not worth preserving. It is software papering over a mechanical problem that should have been fixed years ago: a worn liner, a load cell that has read low since it got flooded, a chute whose angle was wrong the day it went in. Carrying that compensation forward just moves the debt onto a new platform. A migration is a rare chance to clear it, and the right call is often to fix the iron and delete the workaround. Half the time, mind you, you dig in and the old tuning was fine, and you will have spent a week proving what you could have assumed. Still cheaper than the alternative.
One category you never treat this way is safety. If an interlock is a safety function (an e-stop, guard logic, a rated shutdown), you do not informally "prove it still behaves." You re-validate it, and depending on how it is rated you may have to re-certify it on the new hardware, as its own piece of work. Lumping safety-rated logic in with the rest of the tribal knowledge to be mined and reproduced is how people get hurt.
What actually breaks at cutover
Everything above is about logic, and logic is not where most migrations bleed. The bulk of the schedule and the risk live in the physical layer: landing hundreds of field wires onto new terminals, re-addressing input/output (I/O), rescaling every analog signal so a 4-20 milliamp reading still means the same pressure it did before. If the old system ran remote I/O or drives over a legacy fieldbus, moving that network onto a modern one is often the highest-risk piece of the whole job.
Two controller-level traps catch people who looked only at the program. Scan time is the first: old and modern processors execute at very different speeds, and logic that leaned on a slow scan, an edge that was reliable at forty milliseconds, can misbehave on a box that comes around every two. The second is that proportional-integral-derivative (PID) loop tuning does not port. Platforms differ in PID form, scaling, and execution rate, so the old gains are a starting reference at best and you re-tune on the new one. And the operator interface counts too: the human-machine interface (HMI) and the supervisory control and data acquisition (SCADA) layer above it are often as much work as the PLC.
What ties all of it together is proving equivalence: capture how the machine behaves before you touch it, write a plain-English functional description from the live plant rather than from drawings three modifications out of date, then test the new code against that captured behavior on a simulation or a bench before it goes near production. None of this is proprietary; your own controls staff or any competent integrator can run the same playbook. A good cutover is quiet by design, but nobody should sell you "quiet" as "the easy day." The field wiring is the drama. It always is.
What this looks like on a real plant
A mid-sized manufacturing operation, three obsolete processors chained together, the newest roughly two decades old. The stated job was a straight hardware refresh before an unsupported card failed and took the line with it. The interesting part showed up in the raw material feed.
The infeed drive was throttled off a downstream level signal, and the tuning was aggressive in a way that made no sense on the drawings. Watching it run for a shift explained it. Between the infeed and that level sensor sat a surge bin with a dead spot where material bridged. Not always, not predictably, but enough. Each time, flow to the downstream dropped, the level sagged, and the loop slammed the infeed to catch it before anyone downstream felt a thing. Nobody on site knew that logic was doing that. They knew the line "ran smooth."
A naive conversion would have carried the tuning across, and the line would have kept running, operators none the wiser, the bin still bridging. Instead we flagged the bridging as the mechanical problem it was, wrote the new logic to handle it deliberately, and added an alarm so the next person would actually know it was happening.
The plain-English version
Replacing an obsolete PLC reads like a hardware project and mostly isn't one. What is at risk is the tuning, interlocks, and quiet compensations inside it, most exposed on the day everyone is staring at the new panel. Capture that behavior while the old system is still alive to watch. Handle the safety functions as their own formal job. Decide honestly what deserves to survive the trip and what was only covering for a mechanical fault. And prove the new system does what the old one did before cutover, not afterward through a stack of complaints.
If you have a controller you would rather understand than gamble on, get in touch and we can talk through where your real exposure sits.