PLC Migration Checklist
Updated · Written by HAM International Trade Team
A PLC migration plan covers more than hardware and code conversion. Baseline the as-built system; map every I/O, network, HMI, drive, safety, data and external interface; define converted behaviour and exceptions; then plan offline tests, site tests, cutover, acceptance, rollback, training, spares, and as-built records with named owners.
Freeze the as-built baseline before designing the target
Collect hardware, rack and slot layout, I/O, wiring, networks, addresses, HMI and SCADA links, drives, robots, vision, safety, recipes, data, external handshakes, programs, libraries, parameters, firmware, alarms, diagnostics, software, licences and backups. Compare documents with the live machine under authorised procedures. Mark discrepancies rather than silently updating one source.
Record behaviour code alone may not explain: sequences, permissives, interlocks, startup, recovery, manual modes, fault handling, timing, retained data, workarounds, quality checks and maintenance practice. Decide what must remain, what will change, and who approves each change.
Migration workstream map
The controller sits at the centre of connected systems and accountable work.
Hardware and I/O
physical path
Power, racks, modules, wiring, panels, terminals, field devices and spares
Logic and motion
machine behaviour
Programs, timing, sequences, parameters, drives and robots
Networks and data
information flow
Networks, HMI, SCADA, historians, MES, remote access and time
Safety and compliance
independent acceptance
Risk assessment, safety functions, validation and change approval
Cutover and operations
controlled transition
Test, outage, rollback, production trial, training and support
Convert with a discrepancy register
Map old constructs to the target and record every automatic conversion, manual rewrite, unsupported instruction, data-type or address change, timing assumption, communication change, alarm change and deliberate improvement. Link each discrepancy to an owner, resolution, test and approval. Do not bury unresolved messages inside a conversion report.
Protect scope. Mandatory migration work, as-built correction, reliability improvement and new feature are different categories. Combining them can be valid, but each needs a reason and test. The goal is controlled behaviour, not identical source text.
Readiness gates before shutdown
A failed gate returns work to its owner; it does not become an outage-day experiment.
- 01
Baseline gate
Inventory, backups, narrative and interface owners are sufficient to design.
OUTPUTApproved baseline
- 02
Design gate
Architecture, mappings, discrepancies, safety, test and rollback are reviewed.
OUTPUTIssued design
- 03
Offline test gate
Code review, simulation or bench tests cover planned cases and exceptions.
OUTPUTSite-test candidate
- 04
Cutover gate
People, parts, tools, access, time and stop criteria are ready.
OUTPUTAuthorised outage
- 05
Acceptance gate
Site and production evidence meets criteria; deviations have disposition.
OUTPUTAcceptance or rollback
Design rollback before cutover
Rollback needs an executable time, not a sentence. Identify the last decision point, old hardware and backups, wiring reversibility, data restoration, network changes, authority, remaining outage window, and tests after restoration. Some panel changes make full rollback impractical; state fallback stages honestly.
Define who can continue after a failed test, what defect forces rollback, which temporary workaround is prohibited, and who informs production, quality and maintenance. Log outage decisions with time, evidence, approver and consequence.
PLC migration scope and acceptance
Each item needs evidence and an owner; checking it does not replace engineering judgement.
- As-built hardware, I/O, wiring, networks, software, versions and backups are controlled
- Sequences, modes, interlocks, alarms, diagnostics, timing and retained data are described
- HMI, drives, robots, safety, SCADA, historian, MES and handshakes are mapped
- Conversion exceptions and changes have tests and approval
- Offline, site, safety and production tests have expected results
- Cutover resources, access, tools, permits, roles and escalation are ready
- Rollback or fallback is timed, resourced and authorised
- Training, spares, support, security and as-built records are delivered
Close with operational evidence
Archive released programs, parameters, configuration, firmware, drawings, network records, tests, deviations, safety validation, licences, recovery media and history in the controlled repository. Confirm maintenance can connect, diagnose, back up and restore. Define early-life support and defect ownership after production resumes.
HAM can source defined Japanese components within an approved design. Architecture, conversion, safety, testing, cutover and site acceptance remain with qualified controls and plant owners.
Frequently asked questions
- Can this checklist replace an engineering plan?
- No. It exposes workstreams and evidence. Design, risk assessment, test cases, procedures and acceptance must be specific to the machine and site.
- Should new features be included?
- Only when separately scoped, owned and tested. Mixing features into mandatory conversion increases diagnosis and rollback difficulty.
- What makes rollback credible?
- A decision time, retained hardware and backups, reversible interfaces or fallback, authorised people, sufficient window, and a tested restoration procedure.