Migration
Allen Bradley to Siemens: what actually transfers, and what does not
Cross-brand PLC migration is sold as a conversion and delivered as a rewrite. Here is where the line falls.
Cross-brand migration gets quoted as if it were a translation exercise. It is not. Converting Allen Bradley logic to Siemens is closer to porting software between languages that share some keywords than to running a file through a converter, and the projects that overrun are almost always the ones scoped on the first assumption.
The useful question is not "can it be converted" but "which parts carry real information across the boundary". Some do. Most of the value does.
What carries across
| Element | Transfers? | What actually happens |
|---|---|---|
| I/O list and field wiring | Yes | The plant has not changed. This is the most valuable artefact you own and it maps directly. |
| Interlock and permissive intent | Yes, as information | The *logic* has to be rewritten. The *decisions* it encodes are the real asset and are worth documenting before anything else. |
| Ladder rungs | Partly | Simple contact-and-coil rungs map. Anything using AB-specific instruction behaviour does not. |
| Timers and counters | With care | Timebase and retentive behaviour differ. Silent differences here produce faults that appear weeks later. |
| Add-On Instructions | No | Rewritten as function blocks. Often an improvement, because the AOI usually accreted scope over years. |
| Analogue scaling | No | AB and Siemens raw ranges differ. Every scaled value gets rechecked against the actual transmitter range. |
| HMI screens | No | Rebuilt. Treat as new development and quote it that way. |
| Drive parameters | As data | Values transfer conceptually, but the parameter numbering is entirely different per vendor. |
The timer difference that catches people
An AB TON accumulates while the rung is true and resets when it goes false. A Siemens S_ODT behaves comparably, but retentive timers, the way accumulated values are held across a mode change, and first-scan behaviour after a download all differ in ways that are easy to miss on a bench test and awkward to find on a running plant. Every timer in a converted program should be looked at individually.
The strongest argument for cross-brand migration is not the hardware. It is that the logic is going to be opened up anyway, and this is the only realistic opportunity in a decade to restructure it — to separate device control from sequence control, to document the interlock matrix properly, and to remove the accumulated workarounds nobody dares delete while the plant is running.
Projects that treat migration as a like-for-like conversion get none of that value and still pay most of the cost.
How to scope one honestly
- Step 01
Recover and read the existing program
Before quoting. If there is no source, that recovery is its own priced piece of work.
- Step 02
Document the interlock matrix
Separately from the code. This is the artefact that survives the migration and it is worth having regardless.
- Step 03
Rebuild the I/O list against site
Not against the drawings. Discrepancies are normal.
- Step 04
Quote the HMI as new development
Because it is.
- Step 05
Plan the shutdown window backwards
From the window you can actually get, not from an ideal sequence.
Related services
More
- Maintenance
Your SCADA backup probably does not restore
The most common serious finding on a first maintenance visit is not a missing feature. It is that nobody has ever tested the backup.
- Retrofit
Planning a PLC changeover around the shutdown window you can actually get
The window is the constraint. Everything else in a retrofit is arranged around it, including the decision to stop.
Next step
Tell us what the plant is doing
Send the problem, not a specification. An engineer will come back to you — usually the one who would do the work.
An engineer responds within one business day.