Skip to content
PLC & Control Systems · APR 2026 · Updated JUNE 2026 · 10 min read

Legacy PLC Migration in Australia: Planning an Upgrade Without Losing Production

Key points

Key points
1

Plan before spares and recovery become urgent

Most migrations begin because spares, software access, or support coverage are getting thin.

2

Discovery shapes the outage window

The length and shape of the shutdown is settled during discovery, by what is found in the existing I/O, comms and field wiring, well before any hardware is ordered.

3

Staged upgrades often suit live plants

Line-by-line or area-by-area migration is often easier to manage than a single full cutover.

In most Australian sites the trigger for a legacy PLC migration is not better performance. A line keeps running while spares get harder to source, the programming software runs only on an ageing PC or operating system, and the options for recovering from a fault keep narrowing. When the only spare is the card that failed, restoring a tripped line can take days instead of hours. Migration planning should begin while the site still controls the shutdown window.

Signs it is time to start planning

Spare parts are getting thin

If a failed CPU or I/O card is now hard to source, the site is already exposed.

The software is fragile

When the programming software only runs on one ageing laptop and one person knows the application, a single absence or hardware failure can leave the line without a recovery path.

The plant needs new data or visibility

Older controllers and HMIs often reach their limits once the site wants richer reporting, structured alarm handling, or integration with MES or higher-level systems.

When does a legacy platform actually reach end of life?

Spares and recovery problems arrive years before the hardware stops working, and that gap is what drives migration timing. The platforms most common on Australian sites have all passed their commercial peak.

On the Allen-Bradley side, the PLC-5 family and the SLC 500 with its 1746 I/O are both discontinued lines. Rockwell now positions ControlLogix and CompactLogix as the migration targets and publishes structured migration paths for these legacy controllers (Rockwell Automation, SLC 500 to CompactLogix migration). Spares for these ranges increasingly come from the grey market and refurbishment channels, where pricing and reliability are both unpredictable.

On the Siemens side, the picture is dated. Production of the SIMATIC S7-300 controller and the ET 200M distributed I/O ended in October 2023, with spares and repair support nominally available for roughly a decade beyond that point. A line running S7-300 today is not in immediate danger, but it is on a defined clock, and the cost and lead time of spares tend to climb well before the formal end of support.

The practical message is the same across both vendors. The right time to plan is when one card failure would turn into a sourcing problem, not when the platform is formally retired. Planning early is what keeps the choice of shutdown window with the site rather than with a failure.

What to decide early

OptionBest fit
Full replacementOld hardware, old network, and difficult maintenance
Processor swap with retained I/OTight outages and healthy existing field side
Staged migrationMulti-line plants that cannot stop everything at once

How is the outage window kept short on the wiring side?

The longest part of many cutovers is re-terminating field wiring, so the wiring conversion approach is usually the single biggest lever on outage length. Wiring conversion systems exist specifically to avoid pulling every field conductor onto a fresh terminal block during the shutdown.

For Rockwell migrations, swing-arm wiring conversion modules and pre-wired conversion cables (the 1492 conversion system) are designed to land existing 1771 and 1746 field wiring directly onto 1756 ControlLogix I/O. The legacy I/O is removed, the new ControlLogix chassis goes in, and the pre-wired cables connect the field side through an interface module that maps the old terminal layout to the new I/O. Re-termination during the window is minimised, the point-to-point checking is reduced to the conversion interface rather than every field device, and the risk of a mis-landed wire under shutdown pressure drops accordingly.

This is not a universal substitute for inspection. The field wiring still has to be sound, the existing terminations still need checking, and any hand-modified or undocumented connections found during discovery will need to be resolved before the conversion hardware can be trusted. Where the field wiring is in good condition, though, a conversion system can turn what would have been a multi-day re-wire into a far shorter swap.

Code conversion is a starting point, not the finish

An automated converter gives a faithful structural translation, and the program still needs engineering work before it can run a live line. This is the step that most often gets underestimated in migration planning.

For Rockwell platforms, the Studio 5000 (formerly RSLogix 5000) Project Migrator converts PLC-5 or SLC 500 logic into a Logix project and does a competent job of the routine ladder. The areas that consistently need manual rework are well documented (DMC, converting PLC-5 to ControlLogix with the Project Migrator):

  • Analogue scaling. The way raw counts map to engineering units differs between the old and new analogue modules, so scaling has to be reviewed channel by channel rather than trusted from the converted code.
  • Block-transfer instructions. PLC-5 block-transfer reads and writes (BTR and BTW) do not map one-to-one onto Logix module data, so the data handling around analogue and specialty modules generally needs rebuilding.
  • Timing and scan assumptions. Logic that quietly relied on the old scan time or instruction timing can behave differently on the new controller and needs to be checked against the process, not just compiled clean.
  • Indirect and indexed addressing. Converted indirect addressing should be reviewed carefully, because addressing that was valid in the old data table can land on the wrong tag after conversion.

Siemens migrations carry their own version of this. Moving an S7-300 application toward newer platforms means reworking any logic that relied on the older addressing model, including ANY pointer parameters that must be re-expressed as VARIANT in the newer environment. As with the Rockwell tools, the converter handles structure and the engineer handles correctness.

