Skip to content
General Tech Automation
Get A Free Quote
Application example

Migrating a Lineoff an Obsolete PLC

Logic Recovery • Hardware Replacement • Tested Cutover • Dubai • Sharjah • Abu Dhabi

In the control panel
  • Obsolete PLC and I/O: replaced by, Current PLC and I/O
  • Old operator panel: replaced by, New HMI
  • Software that needs XP: replaced by, Current software
  • Field devices and wiring: reconnected as is, Nothing fitted
  • The machine itself: left as it is, Nothing fitted

An obsolete PLC does not announce itself. The line runs perfectly well, the logic has not been touched in a decade, and the risk is entirely invisible until the day a card fails. Then it becomes very visible: the part is out of production, the broker wants a great deal of money for a used one with no warranty, the programming software will not run on anything newer than Windows XP, and the only person who understood the program left in 2014.

Migrating to a current platform is the work of removing that risk before it collects. Done properly it is not a rebuild — the field devices, the wiring and the machine itself stay exactly as they are. What changes is the controller, the software it runs, and the fact that spares and support exist for it again.

In the control panel

The control changes; the line does not

Drives, motors, sensors and the machine stay exactly as they are. What is replaced sits at the left of the drawing, and the field wiring is landed onto it as it is.

  • Signal
  • FMeasuring point
  • What we fit
  1. SDrive signalsRun, speed reference and fault from each drive, landed on the new rack. The drives and motors themselves stay.
  2. ZSField sensorsPosition and proximity switches on the line, reconnected as they are and point-checked one by one at cutover.
  3. XAAlarms and diagnosticsOn the new HMI, with a proper history and alarm text that names the failed sensor rather than a fault code.
What changes

What comes out, and what stays

The most common worry about a migration is that it is a rebuild. It is not. The machine, the field devices and the wiring are untouched — only the control that drives them is replaced.

Replaced

Everything here is end-of-life, unsupported, or dependent on software that will not run on a current laptop.

  • Processor and I/O racksA current controller on the platform your team already supports
  • Operator interfaceUsually as unobtainable as the PLC, and replaced with it
  • The panel and its terminalsNew equipment in a thirty-year-old enclosure is a false economy
  • Programming softwareSo a change no longer starts with finding the one laptop that can connect

Kept

None of this is disturbed. It is why a migration fits a shutdown rather than a project.

  • Field devicesSensors, valves, drives and motors stay exactly as they are
  • Field wiringLanded onto the new rack, laid out to minimise re-termination
  • The machine itselfNo mechanical scope, no foundations, no re-commissioning of the process
  • What the line doesThe sequence is reproduced, including the odd behaviour somebody asked for in 2009

The old hardware is kept, intact and labelled, until the new system has run a full production cycle. It is the cheapest insurance in the project.

What actually gets replaced

The scope is deliberately narrow. Every extra thing pulled into a migration is another thing that can go wrong in the cutover window.

The processor and I/O

The old rack comes out and a current-generation controller goes in — Siemens, Allen-Bradley, Schneider or whatever the site already standardises on, because a second platform to support is a cost that outlives the project. Where the I/O count and types allow, the new rack is laid out to land the existing field wiring with minimal re-termination.

The program

The logic is recovered from the running controller, read and understood, and rewritten for the new platform. Automatic conversion tools get part of the way and are worth using, but the output always needs a pass by someone who knows what the machine does — a converted rung that is syntactically correct and behaviourally wrong is worse than no conversion at all.

The operator interface

An HMI of the same vintage as the PLC is usually just as unobtainable, so it goes at the same time. This is the one place where taking the opportunity to improve things is worth it: clearer alarm text, a proper alarm history, and diagnostics that tell a fitter which sensor failed rather than which fault code appeared.

The panel it lives in

New hardware in a thirty-year-old enclosure with tired terminals and no room for a new power supply is a false economy. Depending on condition, the panel is either refurbished around the new equipment or rebuilt entirely and swapped as a unit, which is far quicker in the window.

