Simatic S7-300 controllers have been running in Polish plants for over two decades and most of them still do exactly what they were programmed to do. The problem is not that they will stop working on some particular day. It is that the family is at the end of its lifecycle, and that changes the risk arithmetic: a CPU failure stops being a service event and becomes a procurement event. Below is a practical way to size your own exposure and plan the move to S7-1500 and TIA Portal — without guessing dates and without stopping production for a week.
What this guide will not do for you: dates
Siemens runs a formal lifecycle for every order number, with stages for sales, technical support and spare-part availability. Those stages are announced separately for individual CPUs, communication processors and I/O cards — the family does not disappear in one announcement on one day. So we quote no date here. The only reliable sources are the product page in the Siemens Industry Mall and the lifecycle information in Siemens Industry Online Support, checked against your own order numbers. If a quotation states an "S7-300 end of support" date with no order number and no reference, ask for the source.
What can be said safely: the direction is unambiguous, the successor in the portfolio is the S7-1500 programmed in TIA Portal, and investment decisions taken today should not assume that S7-300 will be the platform for another decade.
Inventory: two days of work that change the conversation
Before you can cost anything, you need a list. For every machine with an S7-300 controller, record:
- the order number and firmware version of the CPU and of every module, including communication and interface modules;
- the I/O topology: distributed ET 200M stations, the Profibus DP network, the count and type of cards;
- the drives and how they are commanded — fieldbus, analogue signal or contactors;
- the operator panel or SCADA station: model, software version, licences;
- where the STEP 7 project lives and whether it can actually be opened — licence, dongle and block passwords included;
- who last changed the program and whether that change reached the archive;
- the safety circuits: relays, safety controller, category and performance level from the documentation.
The most common discovery at this stage is not about hardware but about software: for several machines there is no current program source, or the only copy sits on a PC in the workshop that no longer has a power supply. That is a bigger risk than the missing spare CPU, because without the source even an identical controller will not bring the machine back.
Sizing the exposure: which machines are actually at risk
Not every S7-300 machine needs the same response. Rank them on three criteria:
- Consequence of a stop — what an hour of downtime on this machine costs and whether a workaround exists. A bottleneck with no workaround is in a different league from a duplicated machine.
- Software recoverability — whether you hold the source, a backup and a tested restore procedure. If not, move the machine to the top of the list regardless of its importance.
- Spare availability — how many units of the module are on the shelf and what the product page says.
The product of those three ratings gives an order you can defend to the board. It usually shows that two or three machines need a decision this year and the rest can wait for a natural moment: an overhaul, a product change, an expansion.
A spares strategy for the machines that stay
Moving the whole plant at once is neither possible nor necessary. For machines staying on S7-300 for a few more years, a spares kit makes sense: a CPU of the same type, a memory card, the I/O modules that fail most often and a power supply. When buying on the second-hand market, remember three things: check the firmware version, because an older one may refuse the project; insist on a powered test; and treat an unwarranted used part as insurance, not as an investment.
The intangible half matters just as much: the project in a repository, a written restore procedure and — the weakest point in most plants — one rehearsal of that procedure on the spare CPU. A backup nobody has ever restored is a statement of intent, not a safeguard.
A 1:1 swap or a redesign
In a 1:1 swap the mechanics, the field wiring and the process logic stay; the controller, the panel or part of it, and the program ported to the new platform change. It is the shortest route and the lowest risk, and it makes sense when the machine does exactly what it should and the only problem is the age of the control system.
A redesign is worth considering when at least one of these applies: the I/O topology changes, for instance moving from Profibus to Profinet or consolidating distributed stations; the risk assessment exposes gaps in the safety circuits; throughput or product mix is about to change; data has to leave the machine. Adding any of these after the retrofit is finished costs as much again, because the cabinet has to be opened a second time and the line stopped a second time.
What carries over from STEP 7 to TIA Portal
TIA Portal ships a project migration tool and it handles the standardised layer well: graphical-language blocks, data structures, symbol tables and the hardware configuration come across with their meaning intact and need review rather than rewriting. However:
- system blocks and library functions carry different identifiers and different interfaces on the S7-1500 — every call has to be looked at;
- direct memory access, absolute addressing and pointers behave differently under the new execution model, and this is the most common source of post-migration faults;
- statement-list code is often ported automatically, but the S7-1500 favours SCL, and for larger blocks rewriting beats maintaining a translation;
- cycle times and interrupt handling differ, so any logic resting on the assumption that "it will finish in time" needs checking;
- communication and safety functions are configured differently and are almost always built from scratch.
A realistic rule: tool-assisted migration produces a working starting point, not a finished program. What remains is a block-by-block review and testing — and that part, not the port itself, drives the schedule. If a quotation offers "automatic migration" with no line item for review and testing, it is incomplete. We describe the scope of that work on the Siemens PLC, HMI and SCADA programming page.
WinCC V7, operator panels and the road to WinCC Unified
A controller retrofit almost always drags the visualisation layer with it. Older operator panels configured in pre-TIA tools will not migrate on their own, and a WinCC V7 station is a separate product, not an older version of the WinCC built into TIA Portal — moving to WinCC Unified is a project, not an upgrade.
What usually carries over: the screen structure, the tag list, texts and alarm lists, recipes. What gets rebuilt: scripts, because the model and the language change; graphics based on old object libraries; reports and database connections; user and permission handling. A practical tip: treat it as the chance to delete the screens nobody has opened in five years. Porting a redundant screen costs exactly as much as porting a needed one.
The downtime window: how to fit it into a weekend
A control retrofit fits into a single weekend only when most of the work has already been done. The sequence that works:
- a replacement cabinet built in parallel, off the line, with the new controller and new internal wiring;
- the program ported and tested on the bench with simulated signals — and, for harder machines, against a process model;
- a factory acceptance test with a list of test cases signed off by maintenance;
- in the window itself: field re-termination, a check on every signal, dry runs, a start-up with product;
- a rollback plan — the old cabinet stays serviceable and reconnectable until the next overhaul instead of going straight to scrap.
The window comes from the production calendar, not the supplier's: a planned shutdown, a holiday break, a product changeover. The production line modernisation and machine retrofit page describes the full scope of this work.
The test list before the line is handed back
The minimum worth demanding in the acceptance protocol:
- every input and output checked by physically forcing the signal, not from a table in the project;
- trials of every safety function: emergency stop, guards, light curtains, with stopping times measured rather than taken from a datasheet;
- behaviour after a power loss and restoration, and after losing communication with the panel;
- alarms: every message triggered and checked, translations included;
- throughput: the cycle measured on product and compared with the cycle before the retrofit;
- handover: program sources, a backup, as-built cabinet documentation, drawings, instructions and training for every shift, not just the first one.
If the retrofit changes safety functions or the way the machine behaves, a risk assessment and conformity documentation come on top — from 20 January 2027 under the new Machinery Regulation. We cover that in the guide to the EU Machinery Regulation 2023/1230.
Cost, funding and the order of operations
Retrofit cost splits into four items: hardware, meaning the controller, modules, panel and cabinet parts; electrical design and panel build; software engineering including testing; and on-site commissioning. The proportions depend on whether you take the 1:1 swap or the redesign, and that is the only honest answer without seeing the machine. Modernisation capex is often eligible under investment support programmes; we keep the current routes on the automation and digitalisation grants page.
The order that works: inventory, exposure rating, securing the software with a restore rehearsal, a spares kit for the machines staying on the old platform, migrating the two most exposed machines in the next window, then the rest at the pace of scheduled overhauls. You can do the first two steps in-house in a week, and they remove the most risk.