STEP 7 to TIA Portal migration: the code problems nobody warns you about

A STEP 7 to TIA Portal migration has two halves. The first, bringing a STEP 7 V5.x project into TIA Portal, is largely automated and quick. The second, making that code run correctly and maintainably on an S7-1500, is where the engineering hours go. The tool converts syntax; it cannot decide what the original programmer meant. This article lists the code problems we meet on almost every migration and how we deal with them.

It is written for controls engineers who will review or maintain a migrated program, and for managers who want to understand why a "converted" project is not yet a finished one.

The two stages of a STEP 7 to TIA Portal migration

1. Project migration. The STEP 7 V5.x project is brought into TIA Portal, still targeting the S7-300 or S7-400 hardware. This step should compile without errors before you go further.
2. Platform change. The hardware is changed to an S7-1500 and the code adapted to its instruction set, memory model and communication. This is the real work.

Keep the two stages separate in your project plan and in your version control. If behaviour changes later, you want to know whether it came from the import or from your adaptation.

Pitfall 1: absolute addressing and optimised blocks

Classic S7 code often reads data by absolute address: DB10.DBW4, or worse, pointers built at runtime. S7-1500 data blocks default to optimised block access, where symbolic access is the norm and absolute offsets are not available. You can switch a block back to standard access, and sometimes that is the right short-term answer. For maintainable code, convert to symbolic access and replace pointer arithmetic with arrays and structured data types. It is the single largest effort item in most migrations.

Pitfall 2: system functions that changed

Many SFCs and SFBs from the S7-300/400 world are replaced by newer instructions on the S7-1500, or behave differently. Typical examples are diagnostic calls, time and date handling, and communication blocks. Each one needs to be found, understood in context and replaced, with a test that proves the new instruction does what the old one did in that program.

Pitfall 3: STL, timers and hidden behaviour

• STL. Statement List runs on the S7-1500, but STL that manipulates accumulators, the status word or address registers directly is fragile and hard for the next engineer to read. We rewrite critical STL networks in SCL or LAD.
• Timers and counters. Old S5 timers and counters work differently from IEC timers. Converting them is easy; getting the reset and edge behaviour exactly right is not.
• Scan-time assumptions. Code that relied on the slower cycle of an old CPU can behave differently on a fast S7-1500, for example edge detection across cycles or watchdog logic.
• Uninitialised data. Behaviour on restart and the retentive memory concept differ. Check every block that depends on start-up values.

Pitfall 4: communication and HMI

Connections to HMIs, SCADA, other PLCs and drives are often the last thing checked and the first thing to fail at cutover. Old S7 connections, PROFIBUS links and CP-based communication must be rebuilt for the S7-1500 and PROFINET. HMI tags pointing at absolute addresses break as soon as you convert data blocks to symbolic access. Plan the HMI migration as part of the same work package.

Pitfall 5: missing or misleading documentation

Many STEP 7 projects in the field are not the version that runs in the PLC. Someone made an online change in 2019 and never saved it offline. Before migrating, upload the program from the running CPU, compare it with the archived project, and resolve every difference. Migrating the wrong version is the most expensive mistake on this list, because it surfaces only at cutover.

How to prove the migrated code is right

Comparison testing is the answer. Before migration, record how the original machine behaves in each mode and fault case, from the operator's and the process's point of view. After migration, run the same cases on a virtual S7-1500 in PLCSIM Advanced, driven by a model of the machine, and compare. Our article on virtual commissioning with PLCSIM Advanced shows the set-up. Anything that differs is either a migration error or a bug in the original that you now decide whether to keep.

Clean up while you are there

Testing also protects the people who sign off the migration. With a recorded comparison test, the maintenance lead does not have to trust that the code is right; they can see it. A migration is the cheapest moment to bring old code in line with a modern standard: consistent naming, reusable function blocks, structured data types and comments in the language your maintenance team uses. The PLCopen coding guidelines are a good neutral reference, and the current edition of IEC 61131-3 supports the structured, object-oriented style the S7-1500 handles well. Put the result under version control from day one.

Wartens migrates STEP 7 projects to TIA Portal and S7-1500 as fixed-price work packages. See our automation engineering services and the wider plan in S7-300 end of life. Next step: send us one project archive and we will return a list of the pitfalls it contains. Contact us.