Migrating a control system is not a software upgrade. It is a plant availability problem with a software component. The controller replacement is the easy part; the risk sits in the cutover window, the field wiring you are not allowed to disturb, and twenty years of configuration nobody fully documented.
When this becomes urgent
| Trigger | What it means in practice |
|---|---|
| Vendor end-of-support announced | Spares come from the grey market; firmware fixes stop |
| Operator stations on an unsupported OS | Security exception paperwork every year, and eventually a refusal |
| Nobody left who knows the configuration | Every change is a research project |
| Cannot add I/O | A small plant modification triggers a system-scale decision |
None of these are emergencies on the day they appear, which is exactly why they get deferred until they are.
Migration routes
| Route | How it works | Best when |
|---|---|---|
| Like-for-like controller swap | New controllers, existing marshalling and field wiring retained | Field wiring is sound and documented |
| Staged unit-by-unit migration | One unit at a time over successive shutdowns | The plant cannot take one long outage |
| Parallel run with cutover | New system built alongside, switched at a defined window | Availability requirement is high and space allows |
| Full replacement | New controllers, new marshalling, new graphics | Wiring is at end of life anyway |
Configuration carry-over
The part clients underestimate. A control system is not just logic — it is alarm limits, tuning constants, interlock bypasses, historical tag names that reports depend on, and operator graphics people have used for a decade. Re-typing all of it is how you introduce faults that only surface during an upset.
| Carried over | Deliberately rebuilt |
|---|---|
| Control logic and interlocks, verified line by line | Operator graphics, rebuilt to current standards with operator input |
| Tuning constants and alarm limits | Alarm rationalisation — a migration is the cheapest moment to fix a bad alarm set |
| Historian tag names, so existing reports keep working | Naming for anything that was already inconsistent |
Cutover
| Deliverable | Why it exists |
|---|---|
| Cutover plan | Hour-by-hour sequence, with named owners per step |
| Rollback plan | What we do if hour three goes wrong — written before, not during |
| Loop check record | Every loop proven on the new system before the plant takes it |
| Shadow period | Old system kept restorable for an agreed window after startup |
If a contractor does not hand you a written rollback plan, they have not thought about the day it goes wrong.
Platforms we migrate
| From | To |
|---|---|
| Yokogawa CENTUM CS 3000 | CENTUM VP |
| Legacy Siemens S7-300 / classic PCS 7 | S7-1500 with TIA Portal, current PCS 7 |
| Older Allen-Bradley PLC families | ControlLogix / CompactLogix with Studio 5000 |
Start with an obsolescence review
Before quoting a migration we would rather look at what you actually have — controller models, firmware revisions, I/O count, wiring condition and the shutdown window you can realistically get. Contact us.
Start with an obsolescence review
Controller models, firmware revisions, I/O count and the shutdown window you can realistically get.