S5 racks from the eighties still run serious production. Every year makes their migration less optional and — as the people who knew them retire — harder. Lessons from the ones we have done:
The code is the smaller problem
Converters translate STL-era S5 code into S7 syntax; what they cannot translate is intent. Thirty years of patches, dead code, flags named after long-gone products — converting that faithfully reproduces the archaeology, bugs included. Our approach: use the conversion as a specification excavation, then re-implement cleanly in structured TIA code. It costs more upfront and saves it back the first commissioning week.
The genuinely hard parts: undocumented peripheral cards (IPs and CPs with configuration nobody has), timing behaviors the old scan rate accidentally guaranteed, and analog scaling conventions from before 27648 was standard.
I/O strategy decides the downtime
Big-bang replacement of racks and field wiring is a long stop with maximum risk. The staged pattern wins: new S7/ET200 I/O mounted in parallel, circuits migrated group by group at planned stops, terminal-for-terminal lists prepared in advance, old rack finally removed when it is an empty shell. Where wiring quality allows, wiring-adapter frames (S5 connector to ET200 terminals) compress the swap dramatically.
FAQ
Keep the old operator panels? No — the panel generation is the least survivable part; budget the HMI rebuild from the start and use it to fix the alarm philosophy too.
How long does a mid-size S5 migration take? Preparation months, downtime days: typically 2–4 weeks of engineering and staging for each planned stop measured in shifts, not weeks.
Zone Otomasyon has retired S5 racks without unplanned downtime — the machine keeps its habits, minus the fragility. S5 rescue plans.