Migrating legacy PLCs
and obsolete SCADA: methodology

Why is migrating urgent?

There are thousands of industrial plants in Chile and Latin America that are being controlled right now by equipment that has been in service for 20, 30 or even 40 years: Allen-Bradley PLC5 and SLC500, Siemens S5, GE Series 90, and SCADA systems running on Windows XP or Windows 2003 with no security patches for a decade.

Plant managers know the risk but put it off: migrating seems expensive, complex and risky. Until the PLC fails and there are no spare parts. Until the SCADA server's hard drive dies and the backup is 3 years old. Until ransomware gets in through the unpatched Windows XP and stops production for weeks.

The real risks of not migrating

Operational continuity risk

A PLC5 or SLC500 that fails today can take weeks to replace — if the spare part can be found at all. Allen-Bradley discontinued the PLC5 years ago. Modules are available on secondary markets with uncertain stock and no guarantee that they work. A CPU failure in a continuous plant can mean millions of dollars in lost production while waiting for a spare part that may never arrive.

Cybersecurity risk

Windows XP has not received security patches since 2014. A SCADA server on Windows XP connected to any network — even if only to send reports by email — is an open door for ransomware and targeted attacks. Cybersecurity incidents in OT systems with obsolete infrastructure are growing year after year in Latin America.

Knowledge risk

The engineer who programmed the PLC5 in 1995 has already retired. The documentation is on yellowed paper or simply does not exist. Knowledge of the system lives only in the memory of one or two people. When those people leave, the system becomes unmaintainable.

Regulatory risk

In sectors such as food, pharmaceuticals, drinking water and energy, regulatory audits increasingly require evidence that control systems are maintained and up to date. A SCADA on unsupported Windows XP can put certifications at risk.

Real case: Aceros de Guatemala

Grupo Salba carried out a complete migration project at the shredder plant of Aceros de Guatemala that perfectly illustrates the right methodology.

Initial situation

The plant was running an Allen-Bradley SLC500 PLC controlling the scrap shredding process — one of the most critical and intensive processes in the operation. The SCADA system was Cimplicity version 6.x running on a server with an obsolete operating system, with no manufacturer support and no possibility of security updates.

In addition, the system included 10 storage silos with RFID tag identification, integrated dynamic weighing and a Historian on a MySQL database for material traceability.

Project objectives

• Migrate the SLC500 PLC to the GE (now Emerson) RX3i — a modern platform with current support and greater processing capacity
• Upgrade the SCADA from Cimplicity 6.x to version 10.x — keeping all existing functionality and adding modern capabilities
• Keep the RFID integration and the dynamic weighing system
• Minimize plant downtime — the shredder cannot stop for longer than strictly necessary

Migration methodology: the 6 phases

The migration engineering we applied at Aceros de Guatemala — and that we replicate in every project — follows a 6-phase methodology designed to minimize operational risk.

Phase 1 — Exhaustive survey of the existing system

Before touching a line of code or a hardware module, we fully document the current system. This includes a complete survey of the PLC program (ladder, function blocks, data, I/O configuration), an inventory of all SCADA screens and objects, the signal mapping between PLC and SCADA, documentation of all safety interlocks, and a record of normal process values for each variable.

In many migration projects, this phase reveals surprises: undocumented logic, workarounds accumulated over years, and features that nobody remembers the exact purpose of but that "have always been there". All of this must be understood before migrating.

Phase 2 — Design of the target architecture

With the current system fully documented, the architecture of the new system is designed. For Aceros de Guatemala this involved:

• Complete SLC500 → RX3i signal mapping, including equivalent I/O modules
• Conversion of the Ladder logic from RSLogix 500 to Proficy Machine Edition (the RX3i programming environment)
• Design of the new industrial network architecture (industrial Ethernet vs. the original DH+)
• Cimplicity database migration plan: points, alarms, trends, scripts
• Strategy for maintaining the RFID integration with the new SCADA

Phase 3 — Cutover strategy and maintenance window

This is the most critical phase from an operational point of view. The goal is to design a migration strategy that allows the old system to be cut over and the new system started within the available maintenance window — which in the case of Aceros de Guatemala was very tight, since the shredder runs practically 24 hours a day.

The cutover strategy defines:

• Pre-cutover preparation — everything that can be done without stopping the plant: installing the new hardware in parallel, configuring the new SCADA, offline communication tests
• Cutover sequence — the exact order of steps during the maintenance window, with time allocated to each action
• Rollback plan — what to do if something fails during the cutover and it is necessary to return to the old system
• Go/no-go criteria — the minimum conditions that must be met before authorizing startup with the new system

Phase 4 — Offline development and testing

The new PLC program and the new SCADA are developed and fully tested before they reach the plant. We use process simulators and test environments that replicate real conditions to validate all the logic, all the alarms and all the safety interlocks with no risk to production.

In the case of the RX3i, the Proficy Machine Edition environment makes it possible to simulate execution of the PLC program on the engineering workstation itself. For the Cimplicity 10.x SCADA, we create a complete test environment with simulated data that lets us validate every screen, every alarm and every script before the cutover.

Phase 5 — Executing the cutover in the maintenance window

With all the preparation complete, the cutover follows the sequence defined in Phase 3 to the letter. The migration team is on site, the production team is available, and the plan is executed step by step with verification at each stage before moving on.

For Aceros de Guatemala, the cutover included: controlled disconnection of the SLC500, installation of the RX3i rack in the same physical space, reconnection of the field wiring, download of the validated program, supervised startup of the shredding process with the new system, and verification of the RFID integration and dynamic weighing.

Phase 6 — Validation, documentation and handover

Once the new system is operational, the work is not over. An operational validation period follows — typically 2 to 4 weeks — during which Grupo Salba's engineering team is available to resolve any situation that did not come up during testing. At the close, complete technical documentation of the new system is delivered and the maintenance staff are trained.

Legacy PLCs and their modern equivalents

SCADA migration: specific considerations

SCADA migration brings additional challenges beyond those of the PLC, because the SCADA accumulates years of development: hundreds or thousands of screens, alarm configurations, logic scripts, reports, historical trends and communication settings for multiple devices.

Cimplicity 6.x to 10.x — lessons from the Guatemala project

Migrating Cimplicity from version 6.x to 10.x at Aceros de Guatemala brought specific challenges because there were major changes in the product architecture between those versions. Process points, CimEdit screens and Basic scripts could be migrated with the manufacturer's import tools, but required manual review and adjustment in several cases. The integration with the MySQL database for the Historian was one of the points that required the most validation work.

The main lesson: never assume that migrating between versions of the same SCADA is automatic. There are always elements that require manual reconfiguration, especially in integrations with external systems and in scripts with complex logic.

Migration to modern open platforms

When the SCADA to be migrated is very old or the licensing cost of the new version is prohibitive, migrating to Ignition (Inductive Automation) is a powerful alternative. Its per-server licensing model — with no cost per number of clients or tags — and its modern web architecture make it especially attractive for full modernization projects.

When to migrate and when to wait?

Not every obsolete system requires immediate migration. The decision should be based on a risk assessment that considers:

• Spare parts availability — is there stock? For how much longer?
• Process criticality — how much does an hour of downtime on this equipment cost?
• Cybersecurity exposure — is the system connected to any network?
• State of knowledge — does documentation exist? Are there people who know the system?
• Expansion plans — are there plans to add capacity or features?

A PLC5 system that is completely isolated, well documented and has spare parts in stock can run for a few more years at low risk. An SLC500 connected to the corporate network, with no documentation and whose spare parts are no longer available, needs migrating now.