Search Knowledge Base Articles

Controls Hardware, Software Upgrade & Obsolescence Management

CE-SOP-009 — CONTROLS HARDWARE, SOFTWARE UPGRADE & OBSOLESCENCE MANAGEMENT

Department: Engineering – Electrical Controls & Automation
Document Type: Standard Operating Procedure
Document ID: CE-SOP-009
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Applies To: Controls Engineering, Engineering Management, Maintenance, Operations, IT/OT, Purchasing, Finance/Capital Planning, Contractors, OEMs, and System Integrators as applicable.

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a proactive and repeatable process for identifying, evaluating, prioritizing, budgeting, planning, executing, and documenting upgrades to industrial controls hardware and software.

This SOP is intended to prevent the organization from discovering during a production failure that:

A PLC is obsolete.
An HMI is discontinued.
A replacement I/O module cannot be purchased.
Programming software is no longer available.
Required firmware cannot be obtained.
A communication cable or adapter is unavailable.
An old operating system is required.
A vendor is the only source of the program.
No compatible spare exists.
A failed device requires an unplanned platform migration.

The objective is:

IDENTIFY OBSOLESCENCE BEFORE OBSOLESCENCE BECOMES DOWNTIME.

2. CORE PRINCIPLE

Controls obsolescence shall be treated as a:

RELIABILITY RISK

not merely as a purchasing problem.

A device may continue operating for years after becoming obsolete.

The question is not simply:

"Does it still work?"

The better questions are:

"Can we replace it when it fails?"

"Can we program it?"

"Can we recover it?"

"Can we obtain spare parts?"

"Can another engineer support it?"

"What happens to production if it fails tomorrow?"

3. SCOPE

This SOP applies to:

PLC processors
PLC chassis
PLC power supplies
I/O modules
Remote I/O
HMIs
Industrial PCs
SCADA computers
VFDs
Servo drives
Motion controllers
Safety PLCs
Safety relays
Industrial Ethernet switches
Gateways
Communication modules
Barcode scanners
Vision systems
Sensors
Specialty controllers
Industrial networks
Engineering workstations
Programming software
Firmware
Operating systems
Drivers
Communication utilities
Programming cables/adapters
Licenses
Virtual machines
Vendor/OEM software dependencies

4. DEFINITIONS

OBSOLETE

Equipment or software no longer actively supported or manufactured by the supplier.

DISCONTINUED

Product no longer available through normal production channels.

END OF LIFE — EOL

Manufacturer-defined lifecycle stage indicating support, production, repair, or availability is ending or has ended.

LEGACY

Older technology still in operation but potentially carrying increased support risk.

ACTIVE MATURE

Technology still supported but approaching later lifecycle stages.

CURRENT

Technology actively supported and appropriate for continued use.

UPGRADE

Replacement or modernization intended to improve supportability, reliability, functionality, cybersecurity, or maintainability.

MIGRATION

Transition from one controls platform, architecture, or generation to another.

OBSOLESCENCE RISK

Operational risk created by aging or unsupported controls technology.

5. STANDARD OBSOLESCENCE WORKFLOW

The standard workflow is:

IDENTIFY ASSET

↓

VERIFY CURRENT HARDWARE

↓

VERIFY SOFTWARE / FIRMWARE

↓

CHECK LIFECYCLE

↓

CHECK SPARE AVAILABILITY

↓

CHECK BACKUP / RECOVERY

↓

ASSESS CRITICALITY

↓

ASSESS FAILURE CONSEQUENCE

↓

CALCULATE RISK

↓

IDENTIFY REPLACEMENT

↓

DEFINE MIGRATION PATH

↓

ESTIMATE COST

↓

ESTIMATE DOWNTIME

↓

PRIORITIZE

↓

CREATE UPGRADE OPPORTUNITY

↓

MANAGEMENT REVIEW

↓

BUDGET / APPROVAL

↓

PROJECT EXECUTION

↓

COMMISSION

↓

UPDATE ASSET DATABASE

6. SOURCES OF UPGRADE OPPORTUNITIES

Upgrade opportunities may be identified during:

Troubleshooting
Project discovery
Preventive maintenance
Controls audits
Backup audits
Network audits
Spare-parts reviews
OEM communication
Vendor notification
Manufacturer lifecycle announcement
Failed hardware replacement
Software compatibility issue
Cybersecurity review
Annual capital planning
New project development
Expansion planning
Repeated downtime
Engineering observation

