Your controller is going end-of-life: choosing the path and bounding the requalification

The maintenance planner opens the stores record for the granulation line and finds one spare processor module left. The other was fitted after a fault and never reordered. The supplier’s answer to the purchase request is polite and short: the part was withdrawn from sale, repairs stop at the end of the year, and the notice went out long ago, to a mailbox that belonged to an engineer who has since left.

Down the corridor, the two operator stations of the same line run an operating system whose security updates have also stopped. The last periodic review of the system, signed a few months before, concluded that the validated state was maintained. Nobody had asked it to look at the calendar.

On the sites we assess, this is how obsolescence usually arrives: as a surprise, although every date involved was published years in advance. Handled late, it becomes an emergency change with an open-ended requalification. Handled early, it is a planned change in which the site chooses its path and argues the size of the qualification work before anyone touches a cabinet.

The dates are published long before they bite

Control-system vendors move their products through recognisable phases, under names that differ from one catalogue to the next: actively sold, mature or in phase-out, withdrawn from sale, and finally out of support, when repairs, spare parts and firmware fixes stop. Each transition is announced with a notice and, usually, a successor. What most sites lack is someone whose job is to read those notices.

Operator stations and servers follow a calendar that is even easier to read. Microsoft’s Fixed Lifecycle Policy gives its products at least five years of mainstream support, followed for some by extended support with security updates only. Microsoft has set the end of support for Windows 10 Enterprise and Education at 14 October 2025. The Long-Term Servicing Channel (LTSC) edition Windows 10 IoT Enterprise LTSC 2021, common on industrial computers, has extended support until January 2032. Windows 7 left extended support in January 2020.

On a typical supervisory control and data acquisition (SCADA) or human-machine interface (HMI) installation, the computer therefore goes out of support well before the programmable logic controller (PLC) behind it. The two clocks run separately, and both belong in the same plan.

A standard exists for this, and it is written for buyers

IEC 62402:2019, Obsolescence management, second edition, published by the International Electrotechnical Commission (IEC) on 29 May 2019, applies to any organisation that depends on another organisation to obtain value from the items it provides. A pharmaceutical plant that depends on its automation vendors fits that description exactly. Its first edition, from 2007, was a guide; the 2019 edition is written as requirements.

Its published scope runs from a policy and an obsolescence management plan to design strategies, the choice of a resolution and the measurement of results. Read by a site engineer, that is a short list of questions. Who owns the watch? Where is the plan written? Which projects were asked to design for it? How do we know it works?

Few sites working to good manufacturing practice (GMP) need a separate obsolescence procedure to answer them. A few lines added to the system inventory, the periodic review and the change control are enough.

Make the periodic review read the calendar

EU GMP Annex 11 (2011) already asks for the ingredients. Its §4.3 wants an up-to-date inventory of systems and, for critical ones, a system description that includes the hardware and software pre-requisites. Its §11 says computerised systems should be periodically evaluated to confirm that they remain in a valid state, and names among the items to review the upgrade history, performance, reliability and security. Annex 15 (2015) §4.1 asks for equipment and systems to be evaluated at an appropriate frequency to confirm they remain in a state of control.

A system running on hardware the vendor no longer repairs, under an operating system that receives no security fixes, is hard to call reliable and secure for the years ahead, even if it ran perfectly during the review period. The Pharmaceutical Inspection Co-operation Scheme (PIC/S) guide PI 011-3 makes the link explicitly: hardware and software updates are among the triggers of a change or a review for change (§18.3), and the results of periodic reviews may indicate the need for change (§18.4).

In practice, three lines in the periodic review template do most of the work:

• Lifecycle status. For each controller family, operator station, server and operating system: the vendor’s phase and the date of the next transition, or “unknown” written as a finding.
• Spares against consumption. How many spares are in stock, how many were used over the review period, and whether their firmware matches what is installed.
• Nearest deadline and decision. The first end-of-support date affecting the system, and the path chosen for it, with a change request number once one exists.

Four paths, and what each costs in qualification

Once a date is known, the options come down to four. They are not exclusive: most sites combine two of them, buying time with the first while preparing the third.

• Last-time buy. Spares are bought before the part leaves the catalogue, sized on failure history and the years still needed. It buys time and changes nothing on the line, provided the spares carry the same hardware revision and firmware as the installed modules, or the difference is assessed before the first one is fitted.
• Extend and shield. The system stays as it is, beyond support, with compensating measures: its own network zone, strict access, offline images and tested restores, a spares pool. The article on shielding legacy PLCs with compensating controls describes the security side. The quality side is a documented risk acceptance with a review date, not an open-ended one.
• Phased migration. The system is replaced in steps: operator stations first, then controllers area by area, often keeping the field wiring and input/output (I/O) modules. Each step is a smaller change. The interim, mixed architecture is a configuration in its own right and has to be qualified as such.
• Full replacement. One project, one long shutdown, one validation package. The cleanest end state, the highest schedule risk, and the largest requalification, sometimes including renewed process performance evidence.

Two vendor-written trade features look at the choice from the supply side. A sponsored feature in Automation.com Monthly (August/September 2025) argues for landing field wiring on a stable carrier board, so that only the compute module is swapped when it becomes obsolete. An InTech feature (April 2023) calls the like-for-like option “replacement in kind”, the lowest-risk route at the price of forgoing what a newer system offers. Neither settles what a GMP site must prove after the change.

