Cross-vendor migrations happen for corporate standardization, obsolescence, or support reality — and they are re-implementations wearing a migration costume. Planning them honestly is the whole game.
The method
- Inventory beyond the CPU: I/O (voltage classes, special modules — the analog card with the odd range is the schedule risk), comms (every Modbus mapping is a contract to re-honor), HMIs, drives and their interlocks, and the undocumented boxes wired in sideways over the years.
- Extract specification, not code: the old program is evidence of behavior, not a source to transpile. Interviews with operators (what does it really do on jam?), captured sequences, alarm lists and the trace-equivalent recordings become the functional spec the new system is built — and accepted — against.
- Design the target natively: S7/TIA structures per our standards, not Modicon idioms rebuilt in Siemens syntax. Ladder-mimicry migrations carry the old system’s scar tissue into a body that has different physiology.
- Stage the cutover: parallel I/O where feasible, area-by-area over planned stops, old system removable only when the acceptance log says so — the same choreography as our S5 migrations, because the physics of downtime is vendor-neutral.
The traps: trusting converters for anything beyond inventory hints; migrating and “improving the process” in one step (two variables, one blame pool); and forgetting the people — the maintenance team’s fluency migrates slower than the code, so training is a project line item, not a courtesy.
FAQ
Typical timeline for a machine-scale migration? Engineering in weeks, cutover in shifts — proportions like our S5 work: months of preparation buying days of downtime.
Keep the old HMIs during transition? Rarely worth it — panel-generation compatibility is where transition scaffolding costs more than it saves.
Zone Otomasyon executes cross-vendor migrations with acceptance protocols both plant and finance sign. Migration planning.