Controls Engineers should document these opportunities when discovered.

Do not depend on memory.

7. UPGRADE OPPORTUNITY REGISTER

Maintain a centralized:

CONTROLS UPGRADE OPPORTUNITY REGISTER

Each identified opportunity should receive a unique ID.

Recommended:

CE-UPG-YYYY-####

Example:

CE-UPG-2026-0012

8. REQUIRED UPGRADE RECORD

Record:

Upgrade ID
Date Identified
Identified By
Facility
Area
Equipment
Asset ID
Existing Manufacturer
Existing Model
Existing Part Number
Existing Firmware
Existing Software
Lifecycle Status
Spare Availability
Backup Status
Production Criticality
Failure Consequence
Recommended Replacement
Estimated Cost
Estimated Downtime
Priority
Target Year
Status

9. HARDWARE IDENTIFICATION

Before recommending replacement, identify the actual installed hardware.

Record:

Manufacturer
Product Family
Catalog Number
Series
Revision
Firmware
Serial Number
Installation Location
Associated Machine
Quantity Installed

Do not build upgrade recommendations from assumptions.

10. SOFTWARE IDENTIFICATION

Determine what software supports the equipment.

Record:

Software Name
Version
License
Operating System
Required Drivers
Communication Software
Installation Media
Compatibility

Example dependencies may include older programming software or operating systems.

11. FIRMWARE IDENTIFICATION

Record current firmware for:

PLC
HMI
VFD
Servo
Safety controller
Communication module
Network switch
Other programmable devices

Firmware may affect replacement compatibility and migration complexity.

12. MANUFACTURER LIFECYCLE STATUS

Classify each asset:

CURRENT

Actively supported.

ACTIVE MATURE

Supported but newer generation exists.

END-OF-LIFE ANNOUNCED

Manufacturer has announced future discontinuation.

DISCONTINUED

No longer manufactured.

OBSOLETE

Normal support substantially unavailable.

UNKNOWN

Lifecycle not yet verified.

Unknown should trigger research rather than assumption.

13. SPARE-PARTS AVAILABILITY

Determine:

Spare currently stocked?
Quantity?
Spare tested?
Spare firmware compatible?
New replacement available?
Refurbished only?
Third-party only?
Lead time?
Cost?
Repair service available?

A spare that has never been tested may not provide the protection expected.

14. SPARE CONDITION

Where applicable record:

AVAILABLE / VERIFIED

AVAILABLE / UNTESTED

AVAILABLE / UNKNOWN CONDITION

NOT AVAILABLE

PROCUREMENT REQUIRED

OBSOLETE / DIFFICULT TO SOURCE

15. BACKUP READINESS

For programmable equipment verify:

Current PLC program
Current HMI source
Drive parameters
Network configuration
Firmware
Software version
Communication method
Restore procedure

Reference:

CE-SOP-006 – PLC/HMI Backup, Version Control & Disaster Recovery

An obsolete system with excellent recovery documentation presents less risk than an obsolete system with no known source files.

16. CRITICALITY CLASSIFICATION

Assign each asset:

CRITICALITY A — CRITICAL

Failure may cause:

Major production loss
Extended downtime
Significant safety/business impact
No practical alternate production route

CRITICALITY B — IMPORTANT

Failure causes significant operational impact but recovery alternatives exist.

CRITICALITY C — STANDARD

Failure has limited operational impact or alternate capability exists.

17. FAILURE CONSEQUENCE

Assess:

PRODUCTION

What stops?

DOWNTIME

How long could recovery take?

SAFETY

Could failure create or affect a safety risk?

QUALITY

Could product quality be affected?

SUPPORT

Can internal engineering support it?

PROCUREMENT

Can replacement hardware be obtained?

RECOVERY

Can the program/configuration be restored?

18. OBSOLESCENCE RISK SCORE

Recommended scoring system:

Score each category from:

1 = LOW RISK

5 = EXTREME RISK

Categories:

Hardware Lifecycle
Spare Availability
Software Availability
Backup / Recovery Readiness
Production Criticality
Failure Consequence
Internal Support Capability
Replacement Lead Time

Maximum:

Unknown/unavailable.

27. RISK CLASSIFICATION

Suggested:

8–14 — LOW

Monitor.

15–21 — MODERATE

Plan improvement.

22–28 — HIGH

Develop upgrade plan.

29–34 — VERY HIGH

Prioritize capital/reliability action.

