An S7-300 to S7-1500 migration moves a Siemens control system from the long-serving S7-300 family, usually programmed in STEP 7 Classic, to the S7-1500 in TIA Portal. Siemens lists the S7-300 as available until 2033. That leaves time to plan properly, but not to wait: a plant with twenty S7-300 machines and limited shutdown windows needs years, not months.
The migration itself is well-trodden ground. What decides success is the preparation: knowing what is installed, deciding what to keep, testing before site and cutting over without losing production.
Why migrate before you have to
- Spares. As production winds down, spares get scarcer and dearer. A failed CPU on a critical line becomes a long stoppage.
- Skills. Fewer engineers are fluent in STEP 7 Classic every year, while TIA Portal is what new engineers learn.
- Capability. The S7-1500 has integrated PROFINET, supports OPC UA communication and has motion control functions on every CPU, which makes data capture and drive integration simpler.
- Planned not forced. A planned migration happens in your shutdown. A forced one happens when the CPU fails.
Step 1: build an inventory
List every S7-300 CPU, its firmware, the I/O modules, communications processors, connected HMIs and drives, and the network it sits on. Upload the current program from each CPU and compare it with the archive. On many sites they do not match, and the running program is the one that matters.
| Item | Why it matters | Decision to make |
|---|---|---|
| CPU and program | Size and complexity of conversion | Migrate, rewrite or replace machine |
| Distributed I/O (e.g. ET 200M) | Can sometimes stay with a new interface | Keep I/O or replace |
| PROFIBUS devices | May need gateways or replacement | Network strategy |
| HMI panels | Older panels may not support S7-1500 | Migrate HMI project or replace |
| Safety program | Needs re-validation after change | Safety plan and tests |
Step 2: choose the migration approach
There are three broad options. Converting the existing program in TIA Portal keeps the original structure and is fastest when the code is clean. Restructuring during migration costs more but leaves maintainable code that suits the S7-1500's optimised data blocks. Full rewrite makes sense when the old code is undocumented, patched for decades or no longer matches how the machine is used.
Step 3: deal with I/O, networks and HMIs
Replacing field wiring is where cost and downtime grow fastest. Where distributed I/O is in good condition, it can often be kept and connected to the new CPU with a suitable interface module, so only the CPU rack changes. PROFIBUS networks need a decision: keep them with a suitable master, add gateways, or move to PROFINET over time. Older HMI panels often need replacement too, which is a good moment to apply consistent screens and alarm handling.
Step 4: test in simulation before site
Run the migrated program against a simulation of the machine before the shutdown. Simulate the inputs the machine produces, step through every sequence, force faults and check the HMI. This is where you catch converted timers that behave differently, addressing errors and missing interlocks. It turns the shutdown into a planned swap rather than a debugging session. Our virtual commissioning guide explains the method.
What are the differences between SIMATIC S7-300 and S7-1500 PLCs?
RealPars
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeStep 5: plan the cutover
- Back up everything: old programs, HMI projects, drive parameters and network settings.
- Pre-build and pre-wire the new CPU rack and any adapter panels off site.
- Agree a test sheet that covers every I/O point and sequence, signed off by production.
- Keep the old CPU and program ready for fall-back until the new system has run a full production cycle.
- Re-validate safety functions where the safety program or hardware changed.
Code quality: use the migration to tidy up
A converted program runs, but it often carries decades of patches: absolute addresses, unused blocks, copied code with small differences, and comments in three languages. The S7-1500 works best with symbolic, optimised data blocks and reusable function blocks. You do not need to rewrite everything, but restructure the parts maintenance touches most, such as fault handling, recipe management and machine modes. Agree a short coding standard first, so every migrated machine ends up looking the same to the people who support it.
Also check the interfaces other systems depend on. SCADA, MES and neighbouring machines may read specific data block addresses. Either keep those addresses identical or plan the changes on the other side at the same time. A migration that works on the machine but breaks the line's data reporting is not finished.
Common surprises
- Third-party function blocks or know-how protected blocks that cannot be opened or converted.
- Communications processors for serial or PROFIBUS links with no direct S7-1500 equivalent.
- Timers and counters that behave slightly differently after conversion.
- Drives configured from the old PLC that need parameter or telegram changes.
Programme many machines, not one
For plants with many S7-300s, treat migration as a programme. Rank machines by risk (criticality times spares availability), group similar machines so one migrated program becomes the template for others, and fit the work into planned shutdowns across two or three years. A consistent approach also means one set of standards for code, HMI and documentation across the site.
If the machine is also changing function, read our guides to BS EN 60204-1 and UKCA marking before you start, because substantial modifications bring conformity obligations.
Next step
Send us the program backups and hardware list for one machine and we will return a migration scope, test plan and fixed price through our automation engineering service. Engineers who need TIA Portal skills can train through edWartens engineering training. Or contact us.