How is the new system proven before it runs production?

Through a staged acceptance sequence, so that problems are found against simulation and test rigs rather than against product. Three stages do most of the work.

Factory Acceptance Test (FAT)

The converted program is exercised against simulated I/O before anything ships to site. Sequences, interlocks, alarms and edge cases are driven through a simulator so the bulk of the logic is proven off the critical path.

Site Acceptance Test (SAT)

Once installed, the system is checked against the real hardware: I/O is verified point by point, field devices respond as expected, and the wiring conversion is confirmed before the line is handed back.

System Integration Testing (SIT)

The line is tested where it meets upstream and downstream equipment, packaged units and higher-level systems, so interlocks and handshakes across boundaries are confirmed under realistic conditions.

IEC 62381 provides a common industry framework for the acceptance tests of automation systems, covering how FAT and SAT are structured and recorded (IEC 62381). Working to a recognised structure keeps the test scope, pass criteria and sign-off consistent, which matters most when several parties share responsibility for a cutover.

How is the cutover staged with a way back?

By breaking the changeover into defined steps with go/no-go decision gates and a written rollback at each one. The aim is that the line is never in an undefined state, and there is always a known position to return to if a check fails.

A workable cutover run sheet usually includes:

  • Pre-checks before isolation. Confirm spares, backups of the existing program, the converted program loaded and verified, the test record signed off, and support resources on hand.
  • Defined go/no-go points. Each major step ends in an explicit decision: proceed, or roll back. Examples are after isolation and lockout, after I/O verification, after first energisation, and before returning the line to production.
  • A documented rollback per gate. Each gate states what it takes to restore the previous state, including how long the rollback itself needs, so the decision can be made against the remaining window rather than in hope.
  • A clear point of no return. Once the legacy hardware is removed, rollback is no longer cheap. That boundary should be explicit on the run sheet so the team knows when the easy reverse has passed.

Staging line by line, or area by area, keeps each of these windows small and the rollback realistic. It is generally easier to prove and recover one line at a time than to attempt a whole-plant cutover in a single outage.

What does Australian compliance require during the cutover?

The cutover is electrical and plant work, so the safety and electrical standards that govern any such work on an Australian site apply in full. They are not optional extras layered on top of the controls task.

For the safety of the work itself, Safe Work Australia's guidance on managing the risks of plant covers isolation and energy control during maintenance and modification, including lockout and tagout of electrical, pneumatic, hydraulic and stored energy sources before anyone works on the equipment (Safe Work Australia, managing the risks of plant). Energy isolation should be planned into the cutover sequence rather than treated as a site formality.

For the electrical scope, two standards usually frame the work. AS/NZS 3000, the Wiring Rules, governs the electrical installation work around the new controller and field side. AS/NZS 61439 covers low-voltage switchgear and controlgear assemblies, which is the relevant standard where the migration touches or rebuilds control panels. Confirming which standards apply, and to which part of the scope, is part of discovery, not something to settle on the day of the outage.

Why the restart has to be sequenced

Re-energising a process after a cutover is a process event as much as an electrical one, and treating it as such avoids damaging the plant on the way back up. Bringing pumps, valves and drives back to a live state in the wrong order can cause real harm.

The clearest example is water hammer. On CIP and product transfer lines, re-energising pumps and opening or closing valves out of sequence can create pressure surges that stress pipework, fittings and instruments. The restart should follow a defined order that establishes flow paths before pumps are loaded, opens and closes valves at controlled rates, and brings interlocks back to a known state before the line is asked to do real work. On a migrated line this matters even more, because the restart is the first time the new logic drives the real process under pressure rather than a simulator. Sequencing the restart is part of the engineering, not a step left to whoever is on shift.

This is where process understanding earns its place in a migration. A controls change that is electrically correct can still hurt the plant if the restart ignores how the process behaves, so the people planning the cutover need to read the line as a process, not only as I/O.

What to verify before the first shutdown

Migration checklist

  • Physical I/O and comms paths checked on site.
  • Field wiring condition assessed and wiring conversion approach confirmed.
  • Converted code reviewed for analogue scaling, block-transfer and timing, not just compiled.
  • Third-party interfaces identified and tested in FAT scope.
  • Acceptance sequence agreed: FAT, SAT and SIT with sign-off criteria.
  • Cutover run sheet written with go/no-go gates and a rollback per gate.
  • Isolation and lockout-tagout planned to Safe Work Australia guidance.
  • Restart sequence defined to avoid water hammer on CIP and transfer lines.
  • Post-start support locked in before the outage begins.

When to start planning a PLC migration

If one hardware failure would now create a sourcing or support problem, it is worth starting the migration plan before the site is forced into an outage. The migrations that run with the shortest outages and fewest surprises are the ones planned with enough lead time to stage the cutover line by line, prove the converted code through FAT, SAT and SIT, and rehearse the restart before the shutdown.

References

About the author

Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.

Share:LinkedInX
Next step

Planning work in PLC & Control Systems?

Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.