35–40 — CRITICAL

Immediate management review and risk mitigation.

Risk thresholds may be adjusted as the program matures.

28. RISK SCORE IS NOT THE ONLY DECISION

Engineering judgment remains required.

Example:

An obsolete device may receive a moderate numerical score but support a process with serious safety implications.

Such factors may override the calculated priority.

29. RISK MITIGATION OPTIONS

Not every obsolete asset requires immediate replacement.

Options include:

Purchase spare
Repair existing spare
Verify backup
Create recovery procedure
Preserve programming software
Build legacy VM
Obtain communication cable
Train additional engineer
Upgrade firmware
Replace component
Migrate platform
Redesign system

The goal is risk reduction.

30. REPLACEMENT RESEARCH

For each upgrade determine:

CURRENT DEVICE

Manufacturer
Model
Part Number
Firmware

PROPOSED DEVICE

Manufacturer
Model
Part Number
Firmware

COMPATIBILITY

Electrical
Mechanical
I/O
Communication
Software
Network
HMI
PLC
Safety
Process

31. DROP-IN REPLACEMENT VS. MIGRATION

Classify:

DIRECT REPLACEMENT

Minimal engineering modification.

CONVERSION REPLACEMENT

Requires adapter/conversion hardware.

PARTIAL MIGRATION

Some architecture changes required.

FULL MIGRATION

Platform replacement requiring significant redesign.

This distinction strongly affects cost and downtime.

32. HARDWARE COST ESTIMATE

Itemize:

Item	Manufacturer	Part Number	Qty	Unit Cost	Extended Cost

Include applicable:

PLC
I/O
HMI
Power Supply
Chassis
VFD
Servo
Network Switch
Gateway
Sensors
Relays
Terminal Blocks
Enclosure Hardware
Cables
Connectors
Memory Cards
Programming Adapters
Spares

33. SOFTWARE COST ESTIMATE

Include:

Programming software
Licenses
Support agreements
Runtime licenses
Firmware tools
Vendor utilities
Drivers
Operating system
Virtualization
Engineering workstation requirements

Do not overlook software cost when preparing upgrade proposals.

34. LABOR ESTIMATE

Estimate:

INTERNAL ENGINEERING

Discovery
Design
Programming
HMI development
Documentation
Testing
Commissioning

MAINTENANCE

Electrical installation
Mechanical installation
Wiring
Device replacement

EXTERNAL

Contractor
Integrator
OEM
Vendor support

35. DOWNTIME ESTIMATE

Estimate:

Installation time
Download/configuration
I/O checkout
Commissioning
Production validation
Rollback allowance

Recommended:

Estimated Downtime: 6 hours

Requested Downtime Window: 8 hours

Include contingency proportional to project risk.

36. TOTAL PROJECT COST

Calculate:

Hardware

Software

Internal Labor

Contractor

Vendor/OEM

Shipping

Taxes

Contingency

ESTIMATED PROJECT COST

37. CONTINGENCY

Complex migrations should include appropriate contingency.

Potential unknowns:

Hidden wiring
Firmware compatibility
Communication issues
Mechanical fit
Undocumented logic
Missing source files
Unknown field modifications

Document assumptions rather than presenting uncertain estimates as exact numbers.

38. COST OF DOING NOTHING

Every major upgrade recommendation should answer:

WHAT IS THE RISK IF WE DO NOT UPGRADE?

Examples:

Extended downtime
No spare PLC
Unsupported HMI
Lost program risk
Cybersecurity exposure
No engineering support
Excessive troubleshooting time
Vendor dependency
Quality risk

This helps management compare project cost with business risk.

39. FAILURE COST ESTIMATE

Where practical estimate:

Production Loss per Hour

Estimated Recovery Time

Potential Failure Cost

Example:

$8,000/hour × 12 hours = $96,000 potential production exposure.

Use validated company financial information where available.

Do not invent financial values.

40. UPGRADE BUSINESS CASE

Recommended structure:

CURRENT CONDITION

What exists?

PROBLEM

Why is it a concern?

RISK

What happens if it fails?

RECOMMENDATION

What should replace it?

COST

What will it cost?

DOWNTIME

How long will implementation take?

BENEFIT

What risk or limitation will be reduced?

TARGET

When should it be completed?

41. EXAMPLE UPGRADE OPPORTUNITY

Upgrade ID: CE-UPG-2026-0012

Equipment: Process Water Skid