Like-for-like or functionally equivalent: the argument that bounds the scope

The sponsored feature states that keeping the wiring and the I/O layer preserves prior validation. On a GMP site, it does not, at least not by itself. The validated state is a conclusion of the change assessment, never a property of the hardware. Annex 15 §11.4 asks for quality risk management to evaluate a planned change and plan “any necessary process validation, verification or requalification efforts”. What keeping the wiring buys is a smaller, easier argument.

That argument rests on a short comparison between the old item and the new one, made before the change is approved:

1. Identity. Same part number, hardware revision and firmware? Then it is a repair: a maintenance record and a functional check, under the site’s maintenance procedure.
2. Form, fit and function. Different model, same application code, same I/O map? Then the comparison lists what can differ: scan time, instruction behaviour in the new firmware, communication drivers, diagnostics, time synchronisation. Each difference that can touch a GMP function gets a targeted test.
3. Conversion. Code translated or rewritten for a new platform? Then it is a new computerised system with a converted specification, tested as such, and the old one is retired under its own plan.

The evidence for the second case is ordinary engineering: the vendor’s compatibility statement (verified, not quoted), a comparison of the program before and after with its checksums, the unchanged I/O list, and a regression test of the functions the risk assessment names. The logic of what each qualification stage proves applies: installation qualification (IQ) for what was installed, operational qualification (OQ) for the functions that could have changed, performance qualification (PQ) only when the process itself could behave differently.

On a migration, factory acceptance testing (FAT) and site acceptance testing (SAT) are where most conversion errors surface, and the supplier’s tests can count in qualification when this is planned, as described in reusing FAT and SAT as supplier evidence.

The old system has to be retired properly

Migration projects often forget that the old system leaves something behind: batch reports, alarm and event logs, audit trails, recipes, trend data. Annex 11 §17 says that if relevant changes are made to the system, the ability to retrieve archived data should be ensured and tested. Its §4.8 asks for checks that data moved to another format or system is not altered in value or meaning. ISPE’s GAMP 5 Second Edition (2022) gives retirement its own lifecycle phase, a section on system replacement and retirement, and Appendix M10, System Retirement.

A migration is also the moment when an old system with thin validation evidence becomes visible. PI 011-3 §16.4 is clear that historical data do not support validation if the range of operating parameters or the practices have changed significantly. A converted application cannot inherit its validation from twenty years of uneventful running on another platform. It is validated on its own specification, and the history is useful as input to that specification.

A practical point: take a verified image of the old system before it is switched off, and test that it restores. If a question arises later about a batch produced on it, the image may be the only way to answer. The method is the one in testing a backup by restoring it.

Where to start

1. Put a date on every line of the inventory. For each controller family, operator station and server operating system, record the vendor’s phase and the next transition date. Done when every line shows a date or the word “unknown”, and each unknown has a name next to it.
2. Run the three lifecycle lines at the next periodic review of the most critical line. Spares, firmware match and nearest deadline. Done when the review report states a chosen path and, where needed, a change request number.
3. Write the identity and form-fit-function criteria into the change procedure. Agree in advance with quality what counts as a repair, a like-for-like replacement and a new system. Done when the next obsolete part is classified in a day, not argued for a month.

Five common mistakes

• Treating the stores spare as identical. A module bought years ago may carry older firmware than the installed one. Fitting it is a change.
• Shielding without an end date. A risk acceptance for an unsupported system needs a review date and a trigger for migration; otherwise it becomes permanent by default.
• Leaving the operator stations out of the plan. Their operating system usually goes out of support first, and it is the part most exposed to the network.
• Assuming validation follows the wiring. Keeping the I/O narrows the scope. Only the change assessment can say how far.
• Switching off the old system before its data is safe. Archive, test the retrieval, take a restorable image, then retire it under a written plan.

An end-of-support date is the one change on a validated plant that announces itself years ahead. The sites that read it choose their path; the others discover it in the stores.

References

• IEC, IEC 62402:2019, Obsolescence management, edition 2.0, 29 May 2019: webstore.iec.ch.
• European Commission, EudraLex Volume 4, Annex 11: Computerised Systems (2011), §4.3, §4.8, §11 and §17: health.ec.europa.eu.
• European Commission, EudraLex Volume 4, Annex 15: Qualification and Validation (2015), §4.1 and §11: health.ec.europa.eu.
• PIC/S, PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments, 25 September 2007, §16 and §18: picscheme.org.
• ISPE, GAMP 5 Guide, Second Edition (2022), table of contents (4.4 Retirement, 7.14 System Replacement and Retirement, Appendix M10): ems.ispe.org.
• Microsoft, Fixed Lifecycle Policy: learn.microsoft.com; lifecycle pages for Windows 10 Enterprise and Education, Windows 10 IoT Enterprise LTSC 2021 and Windows 7.
• Lifecycle and Obsolescence Management: Extending Control System Lifespans, sponsored feature, Automation.com Monthly, August/September 2025: automation.com (one of the features this article starts from).
• Modern Tools Create Modern Systems, InTech, April 2023: isa.org.