Siemens S5 to S7 Migration: Scope, Steps & Downtime

S5 to S7: What changes on the machine?

A changeover needs to account for the whole machine or plant: what is connected to the controller, what documentation is available, and how long can production stop?

Area	What this means for your plant
Controller	The S5 CPU is replaced. The new SIMATIC controller must meet the plant's functional, performance, and interface requirements.
Program	The existing code is transferred, adapted, and tested. Special functions and communication need individual review.
Wiring and field devices	Cables, sensors, and actuators can stay if their condition and electrical characteristics are suitable. Adapters allow field wiring to be reused with specific module combinations.
Operator controls and interfaces	Operator panels, drives, and supervisory systems need compatible interfaces to the new PLC.
Work involved	The work involved varies from one machine or plant to another. It depends on the existing program, available documentation, and installed modules and interfaces.
Production downtime	Programming and preliminary tests are carried out before the changeover wherever possible. Replacement, testing, and acceptance need a planned shutdown window with a rollback plan.

Warning: Assess safety functions before the retrofit!

Before the changeover, consult a safety specialist about the applicable directives and how the retrofit affects the machine's safety systems. Include the necessary modifications and tests in the plan from the start. The machine may only be released for production once the affected safety functions have been tested and signed off.

We provide PLC programming and migration services, from the initial assessment through to commissioning.

---

Introduction

The SIMATIC S5 is one of the longest-lived PLC families Siemens ever built. Introduced in the late 1970s, it still runs reliably in many plants today. This article covers what's actually involved — technically and organizationally — when you decide to migrate off S5, and what to watch out for along the way.

Where the S5 stands today

There is no single date on which every component in the SIMATIC S5 family reached the same lifecycle milestone. Siemens has described S5 components as no longer being in regular production for many years, while the specific P.M500 date varies by article number. P.M500 marks the end of the product lifecycle and regular support. Any remaining spare-part, exchange, or repair services must be checked using the full article number in the Siemens product catalog and with the regional service partner. The used and third-party market can provide a temporary bridge, but not a guaranteed supply strategy. The status levels are explained in the Siemens lifecycle definitions.

At the same time, STEP 5 expertise is becoming less common, while training and vendor documentation focus on current SIMATIC systems and TIA Portal. This creates a staffing and availability risk for operators: the practical question is whether internal or external STEP 5 expertise will actually be available during assessment, changeover, and fault recovery.

According to the Siemens product timeline, the S7-300 and high-channel-count ET 200M generally reached P.M410 status in October 2025. P.M410 means product cancellation and the start of the spare-parts phase: new units are generally no longer available, while spare-part, exchange, or repair services may still be available for specific articles. The S7-300 is therefore not a sensible target for a new migration. A current S7-1500 or ET 200SP CPU is often the right direction; after redesign, an S7-1200 G2 may also fit a smaller application.

What actually gets migrated

The most common misconception: PLC migration means swapping the CPU. In practice, an S5 to S7 migration covers several areas.

The application program — written in STL, FBD, or LAD, typically grown and modified over many years. The HMI connection — often older OP/TP operator panels whose exact product status depends on the model, including their screens, tag lists, and communication drivers. The communication interfaces — serial, PROFIBUS, or proprietary — to variable frequency drives, scales, load cells, or supervisory control systems. And the documentation that describes the current state of the system.

All of this falls within the scope of a migration. It's worth capturing the full picture early in the project.

Safety, CE marking, and substantial modification

Replacing a controller does not automatically constitute a substantial modification of the machine, nor does it automatically trigger a new conformity assessment. The deciding factors are whether the migration creates new hazards, increases existing risks, or requires changes to safety-related control functions and protective devices. This assessment must be documented for the specific machine and the actual scope of change.

Before implementation, establish whether emergency stops, safety doors, restart interlocks, and safe states remain functionally unchanged. Determine whether safety relays, fail-safe controllers, PROFIsafe components, or safe drive functions will be replaced, and whether response times, stopping distances, operating modes, or remote-access capabilities will change. Where safety functions are affected, functional testing, validation, and formal acceptance belong within the project scope. In its example for migrating a safety program, Siemens notes that changes to safety-certified hardware may create a new collective F-signature and require renewed acceptance of the safety program.

For machinery in the EU, Directive 2006/42/EC and its respective national implementation still apply as of this article's update date. EU Machinery Regulation 2023/1230 applies from 20 January 2027. It explicitly defines a substantial modification as potentially physical or digital and, where the conditions in Article 18 are met, assigns manufacturer obligations to the person making the modification. This is still not a blanket determination: it requires a traceable risk assessment and, where necessary, competent legal or machinery-safety review.

A defensible acceptance package includes at least the change and risk assessment, a list of affected safety functions, test records for safe inputs and outputs, documented response or stopping times where relevant, and approval by the responsible persons.

What happens during code conversion

The tool route documented in the Siemens S5/S7 migration guide has two stages. First, the S5/S7 converter supplied with STEP 7 V5.x processes the STEP 5 program file (*ST.S5D) and the required cross-reference list (*XR.INI); an existing assignment list (*Z0.SEQ) can also be included. The tool generates an STL source, converted symbol data, and a file containing warnings and errors. Only after the result has been reviewed and compiled without errors in STEP 7 V5.x is the project migrated into TIA Portal. There is no generally valid conversion percentage.

