Ask an operations manager what worries them about a control system migration and they will talk about the new controllers. Ask someone who has run one and they will talk about a Tuesday morning in the eighteenth hour.
The controller swap is the well-understood part. Vendors have migration tooling, the logic converts, the graphics come across. What consumes the schedule is everything the migration touches but does not own: wiring installed in 2004, a tuning constant somebody changed during a summer upset, an interlock bypass that has been in place so long it is now considered normal operation.
The four failure modes
| Failure mode | How it shows up | When it is usually found |
|---|---|---|
| Field wiring is not what the drawings say | Loops that will not check out; terminals that do not match the marshalling schedule | During loop checking, at the worst possible time |
| Undocumented configuration | Interlocks and bypasses that exist only in the old controller | When the plant behaves differently after startup |
| Historian tag names change | Reports, dashboards and compliance extracts silently break | Weeks later, when someone runs a monthly report |
| No rollback | A defect at hour three turns into an unplanned outage | At hour three |
None of these are exotic. All four are cheap to prevent and expensive to discover.
Survey the wiring before you quote the job
The single most useful thing you can do before a migration is verify that the field wiring matches the drawings. Not spot-check — verify. On a plant that has been running fifteen years, a discrepancy rate of a few percent is normal, and a few percent of two thousand terminations is sixty problems you will otherwise meet during commissioning.
If the marshalling is being retained, the survey is the deliverable that decides whether the schedule is realistic. If the marshalling is being replaced, the survey is what tells you whether the field cables will reach.
Decide what carries over and what gets rebuilt
Migration is the cheapest opportunity you will ever get to fix things that are wrong, and the easiest way to introduce faults that only appear during an upset. Both are true, which is why the decision has to be explicit rather than left to whoever is doing the conversion.
| Carry over verbatim | Rebuild deliberately |
|---|---|
| Control logic and interlocks — converted, then verified line by line against the source | Operator graphics — rebuilt to a current standard, with operators in the room |
| Tuning constants — they represent years of plant knowledge | Alarm limits and priorities that were never rationalised in the first place |
| Historian tag names — so existing reports keep working | Naming for anything that was already inconsistent |
| Interlock bypasses — but each one logged and owned, not silently copied | Anything whose original purpose nobody can explain |
That last row is the awkward one. Every old system has logic nobody can account for. Copying it forward is not safe and deleting it is not safe either. The workable answer is to list it, get an engineering decision on each item in writing, and carry the list into the cutover pack.
The cutover pack
Four documents, agreed before anyone touches a terminal.
| Document | What it must contain |
|---|---|
| Cutover sequence | Hour by hour, with a named owner for every step and an explicit point at which the plant is handed to the new system |
| Rollback plan | What is reverted, by whom, in what order, and the latest hour at which rollback is still possible. Written in advance, not improvised |
| Loop check register | Every loop, signed off on the new system before the plant takes it |
| Shadow period | How long the old system stays restorable after startup, and who decides when it is decommissioned |
A contractor who cannot hand you a written rollback plan has not thought about the day it goes wrong. That is not a paperwork complaint — it is the clearest available signal about how the project will be run.
Staged versus big-bang
The instinct is to do it in one outage because that looks cheaper. Sometimes it is. But the comparison is not cost against cost; it is cost against risk exposure.
| Approach | Suits | Main risk |
|---|---|---|
| Single cutover | Plants that can take one long, planned outage | Everything depends on one window |
| Unit-by-unit staging | Continuous plants with short shutdowns | Two systems coexist for months, and the interfaces between them have to work |
| Parallel run | High availability requirements, space available | Highest cost; needs somewhere to put a second system |
The staged route is usually right for continuous process plants, and it is also the one that most needs a competent integrator, because the interface between old and new is genuine engineering rather than configuration.
What to ask a bidder
Four questions that separate people who have done this from people who have read about it:
| Question | What a good answer sounds like |
|---|---|
| How will you verify the field wiring? | A survey scope with a sample size or a 100% claim, and a price attached |
| What is your rollback plan? | A described sequence and a decision deadline, not “we restore the backup” |
| How do you handle undocumented logic? | A register, an engineering review, a written decision per item |
| Who is on site at cutover? | Named engineers who also did the configuration and the FAT |
Related: control system migration, engineering, FAT and commissioning.
Start with an obsolescence review
Send us the controller models, firmware revisions, approximate I/O count and the shutdown window you can realistically get. That is enough for a first assessment.