Engineering question
What must be captured and tested before replacing an obsolete PLC in a running plant?
A PLC migration is not only a code conversion. The existing controls embody field wiring, undocumented interlocks, operator practice, failure responses, network dependencies and maintenance workarounds. A successful project converts that operating knowledge into an approved design and test record before the shutdown window begins.
Brownfield work should be risk-based. Safety instrumented functions, burner management, high-energy motion, regulatory sequences and unsupported third-party interfaces need specialist review. The migration team must define what is being preserved, deliberately changed, separately validated or left outside scope.
Calculation basis
Formulas and units
I/O reconciliation
Configured = field-proven + simulated/approved spare + documented exception
Every migrated channel should end in a testable disposition rather than an unexplained mismatch.
Cutover readiness
Ready only if prerequisites, FAT exceptions, backups, rollback and authorized people are confirmed
This is a gate, not a percentage score that can hide one critical omission.
Worked example
Apply the formula
A legacy rack lists 240 configured I/O points: 214 active, 12 confirmed spares and 14 unresolved.
- 1Walk down and loop-check the 14 unresolved points.
- 2Classify each as active, abandoned, spare or documentation error.
- 3Do not freeze the new I/O map while unresolved field circuits can still affect operation.
Result: The I/O baseline becomes defensible only when every point has an owner, evidence and disposition.
Discovery and design freeze
- Controller, rack, module, firmware and licence inventory
- Latest running program upload plus checksum and timestamp
- Electrical drawings, I/O list, loop sheets and network topology
- Sequence, interlock, trip, permissive and alarm rationalization
- HMI/SCADA tags, recipes, reports, historians and external interfaces
- Cybersecurity zones, accounts, remote access and time synchronization
- Approved functional design, cause-and-effect and change list
FAT and simulation
- I/O forcing policy and simulator boundary
- Normal sequences and every credible permissive failure
- Power-cycle, warm restart, communication loss and bad-quality behaviour
- Alarm priority, acknowledgement, shelving and timestamp checks
- Drive, remote-I/O, protocol and third-party interface tests
- Backup restore on representative hardware
- Open-punch ownership and shutdown acceptance criteria
Cutover and rollback
Prepare labelled wiring schedules, tested conversion cables where appropriate, backups, spare hardware, software tools and a minute-by-minute cutover plan. The rollback point must be time-bound and technically feasible; merely retaining the old PLC in a box is not a rollback plan. After first production, stabilize trends, alarms and operator workflows before closing the project.
- Authorized shutdown and permit
- Pre-cutover backups and photographs
- Point-to-point I/O proof
- Dry and wet sequence tests
- Production ramp with hold points
- As-built backup and handover
Common mistakes
- Migrating the latest offline file without proving it matches the running PLC
- Reusing old tag meanings without I/O walkdown
- Testing only normal production
- Deferring rollback design until cutover night
Troubleshooting checks
- Sequence stalls: compare permissive truth tables and scan/task timing.
- Intermittent network faults: verify topology, duplicate addresses, update rates and switch configuration.
- Analog values differ: compare module range, scaling and filtering.
- HMI status lags: inspect tag subscriptions, communications load and timestamp source.
Assumptions
- Plant owner provides access and operating knowledge
- Safety and regulatory systems receive their required independent review
- A shutdown and test window is approved
Limitations
- Checklist does not replace a project-specific risk assessment
- Automated code conversion cannot prove process equivalence
- Vendor lifecycle, licensing and cybersecurity requirements vary
Topic cluster