Existing Controller: Legacy PLC

Condition: Controller and associated I/O have limited replacement availability.

Risk: Failure may cause extended production interruption because replacement hardware and programming support are increasingly difficult to obtain.

Recommendation: Migrate controller and I/O to currently supported platform.

Estimated Hardware: $____

Estimated Software: $____

Estimated Labor: ____ hours

Estimated Downtime: ____ hours

Priority: High

Target: FY2027

42. PRIORITY CLASSIFICATION

U1 — CRITICAL

Immediate reliability exposure.

Examples:

No backup
No spare
Obsolete critical PLC
Known failing hardware
No practical recovery path

U2 — HIGH

Upgrade should be planned soon.

U3 — MEDIUM

Include in future capital/reliability plan.

U4 — LOW / OPPORTUNITY

Modernization beneficial but current risk manageable.

43. UPGRADE PRIORITY VS. SUPPORT TICKET PRIORITY

Do not confuse:

P1–P4 Support Priority

with

U1–U4 Upgrade Priority

A machine may be operating normally today while still having:

U1 Critical Obsolescence Risk

because recovery after failure is unacceptable.

44. MULTI-YEAR ROADMAP

Build a:

3–5 YEAR CONTROLS MODERNIZATION ROADMAP

Example:

YEAR 1

Critical PLC/HMI systems.

YEAR 2

High-risk drives and remote I/O.

YEAR 3

Network modernization.

YEAR 4

Remaining legacy controllers.

YEAR 5

Standardization and optimization.

The roadmap should be reviewed annually.

45. STANDARDIZATION OPPORTUNITY

When replacing equipment ask:

CAN WE REDUCE PLATFORM VARIETY?

Example:

Instead of supporting:

Five PLC families
Four HMI families
Multiple communication protocols
Many software versions

future architecture may standardize around fewer supported platforms.

Benefits:

Reduced spare inventory
Easier training
Easier troubleshooting
Easier backups
Easier vendor support
Lower engineering complexity

46. APPROVED PLATFORM STANDARD

Controls Engineering should eventually maintain:

PREFERRED / APPROVED CONTROLS PLATFORM LIST

Categories may include:

PLC
HMI
VFD
Servo
Managed Switch
Remote I/O
Safety PLC
Sensor families
Power supplies

New projects should use approved platforms unless a documented exception exists.

47. SOFTWARE VERSION STRATEGY

Avoid uncontrolled software-version proliferation.

Track:

Required versions
Equipment using each version
Compatibility
Upgrade path

Example:

If one machine requires a unique legacy version, document why.

48. FIRMWARE STRATEGY

Do not upgrade firmware merely because a newer version exists.

Firmware changes should have:

Reason
Compatibility review
Backup
Rollback consideration
Test plan
Change record

Firmware upgrades are engineering changes.

49. CYBERSECURITY COORDINATION

Controls upgrades may require IT/OT coordination for:

Operating systems
Network architecture
Managed switches
Remote access
Security patches
User accounts
Firewall rules
Unsupported operating systems

Controls Engineering should not independently alter enterprise/plant network security architecture without appropriate coordination.

50. ENGINEERING WORKSTATION OBSOLESCENCE

Include engineering computers in lifecycle planning.

Track:

Laptop/workstation
Operating system
Programming software
Licenses
Communication adapters
VM dependencies
Backup status

The engineering workstation itself is a Controls Engineering asset.

51. SOFTWARE LICENSE RISK

Identify:

Node-locked licenses
Subscription licenses
Expiring support
Lost activation
Vendor-only licensing
Hardware dongles

A program file is of limited value if the organization cannot open it.

52. COMMUNICATION ADAPTER RISK

Legacy equipment may require:

Serial adapters
Proprietary cables
PCMCIA cards
USB converters
Special Ethernet adapters

Document and protect these tools.

53. SPARE STRATEGY

For critical hardware determine:

SHOULD WE UPGRADE NOW?

SHOULD WE BUY A SPARE AND PLAN THE UPGRADE?

A verified spare may reduce immediate risk and provide time for a controlled migration.

54. CRITICAL SPARE REGISTER

Track:

Asset
Part Number
Quantity Required
Quantity Available
Storage Location
Condition
Firmware
Last Tested
Replacement Cost

55. SPARE TESTING

Critical programmable spares should be tested where practical.

Examples:

PLC powers up
HMI boots
Module recognized
Drive healthy
Firmware known

