Multi-Version PCS 7 Upgrade Paths from V7.0 to V9.0 SP2 and Run-Mode Limitations

Upgrading SIMATIC PCS 7 from V7.0 to V9.0 SP2 cannot be performed in a single direct step, nor does it require installing every minor service pack. The officially supported migration path requires stepping through two intermediate baseline milestones: (1) Upgrade from V7.0 to PCS 7 V7.1 SP4 (on Windows XP / Server 2003); (2) Upgrade from V7.1 SP4 to PCS 7 V8.2 SP1 (on Windows 7 / Server 2008 R2); and (3) Upgrade from V8.2 SP1 to PCS 7 V9.0 SP2 (on Windows 10 LTSC / Server 2016). Furthermore, upgrading across major architectural generations and 32-bit to 64-bit operating systems CANNOT be performed in RUN mode; an AS controller stop and full OS compilation are strictly mandatory.

Executive Summary

Modernizing legacy automation infrastructure from SIMATIC PCS 7 V7.0 to modern PCS 7 V9.0 SP2 represents a decade-long leap in industrial computing architecture, transitioning from 32-bit Windows XP environments to 64-bit Windows 10 multi-threaded platforms. Faced with dozens of Siemens migration documents, engineering managers and plant integrators often struggle to determine the minimum number of intermediate software installations required. Crucial questions also arise regarding whether upgrades can utilize delta compilation to execute in RUN mode without plant downtime, and how 'Software Update with Utilization of New Functions' differs from 'Software Update without Utilization of New Functions'. This article details the official multi-version migration sequence, clarifies run-mode limitations, and outlines licensing requirements.

Architecture and Fundamental Mechanics

The technical constraints governing multi-generation PCS 7 migrations are dictated by database, driver, and OS boundaries:

Operating System and Database Generations:
- PCS 7 V7.0 / V7.1: Built on 32-bit architecture (Windows XP Professional / Windows Server 2003), utilizing Microsoft SQL Server 2005.
- PCS 7 V8.0 / V8.1 / V8.2: Built on 64-bit engineering architecture (Windows 7 SP1 / Windows Server 2008 R2), utilizing Microsoft SQL Server 2008 R2 / 2014.
- PCS 7 V9.0 SP2 / V9.1: Modern 64-bit architecture (Windows 10 Enterprise LTSC / Windows Server 2016/2019), utilizing Microsoft SQL Server 2014 SP2.
Because database schemas cannot migrate directly across three major SQL Server versions without intermediate conversion scripts, the project database must be opened, converted, and saved in specific intermediate PCS 7 releases.
The Milestone Migration Path: According to Siemens migration guidelines (SIOS ID 39980937), intermediate service packs (e.g., V7.1 SP1, SP2, SP3, V8.0, V8.1) can be skipped. The verified milestone sequence is:
$$\text{V7.0} \longrightarrow \text{V7.1 SP4} \longrightarrow \text{V8.2 SP1} \longrightarrow \text{V9.0 SP2}$$
With vs. Without Utilization of New Functions:
- Without Utilization of New Functions: Hardware configuration and existing CFC chart logic remain untouched. Blocks retain their legacy library versions (e.g., Standard Library). The WinCC OS project is updated to run on the new OS version. This provides the fastest migration path with minimal re-engineering, but cannot leverage APL features, CMTs, or PROFINET diagnostics.
- With Utilization of New Functions: Standard blocks are migrated to the Advanced Process Library (APL). Module drivers are regenerated to modern versions, and OS faceplates are modernized. This unlocks all modern PCS 7 capabilities but requires extensive re-testing and validation.
Why Software Update in RUN (TCiR) is Impossible: Type Change in RUN (TCiR) and Software Update in RUN are only supported on redundant S7-400H systems within tightly constrained minor version boundaries (e.g., V8.1 to V8.2, or V9.0 to V9.0 SP1). Jumping across major operating systems, SQL versions, and major library revisions alters internal block footprints and communication protocols, which prevents CPU memory matching. A complete AS STOP and full download are mandatory.

