APP-06Application
PLC & SCADA Migration: Brownfield Control System Modernization
Legacy control systems rarely fail all at once. They become harder to support: spare parts disappear, software no longer runs on current hardware, and the people who knew the logic move on. A migration replaces the platform while the plant keeps producing — which makes planning, not programming, the critical path.
| Tag | Service |
|---|---|
| IO-01 | I/O audit and mapping |
| GW-02 | Communication gateways and interfaces |
| HMI-03 | HMI and SCADA graphics conversion |
| DB-04 | Tag database and alarm list |
| CUT-05 | Parallel run and cut-over |
01Migration map
Migration interfaces between the existing and the new system
Each interface is where the existing and the new system meet. Select one to see what it covers, the typical methods and how it is carried through.
- Field wiring
- Data link
- Migration path
- Legacy — replaced
- Migration interface
- Selected signal path
I/O audit and mapping
- Why it matters
- The I/O list is the contract between the old and new systems. Verifying it against the installed wiring — not only the drawings — finds the spares, the undocumented additions and the signals that changed over years of modification. It also decides whether field wiring can be reused through adapters or must be re-terminated.
- Scope
- Every field signal: tag, address, signal type, range and function
- Typical methods
- Field walkdown and termination survey
- I/O list extracted from the legacy program and reconciled with drawings
- Wiring-conversion harnesses or adapter terminations where the I/O form factor allows
- Integration
- The verified I/O list becomes the basis for the new hardware configuration, the loop-check sheets and the cut-over sequence.
- Why it matters
- The I/O list is the contract between the old and new systems. Verifying it against the installed wiring — not only the drawings — finds the spares, the undocumented additions and the signals that changed over years of modification. It also decides whether field wiring can be reused through adapters or must be re-terminated.
- Scope
- Every field signal: tag, address, signal type, range and function
- Typical methods
- Field walkdown and termination survey
- I/O list extracted from the legacy program and reconciled with drawings
- Wiring-conversion harnesses or adapter terminations where the I/O form factor allows
- Integration
- The verified I/O list becomes the basis for the new hardware configuration, the loop-check sheets and the cut-over sequence.
- Why it matters
- Few plants can migrate everything at once. During the transition, new and legacy controllers must exchange data, and third-party devices — drives, analyzers, packaged units — must keep talking to whichever system controls them. Gateways and protocol converters bridge the two until each area is migrated.
- Scope
- Protocols and data exchanged with other systems
- Typical methods
- Protocol gateways between legacy serial or fieldbus links and Ethernet-based networks
- Modbus RTU / TCP, PROFIBUS / PROFINET, EtherNet/IP or OPC UA interfaces, as the devices require
- Network design with segmentation between control and business networks
- Integration
- Interfaces are tested in a staging environment with simulated or recorded traffic before they carry live control data.
- Why it matters
- Operators run the plant through the HMI. Converting displays is a chance to improve them — consistent faceplates, clearer alarm presentation, better navigation — but changes must be introduced with the operators, not imposed on them at cut-over.
- Scope
- Displays, faceplates, trends and navigation
- Typical methods
- Screen-by-screen conversion using a standard faceplate library
- Operator review of converted displays before commissioning
- Alarm rationalisation alongside the conversion
- Integration
- Graphics are linked to the new tag database, and operator training is scheduled before the new displays go live.
- Why it matters
- Every value the operator sees, and every alarm, is defined in the tag database. Migrated carefully, it preserves scaling, units, alarm limits and trend continuity; migrated carelessly, it is how alarm floods and mis-scaled values reach the new system.
- Scope
- Tags, scaling, engineering units, alarm limits, history
- Typical methods
- Automated export from the legacy system, reviewed line by line
- Naming convention and structure agreed before bulk import
- Historian mapping so old and new trends remain comparable
- Integration
- The reviewed database becomes the single source for PLC addressing, HMI tags and historian configuration.
- Why it matters
- Cut-over is where planning meets production. Where practical, the new system first runs in parallel — reading the same inputs and comparing results without controlling — before control is transferred area by area in planned windows, each with a tested fallback.
- Scope
- Sequence, tests and fallback for each area
- Typical methods
- Factory acceptance test against a simulated process; site acceptance test on site
- Parallel run in monitoring mode to compare old and new logic
- Area-by-area or loop-by-loop cut-over with loop checks and a documented rollback
- Integration
- Each transferred area is signed off with loop-check and functional-test records before the legacy equipment is decommissioned.
02Engineering context
Why the migration plan matters
Obsolescence is a risk that grows quietly. The longer a platform runs past vendor support, the fewer options remain when a processor, network card or workstation fails.
A migration is also the moment to recover knowledge. Undocumented logic, forced bits, bypassed interlocks and alarm floods all surface during the audit — and each is a chance to leave the plant better documented than it was found.
What protects production is the cut-over plan: which parts can move while the plant runs, which need a shutdown window, how each loop is tested, and how the plant falls back if something does not behave as expected.
Constraints that shape the migration
- Existing platform
- Legacy PLCs, remote I/O, HMIs and SCADA — often from several generations and vendors.
- Documentation
- Frequently incomplete; drawings, I/O lists and program comments have to be verified against the installed system.
- Production
- The plant keeps running; shutdown windows are short and planned well in advance.
- Field wiring
- Instruments and cabling are usually retained; terminations, marshalling and I/O form factors decide the reuse strategy.
- Networks
- Serial and legacy fieldbus links alongside Ethernet, with third-party devices that must keep communicating.
- Security
- New Ethernet connectivity needs network segmentation and access control designed in, not added later.
03Migration scope
What the migration has to carry across
The scope items a brownfield migration has to account for, where each one lives in the existing system, and how it is typically handled.
| Scope item | Location | Why it matters | Typical methods |
|---|---|---|---|
| I/O list | Legacy program, drawings, terminations | Defines hardware, wiring reuse and loop checks | Walkdown, extraction and reconciliation |
| Control logic | Legacy PLC programs | Interlocks, sequences and undocumented changes must carry over correctly | Logic review, functional specification, simulation |
| Communications | Networks, serial links, third-party devices | Keeps data flowing during and after the transition | Gateways, protocol interfaces, network design |
| HMI / SCADA displays | Operator stations | Operators must recognise and trust the new system | Graphics conversion, faceplate library, operator review |
| Tag database and alarms | SCADA, historian | Scaling, limits and trend continuity | Export, review, structured import, historian mapping |
| Cut-over | Each plant area | Production continuity and a safe fallback | FAT, SAT, parallel run, staged transfer |
I/O list
- Location
- Legacy program, drawings, terminations
- Why it matters
- Defines hardware, wiring reuse and loop checks
- Typical methods
- Walkdown, extraction and reconciliation
Control logic
- Location
- Legacy PLC programs
- Why it matters
- Interlocks, sequences and undocumented changes must carry over correctly
- Typical methods
- Logic review, functional specification, simulation
Communications
- Location
- Networks, serial links, third-party devices
- Why it matters
- Keeps data flowing during and after the transition
- Typical methods
- Gateways, protocol interfaces, network design
HMI / SCADA displays
- Location
- Operator stations
- Why it matters
- Operators must recognise and trust the new system
- Typical methods
- Graphics conversion, faceplate library, operator review
Tag database and alarms
- Location
- SCADA, historian
- Why it matters
- Scaling, limits and trend continuity
- Typical methods
- Export, review, structured import, historian mapping
Cut-over
- Location
- Each plant area
- Why it matters
- Production continuity and a safe fallback
- Typical methods
- FAT, SAT, parallel run, staged transfer
04Field → Control → Supervision
From the field to the control room
The same application seen as layers of one system — and the Spaaronn capability that engineers each layer.
Field
Measure and analyse at the process
Instrumentation
Field instruments and wiring are usually retained. The audit confirms their condition and identifies the few that need replacement as part of the migration.
- Field device condition survey
- Wiring and termination verification
- Targeted instrument replacement
Control
Decide and act on the signals
Automation & monitoring
New PLC hardware and logic engineered from a verified functional specification, tested against simulation before it meets the plant.
- Logic migration and review
- Hardware and I/O configuration
- Simulation and FAT
Supervision
See, record and report across the plant
Integration
New SCADA / HMI, gateways to remaining legacy and third-party systems, the tag database and historian — brought together as one supervised system.
- SCADA / HMI conversion
- Gateways and network design
- Historian continuity
05Project sequence
Typical project sequence
How this application is typically taken from requirement to a supported, running system.
- 01
Audit the installed system
Hardware, software versions, I/O, networks, documentation and known problems.
- 02
Define the migration strategy
Full or phased replacement, what is retained, and the target architecture.
- 03
Engineer and test off-line
Logic, HMI, tag database and interfaces built and tested against simulation.
- 04
Cut over in planned windows
Parallel run where practical, staged transfer, loop checks and a documented rollback.
- 05
Support after handover
Documentation, operator training and lifecycle support for the new platform.
Next steps
Where to go next
- 01IndustryManufacturingMachine automation, plant utilities and line-level monitoring.
- 02ResourceBrownfield PLC Migration: Planning Without Disrupting OperationsAudit, migration strategy, cut-over planning and testing for running plants.
- 03SolutionAMC & Lifecycle SupportPreventive maintenance, breakdown support, calibration support, troubleshooting and upgrades for installed systems.
Engineering enquiry
Planning a control system migration?
Share the installed platform, the plant areas involved and your shutdown constraints. We can help audit the system and shape a migration plan that protects production.