PCS7 v7 to v9 Migration: 6-Phase Plan Without Breaking Pharma Production

On a Swiss pharma site, halting a production line for one day costs between CHF 80,000 and 250,000 depending on the product. Migrating the SCADA is rarely a priority as long as everything works. Except that Siemens announced the end of standard support for PCS7 v7 in 2020, the end of extended support in 2025, and Windows Server 2008 (which still runs many v7 systems) no longer receives any patches. In the field, we regularly see sites still on v7.1 SP2 with 12 to 15 years of accumulated production, validated GMP batches, and a legitimate fear of breaking everything.

This guide describes the six-phase methodology we apply with our pharma clients in French-speaking Switzerland to migrate to PCS7 v9.1 without losing a single hour of production runtime. The figures and examples come from real, anonymized projects.

Why Migrate Now, Really

End of support is not a sufficient argument for a pharma investment committee. What actually tips the decision is almost always a combination of three factors.

First, security. A PCS7 v7 on Windows Server 2008 is exposed to unpatched CVEs, and Swissmedic or FDA auditors have been asking the question since 2022. On one site, we saw an internal audit raise 14 obsolescence-related non-conformities, including 4 critical ones. The short-term remediation cost exceeded that of a full migration.

Then hardware compatibility. New HPE or Dell servers are no longer certified for Server 2008, and drivers are missing. When a disk fails, you can no longer find a BIOS-compatible replacement.

Finally, MES and data historian integration. PCS7 v9 natively exposes OPC UA with certificate-based security, which v7 only does through fragile add-ons. If you deploy a MES like Werum PAS-X or Körber, v9 becomes a technical prerequisite, not a comfort feature.

Our [industrial automation](/services/automation) and [system architecture](/services/architecture) services integrate this cost-benefit analysis into the initial scoping.

The Real Risks of a Failed Migration

Before discussing method, we must name the real risks. Three categories concern us.

Production runtime loss. A modified FB without exhaustive testing can produce different deterministic behavior (typically on PID regulators after v9 recompilation). On a bioreactor or lyophilizer, this translates to a rejected batch, so CHF 200,000 to 800,000 lost.

GMP deviations. Any modification to the automated control system must be validated according to GAMP 5. A poorly documented migration invalidates the existing qualification. The auditor then demands full re-validation, adding 6 to 9 months to the project.

Loss of history. Process Historian v7 and v9 databases are not binary compatible. A poor archive migration strategy results in losing 5 to 10 years of batch data, which is unacceptable for GxP traceability.

Phase 1: Audit the Existing System (2 to 4 Weeks)

The audit is not a license inventory. It is a complete technical and functional mapping. We systematically document.

AS (Automation System) hardware with exact CPU references, memory size, real cyclic load. A 417-4H CPU at 78 percent load will not support adding OPC UA communication blocks in v9.

Firmware versions on each ET200 rack, each CP 443-1, each PROFIsafe coupler. Siemens compatibility lists between AS firmware and PCS7 version are strict and condition the migration.

Automation code by functional unit. A v7 PCS7 project typically contains 40 to 200 CFCs, 100 to 500 SFCs, and 20 to 80 custom faceplates. Not all migrate with the same effort. Custom blocks written in SCL or inline CFC require particular attention.

Network architecture, distinguishing field buses (PROFIBUS DP, PROFINET IO), system bus, and terminal bus. H-System redundancies add a layer of complexity to the cutover phase.

Output of this phase: an audit dossier of 60 to 120 pages with a risk matrix per item. Without it, project pricing is fortune-telling.

Phase 2: Scoping and Target Architecture (3 to 5 Weeks)

This phase produces the functional specification of the v9.1 environment. Four decisions structure everything else.

Hardware strategy. Either keep the AS and migrate only the OS/ES portion ("OS-only migration"), or replace the CPUs as well. The first option allows a 4 to 8 hour cutover per AS, the second requires a 24 to 72 hour shutdown and functional re-qualification.

Windows Server choice. PCS7 v9.1 supports Server 2019 and 2022. For a site with a 10-year horizon, we systematically recommend Server 2022, more aligned with corporate IT policies.

Virtualization strategy. Hyper-V remains the Siemens reference, but VMware vSphere has been validated since v9.0. If site IT is full VMware, stay homogeneous for operations.

MES, historian, and Active Directory integration. Too many migrations fail because these dependencies are discovered in the test phase. Interfaces must be documented at scoping.

The deliverable is an FDS (Functional Design Specification) signed by production, quality, IT, and automation. Without these four signatures, do not launch the next phase.

Phase 3: Mirror Test Environment (4 to 8 Weeks)

This is where you physically build the new platform, but outside production. The goal is to have a v9.1 system running with a copy of the v7 code, simulating the entire chain.

We install a test AS (often a 410-5H CPU to stay consistent with the target), virtualized OS and ES servers, and restore a recent image of the production project. The v7 to v9 conversion is done via the PCS7 Migration Tool, which automates about 80 percent of the work.

The remaining 20 percent are the real subjects. Faceplates with obsolete ActiveX (to be replaced by WPF), VBS scripts to convert or rewrite, custom alarm shelves to reconnect, OPC DA integrations to migrate to OPC UA.

This phase also produces the test harness. We typically write 200 to 600 functional test cases, structured by automation unit. It seems enormous, but it is actually the minimum to remain credible before a GxP auditor.

Phase 4: Batch Migration with Regression Testing (6 to 16 Weeks)