Do not discover during downtime that the "spare" is defective.

56. UPGRADE TRIGGER FROM TROUBLESHOOTING

Under:

CE-SOP-008

a troubleshooting ticket may identify:

Replacement part difficult to obtain.

The ticket should create/link:

UPGRADE OPPORTUNITY

This ensures lessons from breakdowns feed future reliability planning.

57. UPGRADE TRIGGER FROM BACKUP AUDIT

Under:

CE-SOP-006

if a critical controller requires unsupported software or has no recoverable source:

Create:

OBSOLESCENCE / RECOVERY RISK

This may justify upgrade even if hardware currently functions.

58. UPGRADE TRIGGER FROM PROJECT DISCOVERY

During:

CE-SOP-003

an engineer may discover aging hardware while working on an unrelated modification.

Do not unnecessarily expand current scope.

Instead:

Complete current project scope.
Document discovered risk.
Create Upgrade Opportunity.
Evaluate separately.

This prevents uncontrolled scope creep while preserving the finding.

59. PROJECT CONVERSION

Once approved:

Upgrade Opportunity

becomes:

CONTROLS PROJECT

and follows:

CE-SOP-001 – Controls Engineering Project Lifecycle

60. MIGRATION DISCOVERY

Before migration document:

Existing PLC
Existing I/O
Existing HMI
Existing drives
Existing networks
Existing drawings
Existing source code
Existing sequences
Existing alarms
Existing recipes
Existing communications
Existing external dependencies

Migration without proper discovery creates unnecessary risk.

61. I/O MIGRATION PLAN

Create mapping:

Existing Address	Existing Tag	Device	New Address	New Tag	Tested

Use the Controls I/O Mapping standard.

This becomes a critical commissioning document.

62. LOGIC MIGRATION STRATEGY

Determine whether logic will be:

DIRECTLY CONVERTED

Existing logic migrated largely unchanged.

REFACTORED

Logic reorganized while maintaining function.

REDESIGNED

Control strategy substantially rewritten.

Do not confuse a hardware replacement with permission to unnecessarily rewrite a proven machine.

63. HMI MIGRATION

Document:

Existing screens
Navigation
Tags
Alarms
Recipes
Trends
Security
Communication

Determine whether screens will be:

Replicated
Improved
Redesigned

Operator familiarity should be considered.

64. ALARM MIGRATION

Ensure:

Existing alarms identified
Trigger logic understood
Messages preserved/improved
Delays preserved
Reset behavior preserved
Alarm history requirements maintained

Do not accidentally lose alarms during platform migration.

65. NETWORK MIGRATION

Document:

Existing IP addresses
New IP addresses
Protocols
Switch ports
VLANs where applicable
PLC connections
HMI connections
Remote I/O
Drive communication
External systems

Coordinate with IT/OT where required.

66. ROLLBACK PLAN

Every significant migration should answer:

HOW DO WE RETURN TO THE ORIGINAL SYSTEM IF COMMISSIONING FAILS?

Possible requirements:

Original hardware retained
Original PLC program
Original HMI
Original wiring information
Conversion adapters removable
Downtime available for rollback

The more difficult rollback becomes, the stronger pre-installation testing should be.

67. FACTORY ACCEPTANCE TEST — FAT

For major upgrades consider FAT before field installation.

Test:

PLC logic
HMI
Alarm logic
Sequences
Communication
Simulated I/O
Failure modes

FAT reduces field commissioning risk.

68. SITE ACCEPTANCE TEST — SAT

After installation perform SAT.

Verify:

Actual I/O
Actual devices
Production sequence
Alarms
Interlocks
Permissives
Communications
Production operation

Follow:

CE-SOP-007

69. OLD HARDWARE RETENTION

After migration determine whether removed hardware should be:

Retained as emergency spare
Archived
Reused
Disposed
Returned to vendor

Do not automatically discard functioning legacy hardware immediately after migration if it may provide short-term recovery value elsewhere.

Follow company disposal requirements.

70. POST-UPGRADE DOCUMENTATION

Update:

☐ Asset Register

☐ I/O Mapping

☐ Network Register

☐ PLC Backup

☐ HMI Backup

☐ Firmware

☐ Software

☐ Electrical Drawings

☐ Hardware Inventory

☐ Spare Parts

☐ Change Log

☐ Sequence of Operation

☐ Disaster Recovery Record

71. RETIRE OLD SOFTWARE DEPENDENCIES

