A supervisory upgrade installs successfully, yet historical trends no longer show the correct equipment context and a recipe restart behaves differently. The software version changed; the operational system changed with it. A legacy automation migration is not automatically a simple like-for-like replacement, even when the supplier describes the new release as compatible.
A defensible migration preserves or deliberately changes intended functionality, records and operational capability through a controlled transition. The work spans PLCs, SCADA, servers, networks, databases, recipes, user access and support arrangements. The migration boundary must reflect their actual dependencies.
Define why the migration is needed
Identify the drivers: unsupported operating systems, unavailable hardware, scarce engineering skills, security exposure, capacity limits or functional changes. Separate urgent risk reduction from desirable improvements. A project combining every requested enhancement with an obsolescence replacement can become difficult to test, schedule and reverse.
Document the current intended use and the target intended use. Identify what remains functionally equivalent, what changes and what is retired. Do not assume that existing documentation reflects the running application. Compare the deployed configuration with controlled records and resolve significant discrepancies before treating it as a migration baseline.
[QRM] Assess the consequences of remaining on the legacy system and of performing the migration. Temporary controls may be needed while preparing the replacement. They should have owners and review conditions, with a credible path to resolution rather than an indefinite statement that the old system is validated.
Inventory dependencies before fixing the scope
Map controllers, I/O, communication modules, operator stations, servers, databases, licences, engineering tools and connected systems. Include supporting identity, time, backup and network services. Record versions and support status sufficiently to evaluate compatibility and recovery.
Identify hidden operational dependencies: local scripts, scheduled reports, manual exports, supplier laptops, recipe files and undocumented database queries. Interview operators and maintenance personnel as well as reviewing drawings. A rarely used maintenance tool may be essential when a controller fails after cutover.
Assess physical interfaces too. Replacing a controller can affect electrical characteristics, I/O mapping, timing and communications with packaged equipment. Virtualizing a server changes infrastructure dependencies even if the application remains the same. The migration plan must cover the complete service, not only the software installation.
Select a transition strategy with explicit tradeoffs
| Approach | Potential advantage | Main question to resolve |
|---|---|---|
| Planned full cutover | Clear transition and fewer long-lived mixed configurations | Can the outage, verification and recovery fit the operational window? |
| Phased migration | Limits the scope changed at one time | Can old and new interfaces coexist without ambiguous ownership? |
| Parallel observation | Allows comparison of selected outputs before transfer of authority | How is duplicate control or conflicting record creation prevented? |
| Retained legacy archive with new operational system | Preserves historical access without converting every record | Can the archive remain secure, readable and supported for retention? |
These options can be combined. Choose through process constraints, risk, data needs and recoverability. “Parallel operation” needs a precise definition; two systems must not issue conflicting commands or create competing authoritative records merely to enable comparison.
Assess PLC and control-logic migration functionally
Automated code conversion can support migration, but successful compilation does not prove equivalent behaviour. Review differences in execution, data types, instruction semantics, communication handling and restart behaviour. Verify I/O mapping and the relationship between commands, feedback and process states.
Prioritize consequential functions and transitions: interlocks, permissives, sequences, recipe execution, hold and restart, communications and retained state. Consider the effect of faster or differently scheduled execution on logic that relied on old timing assumptions. Do not infer process equivalence solely from matching source-code appearance.
[GEP] Use controlled simulation and representative testing where appropriate, followed by verification of the installed interfaces. Retain the original and migrated configuration identities and document intentional changes. The evidence should explain why the new implementation is suitable for the intended process, including any limitations of comparison methods.
Treat SCADA and server upgrades as application changes
Review graphics, scripts, drivers, alarms, trends, calculations, reports and security roles. A platform upgrade can change defaults, supported components or the way a script executes. Check vendor compatibility statements against the actual modules and customizations used by the site.
Server replacement or virtualization requires assessment of storage, networking, resource allocation, time behaviour, backup and recovery. Shared infrastructure can introduce new common dependencies. Confirm that the target environment supports the required availability and performance under expected load and relevant failure conditions.
Verify operator tasks on the delivered interface. A revised screen may preserve all data while changing navigation or command meaning. Train users on consequential changes and confirm that operating procedures match the target system. An upgrade is incomplete if staff continue following instructions for controls that no longer behave the same way.
Plan data migration by record class
Identify which records must be transferred, which can remain in a controlled archive and which are eligible for approved disposal. Define the applicable retention obligations and the relationships needed for interpretation. Historian observations, audit trails, recipes, user history and batch context may require different treatment.
Create a mapping specification for converted data. Include identifiers, units, timestamps, quality indicators, links and version information. Define transformations and rules for exceptions. A row count alone cannot establish correctness when fields are truncated, time zones shift or relationships are lost.
Preserve provenance and the distinction between original and migrated information. Where the target cannot retain an original feature, assess the consequence and a justified alternative. Do not manufacture missing historical metadata or present reconstructed information as if it had been captured contemporaneously.
Verify migration completeness and meaning
Use reconciliation methods suited to the records: counts, checksums where applicable, field comparisons, relationship checks and representative retrieval. Assess both the complete population through automated checks and meaningful cases through inspection or functional reconstruction. Select cases according to risk and known data characteristics.
Include boundary conditions such as old software versions, daylight-saving transitions, corrected records, unusual characters, long values, bad-quality observations and records spanning equipment changes. Investigate discrepancies and retain their disposition. A small unexplained difference may indicate a systematic transformation problem.
Confirm that authorized users can retrieve and interpret the migrated or archived records using supported tools. A database successfully restored in a technical environment is not enough if reviewers cannot locate the relevant batch context or audit history.
Preserve recipe and access governance
Reconcile approved recipes and their versions before transfer. Identify obsolete, draft and active definitions, and prevent accidental activation of an unapproved version. Verify parameter limits, units, procedural structure and links to equipment capabilities in the target system.
Map user roles and permissions deliberately. Do not carry obsolete accounts or excessive privileges into the new environment simply because an import tool permits it. Preserve historical attribution separately from current access rights. A former user's identity may need to remain interpretable in old records without retaining an active account.
Check service accounts, certificates and supplier access alongside human users. Confirm ownership and lifecycle arrangements in the new architecture. The OT cybersecurity article covers the related access, exposure and recovery decisions.
Engineer cutover as a controlled sequence
Define prerequisites, responsible roles, steps, verification points and communication. Establish the process state required before cutover and how pending transactions or active batches are handled. Freeze the appropriate configuration and data population so that reconciliation has a known boundary.
Plan the transfer of authority explicitly. Identify when the old system stops issuing commands or accepting records and when the new system begins. Prevent stale queues, cached commands or scheduled jobs from replaying after reconnection. Confirm the state of interfaces on both sides of the boundary.
Use go/no-go criteria that can be assessed within the operational window. Include essential function checks, data reconciliation and support readiness. Reserve adequate time for a justified recovery decision; a rollback plan is not credible if the team reaches its decision point after the remaining window has already disappeared.
Define rollback and its practical limits
Rollback may involve more than reinstalling old software. After the new system has created records or changed process state, returning to the old system can require data reconciliation and compatibility assessment. Define the point beyond which simple reversal is no longer feasible and what recovery strategy then applies.
Protect the legacy baseline, installation media, configuration and recovery dependencies. Demonstrate the restoration path in a suitable environment where feasible. Record expected limitations and the time and expertise required. A backup file that has never been restored is an assumption, not a proven fallback.
[GUIDEGXP RECOMMENDATION] Review rollback with production, automation, IT and quality together. The question is whether the site can return to an acceptable controlled state with understandable records, not merely whether a server can boot the previous image.
Worked example: historian replacement during a planned shutdown
An illustrative site replaces an unsupported historian while retaining local process control. Historical records must remain available, and the new historian must collect current data with approved settings. The team chooses a controlled archive for part of the legacy population and a verified conversion for selected records requiring integrated retrieval.
Before shutdown, it inventories tags, units, quality codes, time conventions and batch associations. Trial migration reveals that a subset of old tags changed equipment meaning over time. The team preserves that configuration history and adjusts retrieval context instead of treating each identifier as one unchanging physical measurement.
Cutover stops old acquisition at a defined boundary, transfers current collection and reconciles the transition interval. Acceptance verifies known process events, delayed data, quality flags and historical retrieval. The old environment remains governed according to the archive and recovery plan; it is not left as an unmanaged workstation simply because it contains useful history.
Build acceptance around the changed boundary
Separate tests that establish target-system functionality from comparisons that establish acceptable continuity with the legacy system. The new system may intentionally improve behaviour, so exact equality is not always the correct criterion. Document intentional differences and their approval; investigate unexplained differences rather than automatically classifying them as improvements.
Use representative process scenarios that cross the migrated boundary. A new controller should be evaluated with its actual supervisory and equipment interfaces. A new server should be evaluated with identity, time, storage and recovery services. A migrated report should be checked against known source records and the approved calculation rules.
Include a rehearsal of the cutover sequence where the risk warrants it. Measure what the rehearsal can establish and identify conditions that cannot be reproduced. Use findings to refine timing, responsibilities and fallback criteria. Do not treat a successful laboratory rehearsal as proof that every site dependency has been covered.
Transfer knowledge to the operating organization
Update drawings, configuration inventories, recovery instructions and maintenance procedures to the delivered state. Provide the engineering environment, access and licences needed for authorized support. Confirm that site personnel can perform representative diagnosis and recovery tasks without relying solely on the migration contractor.
Explain changed behaviour to operators and reviewers, including revised navigation, alarms, record retrieval and historical limitations. Training should use the released configuration or a controlled equivalent. Record outstanding support dependencies and their owners before the project team demobilizes. This handover is part of readiness because an unsupported new system can reproduce the operational fragility that motivated the migration.
Release, monitor and retire deliberately
[REGULATORY REQUIREMENT] Apply relevant GMP change control, computerized-system and qualification requirements to the assessed change. Determine requalification and verification scope from impact and risk. A supplier's “like-for-like” description does not remove the site's responsibility to evaluate altered functions, dependencies and records.
After release, monitor the functions and interfaces most affected by the migration. Define support coverage, issue escalation and closure of temporary controls. Retire obsolete accounts, remote routes, licences and hardware according to the plan while preserving required records and recovery capabilities.
Connect the project with risk-based assurance, Cleanrooms & HVAC Systems for relevant building-control migrations, and the Automation & Digital Systems hub.
Primary references and status
Reviewed 23 September 2026: EudraLex Volume 4, Annex 11, Chapter 4 and Annex 15; ICH Q9(R1); ICH Q10; NIST SP 800-82 Revision 3. Operative EU Annex 11 and Chapter 4 remained the 2011 texts; revision proposals were not current replacements. Migration strategies, comparison questions and the example are original GuideGxP engineering recommendations, to be adapted to the actual system.