Step-by-Step Implementation Procedure

Execute the multi-version migration using isolated intermediate engineering environments:

Milestone 1: Archive and Upgrade to V7.1 SP4

In the live PCS 7 V7.0 system, create a complete multi-project archive (File -> Archive).
Set up an engineering virtual machine (VM) running Windows XP SP3 or Windows Server 2003 with PCS 7 V7.1 SP4 installed.
Retrieve the V7.0 project in V7.1 SP4. Open the project in SIMATIC Manager. Confirm database conversion prompts.
Open HW Config and NetPro; perform a Save and Compile on all stations.
Archive the migrated V7.1 SP4 project.

Milestone 2: Upgrade to V8.2 SP1

Set up a second VM running Windows 7 SP1 (64-bit) or Server 2008 R2 with PCS 7 V8.2 SP1 installed.
Retrieve the V7.1 SP4 archive. Launch the PCS 7 Project Migrator if prompted to migrate WinCC SQL databases.
Open the project in SIMATIC Manager. Compile HW Config and CFC charts.
Archive the cleanly compiled V8.2 SP1 project.

Milestone 3: Upgrade to V9.0 SP2

On the final production Engineering Station running Windows 10 Enterprise LTSC (or Server 2016), install PCS 7 V9.0 SP2.
Retrieve the V8.2 SP1 archive.
In SIMATIC Manager, perform a full Compile and Download Objects check.
If upgrading with new functions, update block types from the APL V9.0 Master Data Library and regenerate module drivers.
Run OS Project Editor to modernize WinCC graphics and compile all OS projects.
Schedule planned plant downtime, place AS controllers in STOP, and execute a full AS and OS download.

Verification

Verify project integrity across the migrated architecture:

Offline Database Check: In SIMATIC Manager V9.0 SP2, select File -> Save As -> With Reorganization (Slow). Confirm that the database reorganizes cleanly without structure errors.
Simulation Validation: Download the compiled AS and OS programs into S7-PLCSIM and WinCC Runtime. Verify that process interlocks, control loops, and graphic faceplates execute identically to the original V7.0 baseline.
Licensing Verification: Open Automation License Manager (ALM) on all V9.0 nodes. Confirm that upgrade licenses (PCS 7 Upgrade Packages, AS RT POs, WinCC RT) are active and transferred from license USB sticks.

Limitations and Operational Precautions

Never attempt to compile or download to physical production controllers directly from intermediate migration VMs. Migration VMs should serve strictly as offline database conversion platforms. Furthermore, ensure hardware compatibility: legacy CPU 414-4HJ04 controllers and CP 443-1 modules from early V7.0 releases may be phased out or unsupported in PCS 7 V9.0 SP2, requiring hardware upgrades. Final license counts and hardware MLFBs must always be verified with an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

Do I need to install all intermediate service packs (V7.1 SP1, SP2, SP3)?

No. You only need the milestone intermediate versions: PCS 7 V7.1 SP4 and PCS 7 V8.2 SP1. Intermediate minor updates can be skipped.

Can I upgrade from V7.0 to V9.0 SP2 without stopping the plant?

No. Software Update in RUN (TCiR) is only supported within minor version boundaries on redundant H-CPUs. Jumping across multiple generations requires a complete plant shutdown and controller restart.

What happens if I upgrade 'without utilization of new functions'?

The project retains its original block types and legacy library algorithms. It runs on modern Windows 10 hardware and WinCC V7.4/V7.5, but cannot use APL faceplates or CMT features.

Why can't WinCC V7.0 databases open directly in WinCC V7.5?

WinCC V7.0 used Microsoft SQL Server 2005, whereas WinCC V7.5 uses SQL Server 2014 SP2. The SQL schema must be converted step-by-step through intermediate SQL versions.