After successful migration determine whether old:

Software
VM
License
Driver
Programming cable

is still required by other equipment.

Do not remove legacy capability until all dependencies are known.

72. OBSOLESCENCE REVIEW FREQUENCY

Recommended:

ANNUAL CONTROLS OBSOLESCENCE REVIEW

Review critical assets more frequently when risk warrants.

Review:

Lifecycle
Spares
Backups
Software
Firmware
Support
Failure history
Upgrade opportunities

73. CAPITAL PLANNING CYCLE

Before annual capital planning:

Review Upgrade Register.
Recalculate risk.
Update quotes.
Review failures.
Review spares.
Review lead times.
Rank projects.
Prepare business cases.
Present recommended roadmap.

Controls Engineering should arrive at capital planning with evidence—not just a list of equipment it wants replaced.

74. QUOTE AGE

Vendor pricing changes.

Track:

Quote Number
Vendor
Quote Date
Expiration Date
Cost
Shipping
Lead Time

Do not treat old quotes as current project cost.

75. MULTIPLE QUOTES

Where company purchasing policy requires, obtain multiple quotes.

Engineering should ensure compared quotes cover equivalent technical scope.

The cheapest quote is not automatically the lowest-risk solution.

76. ITEMIZED QUOTING SECTION

Your web system should include:

HARDWARE

Manufacturer
Part Number
Description
Quantity
Unit Cost
Extended Cost

SOFTWARE

Software
Version
License Type
Quantity
Cost

SERVICES

Vendor
Description
Hours
Rate
Total

INTERNAL LABOR

Engineering Hours
Maintenance Hours
Other

ADDITIONAL

Shipping
Taxes
Travel
Contingency
Recurring Fees

TOTAL

Estimated Project Cost

77. UPGRADE BUSINESS-CASE SECTION

Include:

WHY NOW?

CURRENT RISK

FAILURE CONSEQUENCE

CURRENT SPARES

CURRENT RECOVERY CAPABILITY

COST

DOWNTIME

BENEFIT

RISK OF DELAY

TARGET COMPLETION

78. WEB SYSTEM — UPGRADE OPPORTUNITY TAB

Recommended sections:

ASSET

Area
Equipment
Asset ID

CURRENT SYSTEM

Manufacturer
Model
Part Number
Firmware
Software

LIFECYCLE

Lifecycle Status
Spare Status
Support Status

RISK

Criticality
Risk Scores
Total Risk
Failure Consequence

RECOMMENDATION

Replacement
Migration Type
Benefits

COST

Hardware
Software
Labor
Contractor
Downtime
Total

PLANNING

Priority
Target Year
Budget Status
Approval

PROJECT

Related Project ID
Status
Completion Date

Display:

TOTAL CONTROLS ASSETS

CURRENT

ACTIVE MATURE

EOL ANNOUNCED

DISCONTINUED

OBSOLETE

UNKNOWN

CRITICAL ASSETS WITHOUT SPARES

ASSETS WITHOUT VERIFIED BACKUPS

LEGACY SOFTWARE DEPENDENCIES

OPEN UPGRADE OPPORTUNITIES

APPROVED UPGRADE PROJECTS

ESTIMATED CAPITAL EXPOSURE

81. RISK HEAT MAP

Recommended:

	Low Consequence	Moderate	High	Critical
Current	Low	Low	Moderate	Moderate
Mature	Low	Moderate	Moderate	High
EOL	Moderate	Moderate	High	High
Obsolete	Moderate	High	Very High	Critical

This provides management with a visual representation of Controls Engineering risk.

82. WEEKLY PROJECT REVIEW INTEGRATION

Do not review the entire Obsolescence Register every Friday.

Instead include:

NEW UPGRADE OPPORTUNITIES

CRITICAL OBSOLESCENCE RISKS

QUOTES NEEDED

MANAGEMENT DECISIONS NEEDED

UPCOMING UPGRADES

This keeps strategic risk visible without overwhelming the weekly meeting.

83. QUARTERLY CONTROLS HEALTH REVIEW

Recommended future practice:

Quarterly review:

Obsolescence
Backup health
Spare coverage
Bad actor equipment
Controls downtime
Network health
Upgrade projects

This creates a higher-level Controls Reliability review separate from day-to-day project meetings.

84. MANAGEMENT REPORTING

When presenting an upgrade, avoid:

"This PLC is old and I want a new one."

Instead:

