The only technician is often responsible for equipment whose manufacturer no longer supports the control system. Obsolescence should be treated as a planned risk, not a surprise.
Identify the genuine single points of failure
Old does not automatically mean critical. The risk is highest when a unique obsolete component has no spare, no backup, and no replacement path.
The fastest way to make this useful is to attach it to the work itself: Create an obsolescence register for controllers, HMIs, drives, special electronics, and proprietary mechanisms.
An old PLC with three tested spare CPUs may be less urgent than a ten-year-old HMI whose project file is missing.
A strong approach to identify the genuine single points of failure also makes absence easier. Ask whether a contractor could follow the information without calling you for the missing context. If the answer is no, improve the note, drawing, label, spare reference, or contact information before the next emergency.
Test spares before trusting them
A dusty component on a shelf is not a proven recovery plan.
Treat this as part of the repair, not as optional paperwork afterward: Where safe and practical, verify spare condition, firmware compatibility, stored program, batteries, and required accessories.
A spare drive that powers up but lacks the correct option card may not restore the machine.
When management asks why test spares before trusting them matters, translate it into an operational outcome: fewer minutes of downtime, lower chance of secondary damage, safer isolation, faster contractor response, fewer callouts, or less obsolete-stock risk. Technical work wins support when its business consequence is visible.
Develop a migration trigger
Waiting for catastrophic failure forces rushed modernization.
For a lone technician, the practical consequence is this: Define when replacement becomes justified: spare count reaches zero, support ends, downtime exceeds threshold, or backups cannot be restored.
A planned controller migration during shutdown is expensive; an emergency migration during peak production is usually more expensive.
Be careful about false completion with develop a migration trigger. Production running again does not always mean the maintenance job is complete. Check whether a temporary condition remains, a part must be ordered, a program backup changed, a guard was removed, or a root cause still needs confirmation.
Practical application
Take one recent maintenance event that relates to obsolete equipment and unsupported machines. Reconstruct what you knew at the beginning, before resets, part changes, or production explanations influenced the diagnosis. Then review the event through three lenses from this chapter: identify the genuine single points of failure, test spares before trusting them, and develop a migration trigger. Write down where your real response matched the method and where it depended on memory, urgency, or luck.
Use the examples as prompts rather than scripts. For identify the genuine single points of failure, the chapter showed: An old PLC with three tested spare CPUs may be less urgent than a ten-year-old HMI whose project file is missing. For test spares before trusting them, it showed: A spare drive that powers up but lacks the correct option card may not restore the machine. Decide on one practical change you can make before the same type of event returns – a measurement point, spare, label, note, backup, callout rule, PM task, or escalation contact.
Chapter action checklist
☐ Identify one current weakness related to obsolete
equipment and unsupported machines.
☐ Choose one change that can be implemented without new
software or budget.
☐ Decide what evidence should be recorded the next time this
situation occurs.
☐ Identify the point where you would stop and escalate rather
than continue alone.
☐ Add any resulting repair, documentation, spare, training, or
management action to the visible backlog.