SIMATIC S5 to S7-400 Migration: Engineering Justification Guide

Overview: Why the S5 to S7-400 Migration Is No Longer Optional

SIMATIC S5 controllers have been the workhorse of European process and factory automation since 1979. Three decades of installed base mean that many plants still operate large S5 networks — frequently 10, 20, or more CPUs tied to WinCC V6.0 or WinCC flexible servers. Field reports of S5 plants operating reliably for 20+ years are routine. Yet the platform has reached end of commercial life, and engineering teams running mixed S5/S7 architectures encounter a recurring class of problems that the S7-400 generation eliminates by design.

The two most common pain points documented in operating plants are:

1. Server-side memory growth on WinCC V6.0: redundancy partners slowly consume RAM until swap activity brings the HMI to a crawl, forcing a manual restart of the WinCC pair every few months.
2. CP-side latency in PROFIBUS and Industrial Ethernet segments: older CP 5611 / CP 1612 communication processors, paired with S5-135U/155H CPUs, exhibit slower reconnection and slower tag polling than modern CP 5613 / CP 1613 hardware.

Both problems can be mitigated, but the long-term engineering answer is migration to SIMATIC S7-400 (or S7-1500 for greenfield work). The justification rests on three pillars: product lifecycle status, performance and diagnostics, and engineering toolchain continuity. This reference consolidates Siemens official lifecycle data, CP module comparison, memory diagnostics procedures, and a migration roadmap suitable for a 12-CPU plant tied to redundant WinCC V6.0 servers.

SIMATIC S5 Product Lifecycle and Spare Part Availability

Siemens formally announced the phase-out of the SIMATIC S5 family in 2003. The discontinuation was staggered by product line so that customers could plan migration in waves. The dates that matter for spare-part planning and budget justification are summarized below.

As of 2024, all S5-90U/95U/100U and S5-115U spare-part guarantees have expired; only the S5-135U/155U/155H lines remain on the formal spare-parts list via the "Send-in for repair" program. From a budget-approval standpoint, every additional year of S5 operation now carries an increasing risk premium: a failed CPU 928B or CPU 948 cannot be replaced from stock and may trigger weeks of downtime while a refurbished unit is located.

Refer to the official Siemens migration portal for the most recent spare-parts status of any specific S5 article number: Siemens Industry Online Support.

Diagnosing the WinCC V6.0 Memory Leak Phenomenon

A 12-CPU S5 network front-ended by redundant WinCC V6.0 servers that runs for "several months" before slowing down is the classic signature of an unbounded growth pattern in the WinCC process image, the archive database, or the OPC/COM link layer. The S7 parallel network "functions correctly" because newer S7 controllers expose different diagnostic data and the S7 driver path through CP 5613/1613 is implemented as a different process model than the S5 path through CP 5611/1612 + SIMATIC NET OPC.

Step-by-step Memory Diagnostics

1. Baseline the WinCC server before commissioning the change. Capture Working Set (Private), Commit Charge, and Page Faults/sec from PerfMon /report over a representative operating day.
2. Enable WinCC diagnostic tags from the WinCC Information System. The internal tag @PRF_FreeArchiveSegments, @PRF_ArchiveCount, and the redundancy status tags expose archive and partner-state growth.
3. Sample every 60 seconds for 72 hours to see if Working Set is bounded or trending upward. A slope above ~50 MB / week on a 12-CPU tag set is the threshold for an S5-network leak.
4. Inspect the redundancy partner swap log: WinCC V6.0 redundant servers historically exhibit leak growth after an unintended failover, not during steady state. Confirm that RedundancyState stays at Primary/Standby.
5. Check the SIMATIC NET OPC server for stale group handles: an S5 network polled via S7ONLINE using the CP 5611/1612 path can retain disconnected group subscriptions that the OPC daemon never releases.

Most Common Root Causes in S5 + WinCC V6.0 Plants

The pragmatic answer for a 12-CPU S5 plant is rarely "fix the leak" — it is eliminate the leak source by migrating the affected data path. Once the underlying S5 CPUs are replaced with S7-400 + CP 443-1 and the new OPC path uses S7ONLINE over ISO-on-TCP, the WinCC driver layer changes substantially and the leak pattern does not reproduce.

CP 5611 / CP 5613 and CP 1612 / CP 1613: Why the Hardware Matters

The choice of communication processor on the engineering station (or the WinCC server) is the single most overlooked performance lever in an S5 plant. The S5 driver stack is:

