PLC end of life: keeping legacy Siemens S5 controllers running

Many production lines still depend on programmable logic controllers that left the manufacturer's catalog long ago. The Siemens SIMATIC S5 family is the best known example: it has been discontinued for many years, and Siemens positions the SIMATIC S7 range as its successor. Yet S5 controllers still run presses, conveyors and process plants worldwide. This article explains how to manage that risk and migrate on your own schedule.

What end of life really means for a PLC

Discontinuation usually happens in phases: new sales stop first, then spare modules and official repair services are reduced and finally end. The controller still works, but every failure becomes harder to fix.

For the plant, the practical consequences are:

New original modules are no longer available from the manufacturer.
Programming tools and engineering knowledge become scarce. S5 programs are written in STEP 5, and fewer engineers are familiar with it every year.
Programming hardware and interfaces (for example the AS511 programming interface used by S5 CPUs) are not supported by modern laptops without adapters.
Ageing capacitors, backup batteries and EPROM memory modules cause more and more failures.

None of this means the machine must be replaced tomorrow, but the risk has to be managed actively.

Step 1: Take inventory of what you have

Start with a complete list of every S5 system in the plant. For each controller, record:

The machine or line it controls and how critical that line is.
The rack type and CPU model (for example S5-95U, S5-115U or S5-135U).
Every module in the rack, with the full order number from the label (the 6ES5 numbers).
Communication modules and connected devices, such as operator panels, drives and remote I/O.
Where the current program is stored, and whether that copy is verified.

The order numbers are the most important part. Siemens order numbers include version information, and replacement modules must often match closely to be accepted by the CPU and the program. Our guide on how to read a machine nameplate explains what to record from labels.

Step 2: Secure the program

A failed CPU or lost memory module is far more serious without a current program backup. Make sure that:

The program has been read out of every running CPU and stored in at least 2 locations.
The backup matches what is actually running, not an older version from commissioning.
Documentation, symbol tables and comments are stored together with the program.
At least 1 working programming setup (software, interface adapter and a computer that runs it) is available and tested.

Tip: Test your backup by loading it into a spare CPU on the bench, if you have one. A backup that has never been restored is only a hope.

Step 3: Decide on a spares strategy

For critical S5 systems, waiting for a failure and then searching for a module is the most expensive option. Typical spares options are:

Option	Advantages	Things to check
New old stock (unused original modules)	Original condition, no wear	Storage conditions, age of capacitors and batteries
Refurbished or tested used modules	Often easier to find	Who tested it, how, and what warranty applies
Repair of your own failed modules	Keeps the exact version you use	Availability of a capable repair service and turnaround
Spares taken from decommissioned machines	Matches your installed base	Unknown history, needs testing

A common approach is to keep a spare CPU, power supply and 1 of each I/O module type used in critical lines, and to test spares periodically.

Because S5 parts are no longer supplied through the manufacturer's normal channels, they have to be found through distributors, surplus dealers and specialists. A sourcing agency such as LiteHard can search this market on your behalf and check the exact order number and version before a quote is made. When buying used modules, follow the precautions in our article on counterfeit industrial parts.

Step 4: Plan the migration

Keeping spares buys time, but it does not remove the obsolescence problem. Sooner or later the controller should be migrated. Common migration paths are:

Full replacement with a current PLC

The S5 hardware is removed and replaced by a current controller, such as a Siemens S7 system. The program is converted or rewritten, and the wiring is moved to new I/O modules. This gives the cleanest result but needs the longest shutdown.

Staged migration

The CPU is replaced first while the existing I/O is kept for a period, using interface solutions available on the market, or the plant migrates line by line. This spreads the cost and the risk, and allows each stage to be tested before the next one.

Program conversion

Siemens has provided conversion tools for translating STEP 5 programs into S7 format. Converted code usually still needs manual review and testing, especially for timing, special function blocks and communication.

Retrofit with the machine builder

For complex machines, the machine builder or an integrator may offer a complete control retrofit, including drives and panels.

Whichever path you choose, keep the old system and its spares until the new one has proven itself in production.

Step 5: Review the plan regularly

The market for legacy modules changes over time, and the number of engineers familiar with STEP 5 keeps shrinking. Review your inventory, backups and spare stock at least once a year, and adjust the migration timeline if failures become more frequent. A structured critical spares plan helps to set priorities across all legacy systems, not only PLCs.

Key takeaways

Siemens S5 has been discontinued for many years, but it can still be run safely if the risk is managed.
Record every module with its full order number and keep verified program backups in at least 2 places.
Combine spares, refurbished modules and repair to cover critical lines until migration.
Plan a full or staged migration to a current platform such as S7 during scheduled shutdowns, not after a failure.