Rather than migrating everything at once, we cut into coherent functional batches. On a typical pharma site, this gives 5 to 12 batches corresponding to process units (preparation, transfer, fermentation, formulation, primary packaging).

For each batch, the cycle is identical. Convert v7 code to v9 on the test environment, run associated test cases, fix detected deviations, cross-review code between two automation engineers, quality sign-off on the test dossier.

Regression tests are what distinguish a serious migration from an optimistic one. Concretely, we compare trace by trace the PID values, SFC cycle times, alarm triggers between v7 and v9 on the same scenarios. A deviation greater than 0.5 percent on a setpoint requires investigation.

It is also during this phase that surprises emerge. A ratio calculation FB that returned NaN under certain conditions in v7 and now returns 0 in v9, because float handling has changed. On a product dosing operation, this can create an OOS (Out Of Specification). We have seen this, the deviation represented CHF 30,000 of product lost in simulation.

Our [pharma CQV team](/services/cqv) intervenes in this phase to produce IQ, OQ, PQ protocols and the GAMP 5 traceability matrix.

Phase 5: Qualification and Cutover Preparation (4 to 6 Weeks)

Once all batches have been tested in the mirror environment, you prepare the cutover. This phase covers three dimensions.

Formal qualification. Execute IQ (Installation Qualification), OQ (Operational Qualification), PQ (Performance Qualification) protocols on the target environment. Each result is traced, signed, archived. A serious pharma site generates 800 to 1,500 pages of documentation here.

Operator and maintenance technician training. v9 novelties (redesigned faceplates, new alarm management, OPC UA) typically require 8 to 16 hours of training per profile. Do not skip this, it is what generates nighttime calls in the first weeks after cutover.

Rollback plan. Before each batch cutover in production, you must be able to revert to v7 in less than 2 hours if a major problem appears. This requires ready system images, tested procedures, and ideally a cutover window during a planned shutdown.

Phase 6: Production Cutover (1 to 4 Weeks)

The actual cutover is the most stressful phase but also the shortest if everything else has been done well. We always proceed by functional batch and always during planned production windows (CIP/SIP, campaign change, maintenance weekend).

For each batch, the typical sequence over 16 to 24 hours. Complete v7 backup (system image plus database dump plus recent historian archives). Physical PG cutover to the new ES, loading of the validated v9 project, AS transfer with CRC check, progressive startup in supervised mode. Production tests on a subset (typically a non-critical equipment of the batch first), then progressive ramp-up over 8 to 12 hours.

For the first 72 hours, we maintain reinforced on-call support with an automation engineer on site. Beyond D+30 without major incident, we consider the batch stabilized.

On our last pharma project in Vaud, 9 batches migrated in 14 months, zero rejected batch, zero unplanned shutdown. This result is nothing exceptional, it is the standard when the method is applied.

Common Pitfalls We Systematically See

Three pitfalls return in almost all the failed projects we are called to recover.

The first, underestimating custom faceplates. These are often ActiveX written 12 years ago by an integrator who no longer exists. Their migration can represent 30 to 50 percent of total effort and bad surprises accumulate.

The second, neglecting the historian. Process Historian v7 databases must be migrated with a dedicated tool, and the integrity check must be documented. Otherwise, you lose GxP archiving and the auditor detects it.

The third, wanting to migrate everything at once. It is faster on paper, and it is exactly how you end up with a line stopped for three days and a complete re-validation to do.

French-Speaking Switzerland Field Feedback

On 4 pharma projects led in recent years in the Lake Geneva region and the Jura Arc, the average total cost of a v7 to v9 migration (excluding AS hardware if retained) is around CHF 380,000 to 750,000 for a medium site (1 to 3 processes, 4 to 8 AS). Total duration, audit to end of cutover, is 9 to 18 months.

The classic mistake consists of comparing this figure to the license purchase cost (CHF 40,000 to 80,000). This 1-to-8 ratio between licenses and real project cost is nothing abnormal in a GMP environment, it is the qualification that weighs.

If you are starting this type of project, let us talk. Our team has done this migration on Roche, Lonza, and several Romandy CDMO sites, and we know exactly where the bones are. You will find some [sector references](/references) and our [contact](/contact) on the site.

See also our [pharma sector](/secteurs/pharma) page for the full scope of our GMP services.

Frequently Asked Questions

How long does a PCS7 v7 to v9 migration actually take on a pharma site?

Between 9 and 18 months for a medium site, audit to end of cutover. Multi-process sites with lyophilization, fermentation, and formulation can exceed 24 months. The longest phase is rarely the technical one, it is almost always GAMP 5 qualification that sets the pace.

Can we migrate without changing the AS automation systems?

Yes, it is even often recommended. PCS7 v9.1 supports classic 41x series CPUs provided the firmware is in the right range. The "OS-only migration" option reduces hardware costs by about 40 percent and limits the per-batch shutdown window to 4-8 hours instead of 24-72 hours.

What is the main cause of PCS7 migration failure?

The absence of a representative mirror test environment. Teams that test directly on production discover deviations too late, must rollback, lose confidence, and the project slips by 6 to 12 months. Investing CHF 60,000 to 120,000 in a test environment saves 3 to 5 times that amount in slippage avoidance.

Do we need to redo all GMP qualification after migration?

No, unless you change the system functionality. A controlled version migration is treated as a GAMP 5 change control, with impact assessment, documented regression tests, and targeted requalification on the impacted modules. This is typically 30 to 50 percent of the initial qualification effort, not 100 percent.