• CP 5611 (PCI) / CP 1612 (PCIe): original PROFIBUS-MPI / Industrial Ethernet card; older ASIC; lacks hardware-side connection pooling.
• CP 5613 (PCI) / CP 1613 (PCIe): successor with on-board processor for protocol termination; supports up to 64 simultaneous S5 connections with deterministic reconnection.

The S7-1500 / S7-400 driver path through CP 1623 / CP 1628 is yet a third generation, but for an S5-to-S7 migration the immediate upgrade from CP 5611 → CP 5613 (or CP 1612 → CP 1613) typically yields:

• 30-60% lower average tag round-trip time on saturated networks
• Elimination of "ghost reconnect" events that trigger OPC group refresh storms
• Improved handling of S5 CPU restart diagnostics — the S5 OB1/OB21 startup blocks are polled faster and WinCC picks up the restart in under one tag cycle

Article numbers for the typical upgrade:

Cross-reference the SIMATIC NET manual for firmware compatibility: SIMATIC NET PC Software.

Functional Comparison: SIMATIC S5 vs SIMATIC S7-400

The engineering argument for migration is most credible when grounded in concrete functional differences. The table below compares the dominant S5 CPU classes against the typical S7-400 migration targets.

Bit-execution figures sourced from the Siemens S7-400 CPU data sheets; compare against the CPU 944 / CPU 948 manuals archived on the Siemens support portal.

Migration Architecture: Reusing I/O vs Full Replacement

A 12-CPU S5 plant can be migrated in one of three patterns. The decision is driven by I/O count, signal type, and outage tolerance.

Pattern A: Adapter-Based Reuse (Lowest Outage)

For each S5 rack, insert a SIMATIC S5-IM to S7 IM adapter (e.g., the SIMATIC ET 200S with S5 adapter, or third-party S5 bus adapters) so the existing S5 I/O modules can be re-inserted into the new S7-400 rack. This is feasible only for digital I/O modules; analog and intelligent modules require replacement.

Pros: Minimum wiring disturbance, fastest mechanical retrofit.

Cons: Adapter cost per slot, no access to modern diagnostic data from the legacy modules, third-party adapter means mixed-vendor support.

Pattern B: S7-400 with New ET 200M Distributed I/O

Replace each S5 with an S7-400 plus IM 460/461 interface modules or directly attach ET 200M stations over PROFIBUS. Each ET 200M carries a Siemens S7-300 series of I/O modules (SM 321 / SM 322 / SM 331 / SM 332) that are S7-400 native.

Pros: Field wiring can often be preserved terminal-by-terminal; PROFIBUS diagnostics and channel-level fault reporting become available.

Cons: Requires PROFIBUS segment installation; ET 200M stations must be configured in STEP 7 hardware configuration; long marshalling cables need re-termination.

Pattern C: Full Replacement with ET 200SP / ET 200MP

New I/O migration using ET 200SP on PROFINET for greenfield or major overhaul work. This is the recommended pattern when migration is part of a broader plant digitalization effort because it provides full PROFINET diagnostics, channel-level health, and predictive maintenance data.

Pros: Best diagnostic capability, lowest long-term maintenance, prepares for S7-1500 follow-on.

Cons: Highest wiring rework; PROFINET infrastructure (managed switches, ring topology) must be installed.

STEP 5 to STEP 7 Program Conversion

Program conversion is the longest engineering task in any S5 → S7 migration. The official tool is the "S5 to S7 Converter" (shipped as an add-in to STEP 7 V5.x, with a successor in the TIA Migration Tool). The converter handles approximately 70-85% of code automatically; the remaining 15-30% requires manual rework.

Conversion Mechanics

Conversion Workflow

1. Export STEP 5 source files from each S5 CPU using the S5 files utility (or from a STEP 5 project backup).
2. Open the S5 file in the S5 → S7 Converter; select the target CPU (CPU 414-3 PN/DP or CPU 417-4H).
3. Run the converter. Address the converter's diagnostic log: every warning or error indicates a construct requiring manual review.
4. For each converted FB, recompile in STEP 7 and run the symbol table against the I/O assignment documentation. S5 "M" flags mapped to physical functions often have comments that were never written back into the program — those must be reconstructed from the original electrical drawings.
5. Run a function-by-function simulation in S7-PLCSIM before connecting to real I/O.
6. Run a parallel-operation phase where the S5 and the new S7-400 drive the same field devices via shared input / OR'd output relays. Verify behavior under normal operation, then under each alarm condition.

Refer to the official Siemens migration manual for code-conversion caveats: SIMATIC S5 to S7 Migration Manual (PDF).

WinCC V6.0 Migration Path