"This controller is discontinued, supports a critical production process, has no verified spare, requires legacy software, and has an estimated recovery exposure of 12+ hours. The proposed migration reduces that recovery risk and standardizes the platform."

Translate technical risk into business impact.

85. DO NOT UPGRADE JUST BECAUSE IT IS OLD

Age alone is not sufficient justification.

Consider:

Reliability
Supportability
Spare availability
Backup readiness
Production consequence
Cybersecurity
Business needs
Migration complexity

A well-supported legacy system may present less immediate risk than a newer poorly documented system.

86. DO NOT WAIT FOR FAILURE

The opposite mistake is:

"It still works, so leave it alone."

A functioning obsolete PLC with:

No spare
No backup
No software
No support

may represent substantial operational risk.

87. DO NOT CREATE A MIGRATION EMERGENCY

The worst time to design a PLC migration is:

WHILE PRODUCTION IS DOWN BECAUSE THE OLD PLC FAILED.

Plan migrations while the old system still works.

88. STANDARDIZATION TEST

For each upgrade ask:

Does this project move the facility toward a smaller, more supportable set of controls platforms?

Where practical, the answer should trend toward:

YES.

89. RECOVERY TEST

Ask:

If this device fails tomorrow, how long will it realistically take us to recover?

If the answer is:

"We don't know."

the asset deserves further risk assessment.

90. SUPPORTABILITY TEST

Ask:

Could another qualified Controls Engineer support this system using company-owned software, files, documentation, and tools?

If:

supportability risk exists.

91. CAPITAL PRIORITY TEST

Ask:

If we can fund only five controls upgrades this year, which five reduce the greatest combination of production, safety, recovery, and support risk?

This is the purpose of the scoring system and roadmap.

92. QUICK-REFERENCE OBSOLESCENCE WORKFLOW

1. IDENTIFY IT

What hardware/software exists?

2. CLASSIFY IT

Current, mature, EOL, discontinued, obsolete?

3. CHECK SPARES

Can we replace it?

4. CHECK BACKUPS

Can we restore it?

5. CHECK SOFTWARE

Can we program it?

6. SCORE RISK

What happens if it fails?

7. RESEARCH

What replaces it?

8. ESTIMATE

Hardware + software + labor + downtime.

9. PRIORITIZE

U1–U4.

10. PLAN

Assign target year.

11. APPROVE

Build business case.

12. EXECUTE

Follow project lifecycle.

13. COMMISSION

Verify migration.

14. DOCUMENT

Update assets and backups.

15. STANDARDIZE

Reduce future complexity.

93. OBSOLESCENCE GOLDEN RULES

RULE #1

Do not wait for obsolete equipment to fail before planning replacement.

RULE #2

Old does not automatically mean high risk.

RULE #3

Working does not automatically mean low risk.

RULE #4

A spare without a backup may not solve the problem.

RULE #5

A backup without programming software may not solve the problem.

RULE #6

A replacement part without compatibility verification may not solve the problem.

RULE #7

Critical equipment requires a known recovery path.

RULE #8

Troubleshooting discoveries should feed the Upgrade Register.

RULE #9

Every major recommendation should explain the risk of doing nothing.

RULE #10

Use evidence to prioritize capital.

RULE #11

Use upgrades to reduce unnecessary platform diversity.

RULE #12

Maintain company ownership of required source files and recovery information where contractually permitted.

RULE #13

Plan migration while the existing system still operates.

RULE #14

Commission every upgrade as an engineering change.

RULE #15

Update the Asset Register after completion.

94. DEFINITION OF SUCCESS

CE-SOP-009 is successful when Controls Engineering can answer:

Which systems are obsolete?

Which systems are approaching obsolescence?

Which critical systems have no spare?

Which systems have no verified backup?

Which systems require unsupported software?

Which systems depend on one engineer or vendor?

What replacement is recommended?

How much will it cost?

How much downtime is required?

What happens if we delay?

Which upgrades should happen first?

What is the three-to-five-year modernization plan?

The goal is to move the facility from:

REACTIVE OBSOLESCENCE

to:

PLANNED CONTROLS LIFECYCLE MANAGEMENT.

Controls Engineering should know where the next major controls risk is likely to come from before the failure occurs.

95. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-009 – Controls Hardware, Software Upgrade & Obsolescence Management.

Owner: Electrical Controls Engineering

Review Frequency: Annual, during capital planning, and following major lifecycle announcements or significant controls failures.