A PLC migration checklist is a structured list of the decisions and tests needed to move a plant from an obsolete controller to a supported one without unplanned downtime. The code conversion is usually the easy part. Plants lose production when the audit was incomplete, the cutover window was too short or nobody tested the new code against realistic faults before site.

The pressure to migrate is real. Siemens set the SIMATIC S7-300 to phase-out from 1 October 2025 and recommends moving to the S7-1500 or S7-1200 (European Automation). Similar lifecycle notices exist for older platforms from every major vendor. Spare parts get scarcer and dearer, and engineers who know the old software retire.

Phase 1: audit and decide

  1. List every controller, remote I/O rack, HMI, drive and network on the system, with firmware versions.
  2. Recover the latest running code from the controllers, not from a laptop, and compare it with any archived copy.
  3. Mark up electrical drawings against the real panels; undocumented changes are normal.
  4. Record every external interface: SCADA tags, MES and ERP links, peer-to-peer messages, safety relays.
  5. Interview operators and maintenance staff about workarounds, nuisance alarms and things they bypass.
  6. Decide the scope: like-for-like conversion, or conversion plus improvements. Never mix the two without separate test cases.

Phase 2: design the target system

  1. Choose the target CPU and I/O with headroom for memory, scan time and future expansion.
  2. Decide whether to keep field wiring by using adapters or wiring-conversion systems, or to rewire.
  3. Plan the network: replace legacy fieldbuses where it makes sense and design zones and conduits as recommended in IEC 62443-3-2.
  4. Write or update the functional specification so the new code has something to be tested against.

What are the differences between SIMATIC S7-300 and S7-1500 PLCs?

RealPars

This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.

Watch on YouTube
A useful overview of the hardware and software differences that drive migration effort.

Phase 3: convert and test

  1. Run the vendor's migration tool, then review every converted block by hand; tools translate syntax, not intent.
  2. Replace obsolete instructions and system functions with native equivalents in the new platform.
  3. Restructure where it pays: modern data types, structured blocks and consistent alarm handling.
  4. Build a simulation of the machine or process and test the new code against it, including faults and restarts.
  5. Compare old and new behaviour signal by signal for the same input sequences; differences must be explained or fixed.
Siemens Simatic S5-95U compact programmable controller with connectors on its front panel
Controllers like the S5 and S7-300 ran plants for decades. The knowledge in their code is the real asset to migrate.

Phase 4: plan the cutover

  1. Choose the cutover strategy: big-bang in a shutdown, section by section, or parallel running with a changeover switch.
  2. Write a minute-by-minute cutover plan with go/no-go points and a tested rollback to the old system.
  3. Pre-build and test panels off site, and pre-terminate cables where possible to shorten the outage.

Phase 5: start up and hand over

  1. Run a structured site acceptance test using the same test cases as the simulation, signed off by operations.
  2. Hand over as-built code, drawings, a backup procedure and training for maintenance staff on the new tools.

How simulation changes the risk

The single biggest risk reducer is testing the converted code against a simulated plant before the shutdown. You can replay real production sequences, inject the faults operators describe and prove that the new system behaves like the old one. The ISA describes this approach as moving PLC debugging into a virtual environment before it reaches physical equipment (ISA InTech). Read more in what is virtual commissioning.

For a migration, the model does not need to be beautiful. A signal-level simulation of each station, with realistic timings and the faults your operators already know about, is enough to catch most conversion errors. Keep the same test cases for the site acceptance test, so the plant signs off against exactly what was proven in the office.

What drives the cost of a PLC migration

Cost driverWhy it mattersHow to control it
Quality of existing documentationUndocumented changes mean tracing on siteSpend more on the audit, less on site
Rewire versus reuse field wiringRewiring multiplies outage timeUse conversion systems where wiring is sound
Scope creepImprovements add test effortSeparate like-for-like and improvement packages
Number of interfacesEach SCADA, MES or peer link needs testingList them all in the audit
Cutover windowShort windows need more pre-testingSimulate and pre-build off site

Hardware is often the smaller part of the budget. Engineering, testing and the cost of production lost during cutover usually dominate, which is why time spent on the audit and on simulation testing pays back. If you need to prioritise across a site, rank controllers by spare-part risk and by the cost of an hour of downtime on the line they run, then migrate the worst combinations first.

How long does a PLC migration take?

For a single machine with one CPU and a few hundred I/O, engineering is usually a few weeks and the cutover a weekend. A whole line or process area takes months of engineering and is best cut over in stages. The audit is the part to never shorten: a day spent tracing an undocumented interface saves a day of lost production.

Wartens migrates ageing PLC and SCADA platforms with code conversion, testing and remote cutover support, engineered at our India centre. Start with our automation engineering service, check the FAT vs SAT guide for test planning, or send us your system list for a migration estimate.