WinCC V6.0 (released 2004) reached end of mainstream support and is replaced by WinCC V7.x and WinCC Professional in TIA Portal. A migration that touches the PLC layer but not the SCADA layer leaves the operator stations on aging software; this is generally a false economy.

Recommended WinCC Upgrade Path

1. Stage 1 (parallel): Add a WinCC V7.5 server alongside the WinCC V6.0 server. Use the WinCC redundancy option to mirror alarms and archive data. Keep V6.0 as the source of truth during the S5-to-S7 cutover.
2. Stage 2 (cutover): Once each S7-400 is commissioned and the WinCC V7.5 server carries the new driver path (S7ONLINE over TCP/IP), swap operator clients from V6.0 to V7.5.
3. Stage 3 (decommission): Shut down the V6.0 server; the V7.5 server remains as the sole SCADA node with optional redundant partner.

Tag and Screen Migration

WinCC V6.0 project files (MCP / DBM files) are forward-compatible with WinCC V7.x with minimal loss. Use the WinCC Project Migrator to upgrade in place. Verify:

• All OPC tags re-bind correctly (S5 AS511 driver names change in V7.x)
• User Archive layouts preserved
• Alarm logging classes preserved
• Redundant archive paths on shared storage retain R/W permission for the new service account

Step-by-Step Migration Plan for a 12-CPU Plant

1. Inventory and risk-rating. Document all 12 CPUs with article number, firmware, age, and connected I/O. Flag any unit on the S5-135U/155U "defect-exchange only" list as priority.
2. Freeze the change-control scope. Lock all S5 program edits for the duration of the migration; this prevents drift between the converted S7 and the live S5.
3. Replace CP 5611 with CP 5613 (or CP 1612 with CP 1613) on each WinCC server. This is the lowest-effort, highest-impact first step and often stabilizes the memory-leak symptom.
4. Upgrade WinCC to V7.5 on the standby server. Run redundancy for two weeks to confirm no regression on alarm throughput or archive retention.
5. Build the first S7-400 pilot using one of the 12 CPUs (preferably a non-critical line). Convert the program with the S5-to-S7 Converter, manually clean the diagnostic log, simulate in PLCSIM, then run in parallel with the S5 for two weeks minimum.
6. Cutover the pilot. Hot-swap field wiring to the new rack during a planned outage. Keep the S5 on standby for one week.
7. Repeat for the remaining 11 CPUs in batches of 2-3 per quarter, depending on outage windows. Roll the WinCC tag set and the S7 driver configuration in lockstep with each batch.
8. Decommission S5 hardware after a 30-day observation period on the final S7-400. Return defective S5 CPUs via the "Send-in for repair" program for whatever residual credit is available.

Verification Checklist After Each Cutover

• CPU RUN status, SF / BF LEDs green, no diagnostic buffer entries other than informational startup events
• All ET 200M stations report healthy (green channel LEDs, no station failure)
• WinCC tags reflect current process state within one polling cycle (typically 1 s)
• Alarms from the new S7-400 appear in WinCC alarm logging within 2 s
• Redundancy status remains Primary / Standby with no unintended failover for 24 hours
• Archive segments swap successfully on the new server with no growth beyond the configured daily rate
• Power-up test: cycle the S7-400 off and on; verify all outputs go to their configured "safe state"

Troubleshooting Matrix: Common Migration Symptoms

Cost Justification Worksheet for Management

When requesting capital for migration, frame the justification along four axes that finance and operations teams understand.

1. Spare parts risk. Estimate the mean-time-to-recover (MTTR) if an S5 CPU fails today. With defect-exchange pricing, MTTR for an S5-155H CPU can exceed four weeks. Multiply by the line's hourly revenue loss to get the annual exposure.
2. Maintenance labor. Engineers trained on STEP 5 are now near retirement; STEP 7 and TIA Portal engineers are abundant. Labor cost differential on a 12-CPU plant over a 10-year horizon is material.
3. Cybersecurity. S5 has no access control beyond a 4-character PG password; S7-400 supports CPU access protection, signed firmware, and integrated firewall on the CP 443-1. Industrial-security regulations (IEC 62443) increasingly mandate these controls.
4. Operational visibility. S7-400's diagnostic buffer and PROFINET diagnostics reduce mean-time-to-diagnose (MTTD) by an order of magnitude versus S5 status-word inspection. This translates to fewer quality excursions and faster line recovery.

Combine these four axes into a 5-year NPV calculation. Most 12-CPU S5 plants crossing the 30-year age mark find the NPV strongly favors migration when spare-parts risk and labor scarcity are included.

FAQ