The differences cannot be reduced to “S5 uses bytes, S7 uses bits” — both systems support bit, byte, and word access. Address areas, pointer formats, indirect addressing, data blocks, and organization-block event models differ. There is no universal replacement pair for communication either: depending on the S5 CPU, communication processor, and protocol, SEND/RECEIVE handling blocks may need to be mapped to TSEND/TRCV_C, PUT/GET, or another suitable S7-1500 mechanism. Startup logic from OB20, OB21, and OB22, plus special and communication functions, must therefore be understood, adapted, and tested individually — but not automatically rewritten in full.

With an S7-1500 migration there is more to consider: TIA Portal and the S7-1500 are designed around symbolic programming and optimized blocks. Optimized data blocks are addressed symbolically; data blocks with standard access can still be addressed symbolically and absolutely. Optimized data blocks can be substantially larger than the classic 64 KB, but the actual limit depends on the CPU, block type, and access mode. Existing absolute accesses, pointers, and external communication partners may therefore require deliberately non-optimized interface areas. A migration can range from a functionally equivalent transfer to a structured software rebuild.

Three common strategies

Full changeover. The plant stops and everything is replaced within one approved production window. This works well for manageable machines with clear documentation and previously tested target hardware. Advantage: clean cut, no parallel operation. Disadvantage: limited room if something takes longer than planned. Required downtime can only be derived from scope, pretesting, acceptance, and the rollback plan.

Phased migration. Two technical paths must be kept separate. A front-connector adapter connects existing S5 field wiring to a new S7 module: the wiring stays, but the S5 I/O module is replaced. Keeping S5 expansion racks in service temporarily requires a separately engineered coupling. The IM 463-2 is a specific S7-400 solution for certain S5 expansion units, not an S7-1500 module. Siemens documents the supported combinations and electrical differences in its manual for S5/S7 interface module adapters. A phased migration can shorten individual outage windows, but it extends the total schedule and adds integration and testing effort.

Parallel operation. S5 and S7 run simultaneously while plant sections are migrated individually. This requires a communication bridge suitable for the existing interfaces and programmers who can work in both environments. For critical processes, it can spread the changeover risk, but it also creates additional transitional states.

Documentation: the part that's easy to underestimate

A practical observation: many S5 systems do not have complete, up-to-date documentation. Electrical drawings have not been updated since the last modification, programs lack comments or symbol tables, and sometimes there is no current backup of the application program.

Before any migration begins, there is an assessment phase: read the program from the CPU using a suitable STEP 5 environment and adapter, compare the online and offline versions, review the signals, document I/O allocation, and trace communication paths. An important limitation is that a CPU upload provides the executable program but does not automatically restore offline comments, symbols, and plant documentation. The effort therefore depends less on the S5 model than on documentation quality, program scope, special modules, and interfaces.

This isn't extra work — it's the foundation for everything that follows. The cleaner the assessment, the more predictable the rest of the project.

What drives the cost

Quoting specific prices without knowing the system would be guesswork. But the cost drivers are clear.

More effort is needed when: documentation is missing, there are many communication interfaces (each one must be understood and assessed for reuse or adaptation), the S5 program contains custom solutions, operator panels have no direct migration path, and there are many distributed stations. Depending on the engineering environment already available to the operator or integrator, licensing and version maintenance for STEP 5, STEP 7 V5.x, TIA Portal, WinCC, and simulation may also be required.

Less effort when: documentation exists, the program is manageable in size, peripherals are standard, and field wiring plus PROFIBUS slaves can be reused.

Planning for downtime

Software development and testing happen beforehand. S7-PLCSIM is supplied with TIA Portal and executes the controller program on the development machine. This allows CPU logic and defined test sequences to be checked in advance. Real I/O modules, field devices, and physical process behavior are not reproduced automatically. Comprehensive communication, HMI, or process simulation may require S7-PLCSIM Advanced, a process model, or test hardware.

A weekend can be a suitable changeover window, but it is not a reliable standard duration. The approved window should be derived from pretests, a detailed runbook, acceptance criteria, and a rollback scenario with a realistic time limit. Materials, verified backups, suitable engineering hardware, and the responsible specialists must be available on site.

A phased approach can shorten individual production interruptions. It also creates additional transitions, couplings, and acceptance steps; whether the overall operational impact is lower depends on the plant architecture and the partial shutdowns the operation can support.

Common stumbling blocks

A few things that come up repeatedly in S5 to S7 migrations: the program scope gets underestimated because the machine looks simple from the outside. HMI dependencies surface late — the operator panel is part of the migration too. Communication interfaces to drives or supervisory systems don't get tested until the plant is supposed to go live. And there's no rollback plan, even though one should be standard equipment for every changeover.

What can stay

Not everything needs to be replaced. Field wiring, sensors (4–20 mA, Pt100, incremental encoders), actuators, and contactors can remain if their condition, electrical characteristics, diagnostic capability, and current safety requirements are suitable. Documented I/O adapter solutions exist for specific module combinations, allowing an existing S5 front connector to be connected to a new S7 module. Potential distribution, signal voltage, channel count, load capacity, and switching frequency must be checked before use.

One example from our work is the modernization of a TGW automated small-parts warehouse. We renewed the controls and visualization using Siemens SIMATIC. The existing mechanics and conveyors stayed in place.

PROFIBUS slaves — drives, distributed I/O, valve terminals — can remain after compatibility and lifecycle checks. The target controller needs an integrated PROFIBUS DP interface or a suitable communication module such as the CM 1542-5; not every S7-1500 CPU is itself a DP master. The GSD file, telegram structure, diagnostic behavior, and spare-parts risk of each participant must also be reviewed. Equipment that is technically compatible and operationally supportable does not need to be replaced.