Machine Design #50: Retrofitting an Old Machine — Managing Boundaries, Interfaces, and Change Risk
Retrofit is often described as a catalog exercise: choose a new controller, a drive, or an HMI, then make the old machine run again. The difficult part is not selecting the new product. It is understanding the old system well enough to change it without losing hidden functions, safety margins, data, or recovery knowledge.
An old machine may contain undocumented wiring, online edits, tuned parameters, worn mechanisms, obsolete software, and interfaces that work only because an experienced operator knows the sequence. A retrofit must answer:
What is the as-is machine, what is inside the change boundary, what can interact with the new design, and what evidence proves the modified machine is safe and fit for use?
1. Do not start with the catalog
Start with function, boundary, risk, and evidence. A new controller that matches the I/O count can still fail because of scan timing, analog scaling, motion profiles, safety architecture, retained data, network behavior, or a mechanical condition that the old controller tolerated.
Create a discovery plan before choosing a platform. Identify people who know the machine, available records, operating modes, failure history, constraints, and the recovery goal.
2. As-is discovery: old records are hypotheses
Collect drawings, PLC projects, HMI backups, drive parameters, robot programs, recipes, calibration, network maps, manuals, alarm lists, safety documents, maintenance notes, and photos. Treat each as a source with a version and confidence, not as unquestioned truth.
Compare records with the running asset. Inspect panels, I/O, connectors, grounding, guards, devices, labels, firmware, parameters, and actual sequence. Record unknowns instead of filling gaps from memory.
3. Write change intent before the solution
State why the retrofit exists: obsolete controller, unavailable spare, safety gap, performance limit, new product, data need, or maintainability. Define the required outcome, operating context, target life, budget and schedule constraints, and what must remain unchanged.
“Modernize the PLC” is not an intent. “Restore supported control, retain product behavior, improve diagnostics, and preserve validated safety functions within the approved scope” is a reviewable intent.
4. A change boundary is not a line around the new part
Map the boundary across mechanical, electrical, controls, data, safety, network, utilities, operator workflow, maintenance, and documentation. Include inputs, outputs, timing, energy, configuration, and human decisions that cross the boundary.
The changed controller may affect a drive, which affects motion timing, which affects a robot handshake, which affects quality and safety. Draw the dependency map before deciding that an item is “out of scope.”
5. Classify the change without using the label to avoid assessment
Classify the retrofit as major, safety-related, supplier-driven, emergency, or documentation change to select the route and approvers. Classification does not prove impact is small. A controller replacement may be a major architecture change even when the operator sequence looks familiar.
6. Risk assessment must examine old/new interaction
New hazard
The new device, speed, energy, access, network, or failure mode introduces a hazard that did not exist.
Changed hazard
An existing hazard changes because timing, force, stop behavior, diagnostics, or access changes.
Existing control affected
An old guard, interlock, feedback, limit, or procedure may no longer provide the same risk reduction.
Lifecycle state
Installation, testing, production, maintenance, and decommissioning can have different risk profiles.
Human and system interaction
New screens, prompts, roles, reset logic, or remote access can change how people respond.
Common-cause and interface effect
A shared power supply, network, library, or configuration can create a new common failure.
Record the assumptions, required controls, verification, and residual risk. Do not copy the old risk assessment and change the cover page.
7. Safety-related control: return to the function, not only the component
If a safety relay, PLC, drive, sensor, guard, or emergency-stop circuit changes, restate the safety function, operating modes, stop behavior, restart, diagnostic assumptions, performance level, validation method, and as-running evidence. A new component with a similar name does not prove an equivalent safety function.
8. Electrical impact is more than I/O count
Review voltage, current, inrush, grounding, shielding, isolation, short-circuit protection, heat, cabinet space, connector pinout, analog range, noise, cable length, and spare capacity. Check what the old device did with a floating, failed, or delayed signal and what the new device does instead.
9. Software and data migration are machine functions
Plan tag mapping, scaling, state logic, recipes, retain data, alarms, user roles, HMI text, motion profiles, drive parameters, calibration, timestamps, historian data, and backups. A program that compiles is not a migrated machine.
Define conversion, validation sample, rollback, and evidence. Preserve old data where retention or traceability requires it.
10. Network and remote access create a security boundary
Document devices, zones, protocols, accounts, remote-support route, firmware, certificates, backup, logging, and recovery. Remove obsolete access and avoid copying old shared passwords into a new platform. The retrofit should improve support without widening uncontrolled access.
11. More performance can consume old margin
Faster scan, acceleration, cycle, communication, or recipe changes may expose mechanical backlash, vibration, thermal load, sensor response, product handling, or safety timing. Measure margin, not only target performance. Verify the worst model, load, temperature, utility, and restart condition.
12. Staging and rollback must be designed
Create a controlled staging environment, backup the as-is state, identify test hardware, plan wiring and software migration, and define a rollback route. Record the old project, parameters, firmware, calibration, recipes, mechanical parts, and tools needed to return to known-good operation.
Do not discover rollback prerequisites during a production outage.
13. Regression testing follows the impact map
Test direct functions, adjacent sequence states, product variants, alarms, abnormal and recovery behavior, interfaces, safety, data, HMI roles, maintenance tasks, and site integration. Use the as-is evidence as a reference, but do not preserve an unsafe behavior merely because it existed before.
14. Handover must be an as-modified baseline
Deliver a controlled package containing as-is references, approved change, new configuration items, software and firmware, wiring, parameters, recipes, calibration, risk and validation records, test evidence, deviations, training, spares, backup, restore, and ownership. Name the exact asset and version that was accepted.
15. Hypothetical controller and drive retrofit
Trigger
The controller is obsolete and the drive vendor no longer supports the firmware.
Discovery
The team finds an undocumented online speed limit, a recipe value outside the old project, a safety input wired through a separate module, and a drive parameter tuned at site.
Boundary
The retrofit includes controller, drive interface, HMI, safety validation, recipe conversion, motion timing, cabinet wiring, and recovery procedure.
Solution
Select supported hardware, map functions, preserve required limits, isolate the safety route, convert data, and stage the machine with a controlled spare.
Verification
Compare I/O and states, test normal and abnormal motion, validate safety, run all models, check first-piece quality, confirm data, and rehearse rollback.
Handover
Protect the as-modified baseline, record asset versions, update drawings and manuals, train operators and maintenance, and schedule an effectiveness review.
16. Retrofit decision-gate checklist
- [ ] As-is discovery compares records with the running machine.
- [ ] Unknowns, online edits, parameters, safety, and interfaces are visible.
- [ ] Change intent and boundary are approved before solution selection.
- [ ] Old/new interaction is assessed across mechanical, electrical, software, safety, data, network, and human domains.
- [ ] Safety functions are restated and validated.
- [ ] Data migration, backup, staging, rollback, and recovery are planned.
- [ ] Regression follows dependencies and includes abnormal/restart behavior.
- [ ] Performance margin and worst conditions are verified.
- [ ] As-modified baseline, documentation, training, spares, and ownership are complete.
Conclusion
Retrofit is controlled change to a living machine. Discover the as-is truth, write intent, map the boundary, assess old/new interaction, protect safety and data, stage and rehearse rollback, test the dependencies, and hand over an as-modified baseline.
The best retrofit is not the newest controller. It is a machine that the owner can operate, maintain, validate, and recover with evidence after the engineering team has left.
References
- ISO 12100:2010 — Risk assessment and risk reduction: https://www.iso.org/standard/51528.html
- ISO 13849-1:2023 — Safety-related control systems: https://www.iso.org/standard/73481.html
- IEC 62443 — Industrial automation and control systems security: https://www.iec.ch/standards/iec-62443
View all MINATA technical articles