Most programmable logic control systems do not fail without warning. They deteriorate - through component ageing, accumulating undocumented code changes, and shrinking parts availability - until a fault that should have been manageable becomes a multi-day production stoppage.
The maintenance managers who avoid that outcome are not necessarily running newer systems. They are running assessed systems - facilities where someone has methodically evaluated each PLC against a defined fitness framework and made deliberate decisions about what to retain, upgrade, or replace.
This article provides that framework. It covers the five indicators of end-of-useful-life, how to audit code integrity, how to build an obsolescence replacement schedule, and how to frame the migration versus replacement decision in terms your operations director can act on.
The Five Indicators Your Programmable Logic Control System Is Approaching End of Useful Life
Each of the five indicators below represents a distinct failure pathway. None of them is theoretical. Together, they form a practical checklist for any initial assessment of PLC fitness.
- Hardware age. PLCs on Siemens S5, Allen-Bradley SLC 500, or first-generation RDM controllers are operating on hardware that manufacturers have moved well beyond in terms of active support. Capacitors degrade, backplane connectors oxidise, and internal clocks drift - none of which is visible until the fault appears mid-shift.
- Parts availability. When a processor card or I/O module can only be sourced through secondary markets, your recovery time after a hardware fault is no longer predictable. Emergency procurement for obsolete components routinely extends unplanned downtime from hours to days.
- Software compatibility. If the programming environment required to read or modify your PLC code is no longer supported on current Windows versions, or requires legacy hardware keys that are no longer available, your ability to respond to a code fault under operational pressure is severely compromised.
- Undocumented code. Code that exists without version history, variable naming conventions, or fault logic commentary cannot be safely modified by anyone other than the original author - who, in many facilities, left years ago. This is not a documentation shortcoming. It is an operational risk.
- Recurring faults. A PLC that generates regular fault logs - nuisance trips, intermittent I/O errors, unexplained programme halts - is signalling systemic deterioration. Resetting and monitoring is not a maintenance strategy. It is deferred risk.
The Cost of Deferred Assessment
A single unplanned stoppage caused by an obsolete PLC component typically involves emergency contractor call-out, secondary market component sourcing, unplanned overtime, and lost production - all of which individually exceed the cost of a structured assessment and planned replacement programme.
The critical question is not whether any of these indicators is present - in most facilities over ten years old, at least two or three will apply. The question is whether they have been mapped, quantified, and assigned a priority, or whether they remain unacknowledged background risk.
How to Audit PLC Code Integrity: What Good Documentation Looks Like and What Should Concern You
Code quality is the aspect of PLC fitness assessment that maintenance teams most commonly defer - partly because it requires specialist skills to evaluate, and partly because the consequences of poor code are not immediately visible. A machine that runs badly-structured code will, under normal conditions, run without incident. The risk materialises the moment someone needs to modify it.
What Well-Structured PLC Code Looks Like
- Descriptive variable names that map directly to physical I/O - not abbreviations meaningful only to the original programmer
- Version control history showing who changed what, when, and why
- Fault logic that is fully commented, explaining the intended response to each identified failure condition
- Structured programme organisation - function blocks separated by process area, with clear inter-block references
- A current as-built document that matches the installed code, not the original project version
Red Flags That Signal Structural Code Risk
- Variable names like M1.2, T4, or DB7 with no associated tag description or reference document
- Absent or minimal comments - particularly in fault and interlock logic, where intent is most critical
- No version history, or version history limited to a single revision note from installation
- Code written by contractors who have since left, with no handover documentation or programme notes
- Commented-out rungs with no explanation of why they were disabled or whether they should be restored
- Missing or incomplete safety interlock documentation
The Handover Problem
Code written by a departed contractor without handover documentation is effectively a black box. The facility owns the hardware and the programme file, but has no defensible ability to modify, verify, or safely commission a replacement system from that code alone. This situation is more common than most maintenance managers realise - and it is not recoverable without a structured code audit.
A code audit should produce a written assessment of each of these dimensions - not a general opinion. If an assessment concludes that code is 'generally adequate', it has not been carried out to a useful standard. The output must identify specific risks, specific gaps, and specific remediation actions.
Obsolescence Planning: How to Build a Replacement Schedule Before Failure Forces Your Hand
The instinctive response to obsolescence is to defer the decision until the component actually fails. This approach has a logic to it - capital expenditure is avoided, and the system continues to run. The problem is that it transfers the timing of the decision from your planning cycle to an unplanned fault event, at which point your options narrow significantly.
A structured obsolescence plan starts with mapping every PLC component against three criteria: current manufacturer support status, secondary market availability, and lead time for replacement under emergency conditions. The combination of these three data points produces a risk rating for each component - which directly informs the replacement schedule.
The Single Points of Failure Problem
In most facilities, there are components whose failure would halt a process with no alternative path. These are single points of failure - and they are the first priority in any obsolescence plan, regardless of age or fault history. A component that is two years old but has a twelve-week lead time and no secondary market availability represents a higher business risk than an older component with readily available spares.
JBB Electrical's obsolescence planning process maps these single points of failure against manufacturer end-of-life timelines, then schedules proactive replacement during planned maintenance windows. The comparison to emergency procurement is not theoretical: when a critical PLC module fails without a replacement in stock, the response involves secondary market sourcing at significant premium, with delivery windows that are not guaranteed.
Connect Obsolescence Planning to Your Critical Spares Strategy
Obsolescence planning and critical spares management address the same risk from different angles. The obsolescence schedule tells you what needs to be replaced; the spares strategy ensures the right components are on-site until replacement is complete. Both should be outputs of the same assessment - not separate workstreams managed by different teams. JBB's Critical Spares service at jbbelec.co.uk/services/critical-spares addresses exactly this integration.
An obsolescence plan is not a one-time document. It requires annual review as manufacturer support timelines change and as new components are introduced through other projects. The most effective plans are maintained as live documents, updated each time an assessment or maintenance programme identifies a change in component status.
Migration, Reprogramming, or Full Replacement: Understanding the Business Case for Each Approach
When assessment confirms that a programmable logic control system requires intervention, the decision is not simply 'replace it'. Three distinct options exist - each with a different risk profile, capital requirement, and operational disruption footprint.
Migration, Reprogramming, or Full Replacement: The Three Options
Migration
The existing control logic is ported to a current-generation platform - for example, moving from a Siemens S5 to an S7-1500 or from an Allen-Bradley SLC 500 to a CompactLogix - while retaining the process logic structure. Migration is the right choice where the original programme was well-structured, the process it controls has not changed significantly, and the primary driver is hardware obsolescence rather than functional improvement. Capital cost is lower than full replacement, but the output is only as good as the original code - poor structure migrates alongside functional logic.
Reprogramming
The control system is rebuilt from the process requirements up, using current structured programming practice on a target platform. Reprogramming is appropriate where the original code is poorly documented, where the process has evolved beyond the original programme's scope, or where fault detection and alarm management need to be fundamentally improved. The capital and engineering investment is higher than migration, but the output is a maintainable, documented programme that any competent control systems engineer can modify safely in future.
Full Replacement
The control system - hardware, software, and supporting infrastructure - is replaced in its entirety, often as part of a wider automation upgrade. Full replacement is appropriate where the existing panel is beyond economic repair, where the process it controls is being redesigned, or where integration with new equipment or SCADA architecture requires a clean hardware and software foundation. This option carries the highest capital investment but eliminates accumulated technical debt and delivers a system with a defined, known lifecycle from day one. JBB's in-house manufacturing capability means design, build, test, and document phases remain under a single team - the same team: design, build, test, document - eliminating the accountability gaps that arise when design, manufacture, and installation are divided between different contractors.
Business Case Framing
The decision between these three options should not be made on technical criteria alone. It should be framed around three business variables: the cost of an unplanned stoppage on the current system (including downtime, emergency procurement, and recovery time), the capital and disruption cost of each option, and the expected lifecycle of the resulting system. Expressed in those terms, the conversation with finance or an operations director becomes one about risk and return - not technical preference.
Platform Considerations
Platform selection - whether Siemens, Allen-Bradley, or RDM - should be driven by your existing site standards, your engineering team's competency, and the long-term support commitments of the manufacturer for the target platform. JBB Electrical programmes across all three, and the assessment process includes platform-specific lifecycle analysis so the recommended migration target has a defensible support horizon.
What a Professional Control Systems Assessment Should Cover and What the Output Must Include
A credible control systems assessment is not a site visit followed by a general observation report. It is a structured technical audit with defined outputs that your maintenance team and operations director can act on directly.
What the Assessment Must Cover
- Hardware condition and component lifecycle status - physical inspection of processor modules, I/O cards, power supplies, and backplanes, cross-referenced against manufacturer support timelines and published end-of-life dates for every identified component
- Code integrity review - structured evaluation of programme documentation, variable naming, version history, fault logic coverage, and interlock integrity
- Single points of failure mapping - identification of components whose failure would halt production with no recovery path short of emergency procurement, and software environment review confirming the programming environment is available, licensed, and functional on current hardware
- BS EN 60204-1 and relevant safety standards compliance check - confirming that protection schemes and safety interlocks are correctly implemented and documented
What the Output Must Include
- A prioritised risk register - each identified risk rated by likelihood, consequence, and urgency, not grouped into generic categories
- A phased upgrade roadmap with defined timelines - sequenced by risk priority and aligned to your maintenance windows, not a theoretical schedule
- Critical spares recommendations tied to specific failure points, with sourcing options and lead time data, alongside a summary business case for the recommended intervention approach framed in operational and financial terms suitable for internal budget approval
Illustrative Scenario: What a Typical Assessment Reveals
Consider a food processing facility running a Siemens S7-300 PLC managing a primary production line, installed approximately fifteen years ago by a contractor who has since ceased trading. An assessment of this system would typically identify: a processor card approaching the end of manufacturer active support; no version control history on the programme file; fault logic present but uncommented, with several rungs disabled with no documented rationale; and a single I/O module controlling temperature interlocks with no on-site spare and a documented lead time exceeding four weeks. The engineering response would be to classify the disabled rungs for immediate investigation, schedule the I/O module as a priority critical spare, initiate a reprogramming project to rebuild fault logic with full documentation, and map the processor card for planned migration within the next capital cycle. Without the assessment, all four of these risks remain unknown and unmanaged.Illustrative example based on representative JBB project work.
JBB Electrical's Compliance & Breakdown Prevention Assessment covers these dimensions as a structured programme. For facilities with specific control system concerns, the Free Control Systems Assessment at jbbelec.co.uk/free-assessment provides an initial evaluation to identify priority risks before committing to a full programme of work.
The JBB Programmable Logic Control Systems Methodology
The JBB Programmable Logic Control Systems Methodology
Assess
JBB Electrical conducts a structured audit of every PLC component on site - processor modules, I/O cards, power supplies, and programming environments - rating each against manufacturer lifecycle status, physical condition, and code integrity. As a NICEIC-approved contractor with experience across Siemens, Allen-Bradley, and RDM platforms, this stage produces a complete risk register with no gaps.
Modernise
Where assessment identifies migration, reprogramming, or full replacement as the required intervention, JBB engineers design the target architecture using EPLAN Electric P8 and rebuild control logic to current structured programming standards - with full variable naming, version control, fault logic commentary, and interlock documentation included as deliverables, not afterthoughts.
Protect
Single points of failure identified during the assessment are addressed through a combination of on-site critical spares procurement, redundancy engineering where the process supports it, and BS EN 60204-1 interlock verification - so that the modernised system has protection against the failure modes the legacy system left unaddressed.
Prevent
JBB establishes a preventive maintenance schedule for the modernised PLC system, including periodic code backup verification, I/O channel testing, power supply condition checks, and programme version audits - integrated with wider site maintenance programmes through JBB's Preventive Electrical Maintenance service at jbbelec.co.uk/services/maintenance.
Support
Founded 1966, JBB Electrical provides ongoing engineering support across the full PLC lifecycle - from post-commissioning programme modifications and operator training, through obsolescence monitoring as component support timelines evolve, to rapid response when fault conditions arise. The same team that designed and built the system supports it, so institutional knowledge of the control logic is never lost.
Running Your Own Internal Assessment: A Practical Starting Framework for Maintenance Teams
Most maintenance teams do not have dedicated control systems engineers. That should not prevent an initial internal assessment - but it does define the scope. An internal assessment is a risk-identification exercise, not a technical audit. Its purpose is to generate enough information to make a prioritised case for professional assessment where the risk is highest.
Internal PLC Fitness Assessment - Starting Checklist
- Record the manufacturer, model, and installation year of every PLC processor on site, and check manufacturer websites for active support status and published end-of-life dates for each
- Confirm that the programming software required to open each programme file is available, licensed, and accessible on a current machine, and locate the most recent programme backup with the date it was taken
- Review the last twelve months of fault logs for each system - note recurring trips, unexplained halts, and I/O errors
- Identify which PLCs control processes where failure would halt production with no manual override or alternative path, and confirm whether any programme was written by a contractor no longer accessible for support queries
- Check whether critical I/O modules or processor cards have on-site spares - and if so, confirm when those spares were last verified as compatible and functional
This checklist will not tell you whether your code is structurally sound or whether your protection scheme is correctly implemented. But it will reliably identify which systems warrant professional assessment first - and it creates the documented evidence needed to support an internal case for investment.
Where Internal Assessment Reaches Its Limits
Code integrity, interlock verification, and safety function testing require engineering competency that goes beyond what most maintenance teams can self-assess. Where any of the checklist items above returns a concern - particularly on systems controlling safety-critical processes - a professional assessment is not optional. The consequences of an undiscovered fault in a safety interlock are not recoverable through better internal processes.
The internal assessment is the starting point. Its value is in creating structured visibility where previously there was assumption. Where it identifies risk, the next step is professional assessment - not continued monitoring. Connect findings from this exercise to your wider preventive maintenance programme and, where control panels are involved, to a review of your Control Panels & MCC Design provisions at jbbelec.co.uk/services/control-panels.
Facilities running refrigeration processes should also note that PLC fitness directly affects temperature monitoring reliability - a risk area covered separately through JBB's Refrigeration Control Systems service at jbbelec.co.uk/services/refrigeration-control.
Next Step: Request a Compliance & Breakdown Prevention Assessment
Next Step: Request a Compliance & Breakdown Prevention Assessment
A Compliance & Breakdown Prevention Assessment identifies the electrical, compliance, and breakdown risks affecting your operation, and sets out the engineering actions needed to reduce downtime, protect reliability, and keep your infrastructure defensibly compliant. Request a Compliance & Breakdown Prevention Assessment today to establish which of your programmable logic control systems carry unacknowledged obsolescence, code, or single-point-of-failure risk - before a fault event forces the decision under operational pressure.
Compliance & Breakdown Prevention Assessment
