On this page6 sections
Why brownfield migration is different
A greenfield control system is built to a specification. A brownfield migration has to reproduce behavior that has accumulated over years: logic changed online, interlocks added after incidents, timers adjusted during operation, and I/O repurposed without the drawings being updated. The running plant is the only complete specification, and it cannot be taken offline for long.
The usual drivers are hardware that is no longer manufactured or supported, programming software that no longer runs on current computers, a shrinking pool of people who know the platform, and security or capacity limits. None of these feels urgent until a processor or communication module fails without a spare — which is why migrations are best planned while the old system still runs reliably.
Audit what is really installed
The audit sets the risk of the whole migration. Treat every existing document as a claim to be verified against the plant.
- I/O list — reconcile against the physical terminals and field devices: tag, signal type, range, spare channels, and any channel reused for a different purpose.
- Program — upload the running program and compare it with the latest archived copy; the differences are undocumented online changes.
- Forces and bypasses — record every forced point, jumper and software bypass, and find out why each exists.
- Drawings — mark up loop diagrams, panel wiring and network drawings to their as-found state.
- Communications — list every system that exchanges data with the PLC: HMIs, SCADA, other controllers, drives, analyzers, historians and business systems.
- Spares and obsolescence — check the lifecycle status of every module, and the quantity and condition of spares held.
- Timing-sensitive functions — identify high-speed counters, fast interlocks, sequence timing and any logic that depends on scan time or scan order.
Engineering note
A common audit finding
An interlock that exists in the running program but in no document — added after a trip years earlier — is a frequent discovery. It must be understood and either retained deliberately or removed through management of change, never lost in conversion.
Choose a migration strategy
| Strategy | How it works | Production impact | Main risk | Suits |
|---|---|---|---|---|
| Big-bang | Old system removed and new system commissioned in one outage | One planned shutdown, long enough for the full cut-over | Everything must work at restart, with little time to resolve surprises | Plants with a planned turnaround of adequate length |
| Phased | Areas or units migrated one at a time, with old and new systems communicating during the transition | Several shorter outages or area shutdowns | Temporary interfaces between old and new systems must be engineered and tested | Larger systems whose areas can be isolated |
| Hot cut-over | Loops and I/O transferred while the process runs, one at a time, with each final element held in position during its transfer | No plant shutdown | Highest procedural risk — every transfer is a live operation | Continuous processes that cannot stop, with strong operations support |
A phased migration needs a temporary link between the old and new controllers — a gateway or communication interface carrying interlocks and shared signals across the boundary. That link is temporary but safety-relevant: it needs the same testing as the permanent system and a defined behavior when it fails.
Field wiring and code conversion
Reuse the field wiring where possible
Much of the migration risk sits at the terminals. Re-terminating hundreds of field cables under time pressure invites errors, so migrations commonly use wiring conversion interfaces — adapters or pre-wired harnesses that connect new I/O to the existing field terminations — or keep the existing marshalling and replace only the system-side cabling. Either way, maintain a cross-reference from old address to new address to terminal for every signal, and confirm that signal types, sourcing or sinking, and loop-power arrangements match.
Re-engineer the logic, do not transliterate it
Automated conversion tools produce a useful first draft, but platforms differ in ways that change behavior: timer resolution, data types and integer overflow, scan order, indirect addressing, retentive memory, first-scan initialization, and the state outputs take when the controller faults. Review the converted code against the audited behavior, rewrite what is obscure, and use the migration to document the logic properly.
Testing: FAT, parallel running and SAT
Factory acceptance testing (FAT) proves the new system against the functional description and the audited behavior, using simulated I/O. Test cases should cover normal sequences, every interlock and trip, communication failure and controller failure, not only normal operation. IEC 62381 describes FAT, site acceptance testing and site integration testing for process automation systems, and is a useful structure for the test plan.
Parallel running, where practical, gives the strongest evidence. The new controller reads the same inputs — through signal splitters or a read-only communication link — runs its logic with outputs disconnected, and its computed outputs and sequence states are compared with the old system's under real operating conditions. Check the loop budget before inserting splitters: every device added to a 4–20 mA loop adds voltage drop that the loop supply must still cover.
Site acceptance testing (SAT) then confirms each loop from field device to operator screen, including alarms, ranges and failure states, before the system is handed to operations.
Cut-over and fallback planning
Write the cut-over as a procedure, not a bar on a schedule. The fallback plan is part of it: the old system stays intact and restorable until the new one has proven itself, and the decision to roll back is made against agreed criteria at an agreed time — not improvised at the end of a long shift.
Step 1: Freeze the baseline
Final I/O cross-reference, program versions and HMI configuration frozen and backed up; restoring the old system has been tested, not assumed.
Step 2: Agree go/no-go criteria
Operations, maintenance and engineering agree what must be proven before production restarts, and the latest time at which roll-back will be decided.
Step 3: Prepare permits and procedures
Isolations, permits, temporary operating procedures and any authorized, time-limited bypasses in place before work starts.
Step 4: Transfer and loop-check
Signals transferred in the planned order, each loop checked from field device to screen against its check sheet.
Step 5: Prove interlocks and communications
Trips and interlocks function-tested; every external system confirmed to be exchanging data correctly.
Step 6: Hand over and support
Operators familiarized with the new screens beforehand, engineering support on shift through the first operating period, and open items tracked to closure.
Engineering questions
- When should a plant consider a PLC retrofit?
- When spares or support for the processor, I/O or communication modules are no longer assured, when programming software cannot be maintained on current computers, or when capacity, security or integration needs exceed what the platform supports. Plan it while the old system still runs reliably; a migration forced by a failure leaves no time for an audit.
- Can the existing field wiring be reused?
- Usually, if the cables and terminations are in acceptable condition and the new I/O supports the same signal types. Wiring conversion interfaces or retained marshalling can connect new I/O to existing terminations, which shortens cut-over and reduces termination errors. Cable and termination condition should be checked during the audit.
- Is a hot cut-over safe?
- It can be done safely, but it is the most procedure-dependent strategy. Each transfer needs a written step sequence, a way to hold the final element in position, operations staff present and a defined response if the process moves. It is chosen because the process cannot be stopped, not because it is simpler.
- How long does a PLC migration take?
- It depends on the I/O count, the quality of existing documentation, the chosen strategy and the outage windows available. The audit, engineering and testing phases normally take far longer than the cut-over itself — which is what allows the cut-over to be short.