Platforms

The controllers we migrate from and to

Most end-of-life controllers still running lines in the UAE come from a handful of manufacturers — Siemens S5 and S7-300, Allen-Bradley PLC-5 and SLC 500, Modicon, Mitsubishi A-series, Omron C-series. The replacement is usually the same maker's current range, or whichever platform the site already standardises on.

Siemens logo
Allen-Bradley logo
Schneider Electric logo
Mitsubishi Electric logo
Omron logo
ABB logo
How it runs

Doing it without losing the line

The entire method is about moving risk out of the shutdown window and into the weeks before it, where a problem costs time instead of production.

01 / 04 STAGES
  1. Weeks before

    Recover and document the existing system

    The current program is uploaded while the machine still runs, and the I/O list, wiring and sequence of operation are documented against it. On many older installations this is the first accurate documentation the line has ever had, and it has value well beyond the migration.

  2. Weeks before

    Convert, review and simulate

    The logic is rewritten for the new platform and tested against simulated I/O — every interlock, every alarm, every mode change, and specifically all the odd behaviour that only exists because a fitter asked for it in 2009. Faults found here cost an afternoon; the same faults found during cutover cost production.

  3. Weeks before

    Build and pre-test the panel

    The replacement panel is built and wired on the bench, powered up, and tested with the new program loaded and the I/O forced through its states. It arrives on site as a proven assembly rather than a box of parts.

  4. The window

    Cut over and prove

    Old panel out, new panel in, field wiring landed, and then a full point-to-point check of every input and output before anything is allowed to move. Dry runs, then a supervised production run, then handover with the documentation and the source program in the site's hands — not the contractor's.

Keeping the old hardware, intact and labelled, until the new system has run a full production cycle is the cheapest insurance in the project.

What you are actually buying

Spare parts that exist and can be bought in an afternoon rather than sourced from a broker in another country.

Programming software that runs on a current laptop, so a change does not begin with finding the one machine that can talk to the controller.

Documentation and a source program the site owns, which is what makes the next engineer's job possible.

Diagnostics good enough that a maintenance team can find a failed field device themselves instead of calling someone out to read the logic.

A path to connect the line to the rest of the plant — historians, dashboards, condition monitoring — which an end-of-life controller simply cannot take.

Where it fits

Lines that are too old to trust and too good to scrap

Manufacturing

Process and assembly lines built around controllers that have been end-of-life for years, still running well, and carrying a single point of failure nobody has costed.

Automotive

Press, weld and assembly cells where the mechanical plant has decades of life left and only the control system has aged out from under it.

Food and Beverage

Filling, packing and CIP systems where downtime is measured against a production plan with no slack in it, and where the migration has to fit a scheduled clean rather than create a stoppage.

Questions

Common questions about migration

It is a common situation and not usually fatal. Where the logic cannot be recovered from the controller, the system is reverse-engineered from the outside: the I/O list, the electrical drawings, the machine's actual behaviour, and a great deal of time with the people who operate it. It costs more and takes longer than a straight conversion, which is a good argument for doing the migration before the person who knows the machine retires.

That depends almost entirely on how much was proved beforehand. A migration where the panel was pre-built and the logic was simulated is a cutover measured in a weekend or a planned shutdown. A migration where the first time the new program meets the real machine is on the night of the changeover is measured in however long the surprises take. The preparation is what buys the short window.

Staying within the same manufacturer's current range usually converts more cleanly and keeps the maintenance team on software they know. Changing is worth it when the site already standardises on something else, or when the incumbent range no longer suits the application. What is rarely worth it is choosing a platform nobody on site has seen before because it was cheapest on the quotation.

Get in touch

Tell us what is controlling your line, and we will tell you how exposed you are.

A survey of the installed control hardware, its support status, and what a migration would take in scope, cost and downtime.