Grade before you buy
Like-for-like or rewrite
Redundancy costs more
A rollback pointWhen a controller is actually end of life
Obsolescence is a procurement word, and it hides four different situations that need four different answers. Before anyone quotes you a processor, the platform needs grading.
| Stage | What it means | What it justifies |
|---|---|---|
| Active | Still sold, still supported | Nothing. Do not migrate. |
| Active mature | Sold, but the successor is announced | Budget planning. Start collecting the documentation you will need in three years. |
| End of life | No longer sold. Repair and support continue for a stated window | A migration plan with a date, and a spares bridge to cover the gap. |
| Discontinued | No repair, no support, grey market only | Migration now. Every month is borrowed. |
Families we see most often at this point in Malaysian plants: Allen-Bradley SLC 500 and PLC-5, early ControlLogix firmware that will not talk to anything modern, Siemens S5 and early S7-300, Mitsubishi A-series, Koyo and other small platforms that arrived with a packaged machine and were never on anyone's asset register.
A small platform often has no hot swap. Reseating a module on a live rack to diagnose a fault can raise a permanent I/O error by itself, and then you are troubleshooting the repair rather than the failure. Ask what the platform does on module removal before anyone opens a door. It is cheaper to ask than to buy a processor.
Like-for-like, or re-engineer
This is the decision that sets the cost and the risk, and it is usually made by accident.
Like-for-like reproduces the old logic on new hardware. It is faster, it is testable against known behaviour, and it is the right answer when the process is stable and the shutdown window is short. The cost is that you carry across twenty years of patches, dead branches and workarounds nobody can explain.
Re-engineer writes the control philosophy fresh from what the plant actually does now. It costs more up front and it needs process people in the room. It is the right answer when the original design has been overtaken by modifications, or when the migration is the excuse to fix something that has annoyed operations for a decade.
Automatic conversion tools sit uncomfortably between the two. They exist for most cross-vendor paths and they do produce running code. What they produce is code shaped like the source platform, with remapped tags and instruction emulation that no maintenance technician will ever enjoy reading. Used as a reference for what the old logic did, they save real time. Shipped as the deliverable, they hand you an unmaintainable system on new hardware, which is the worst of both outcomes.
The architecture decisions that cost money later
Redundancy is not a second processor in the same chassis
A redundant ControlLogix pair does not permit local I/O in the redundant chassis. So "add a second CPU for redundancy" is never the real bill of materials. The I/O has to move to a remote chassis on a network, which means network modules, a second remote chassis, cabling, and a rework of every I/O reference in the program. If a quotation shows you a processor and a redundancy module and nothing else, it has not been engineered, it has been priced.
Network segregation is decided now or never
A migration is the one moment the control network can be laid out properly. Once the plant is running on the new system, nobody will take another shutdown to separate an OT network from the office LAN. Decide the segmentation, the remote-access path and the patching responsibility during design, and write it into the handover.
Spares strategy is part of the migration, not a follow-up
There is always a gap between the decision to migrate and the cutover. That gap has to be covered by spares for the old platform, bought while they are still findable. Plan it deliberately: which modules, how many, and whether refurbished stock is acceptable for a system with a known retirement date.
How we run a migration
- Survey. Rack inventory, firmware revisions, I/O count and type, network topology, which drawings are current and which are fiction. Most plants discover here that the as-built and the panel disagree.
- Recover the logic. Upload and archive everything before anything is touched, including the HMI application, drive parameter sets and any recipe data. This is also the last chance to recover a program from a processor that may not power up again.
- Control philosophy. Written down, in plain language, and agreed by operations before a line of code is written. Interlocks, permissives, failure states, manual paths.
- Build and FAT. Panel built and the new system tested against simulated I/O, with operations present. Faults found here cost hours. Faults found on site cost a shutdown.
- Cutover. Sequenced against the shutdown window, with a written rollback point and a defined abort criterion.
- Handover. Source code, licences, as-built drawings, parameter backups and a documented restore procedure, in your hands, not ours.
"The plant can still run in manual" is an assumption that has to be tested, not stated. If the manual path runs through a PLC output, a processor in STOP kills manual too. Check the wiring, not the intent, before a migration plan leans on manual operation as the fallback.
Questions we get asked
How long does a PLC migration take?
The engineering is usually months and the cutover is usually days. A single machine on a small platform can be surveyed, built and cut over inside a quarter. A plant-wide DCS migration is planned a year ahead because it is scheduled against annual shutdowns, and the constraint is almost never our capacity, it is the window the process will give you.
Can you migrate between brands, for example Allen-Bradley to Siemens?
Yes, and it is common when a plant is standardising. Expect the instruction set, the tag structure and the HMI to be genuinely rewritten rather than translated. Budget for that honestly rather than trusting a conversion tool to absorb it.
Do we have to replace the field devices and wiring too?
Usually not. Most migrations reuse the field wiring and terminate into new I/O, which is why marshalling and terminal strategy matter more than people expect. Devices get replaced where they are themselves obsolete or where the signal type is changing.
What happens if the cutover fails?
There is a written rollback point and an abort criterion agreed before the window opens. The old racks stay in place and re-terminable until the new system has run through a defined proving period. Any plan that removes the old system on day one is a plan without a reverse gear.
Do you hand over the source code?
Yes. Source code, licences, as-built drawings and backups belong to the plant. A control system you cannot open is a control system you do not own.
Related
- SCADA and HMI systemsLicensing traps, redundancy and what a second console really costs
- Control panel and MCC buildEnclosure sizing, fault levels and the clearances drives actually need
- Industrial spares and obsolete partsBridging the gap between the decision and the cutover
- Industrial automation in SarawakLocal crew, local permits, local response