What should you do first?
Back up everything before anyone touches anything. A clean upload of every PLC, HMI, robot controller, drive parameter set and network device is your insurance against the next fault, and it's the material the person taking over will start from.
Then write down what the line actually does today, including the workarounds operators use. Those workarounds are the best map of where the code is wrong.
Do you own the PLC program?
It depends on your contract, not on whose controller it runs in. Many integration contracts transfer the application code to the customer and keep the integrator's reusable libraries licensed rather than sold; some say nothing at all. Read the purchase order and terms before you assume either way, and get legal advice if it's disputed.
For every new project, put it in writing: you receive the complete, commented source, every password, and the drawings, as a condition of final payment.
What should you ask the previous integrator for?
If they're still answering, ask for the complete handover set:
- The offline project files for every PLC, HMI and robot, not only what's in the controller
- All passwords and source-protection or know-how-protection keys
- Electrical drawings and panel layouts, as-built
- Network addresses and the device configuration files
- The bill of materials, with firmware and software versions
- Any functional description, test records or open-items list from commissioning
- Software licences bought on your behalf
Can code be recovered from the controller alone?
Usually the logic can. On many platforms an upload from the controller recovers the program and tags but not the comments and descriptions, which lived only in the integrator's offline file. The result runs, but nobody can read it.
Recovering it means working out what each routine does, renaming and commenting it, and checking it against the machine's actual behaviour. It's slow, careful work, and much cheaper than rewriting a system that mostly works. Protected routines are harder; if the keys are gone, those sections may have to be rebuilt.
When does a system need rewriting instead?
When the structure itself is the problem: logic that can't be made safe to change, a platform that's obsolete and unsupported, or a machine that never met its spec in the first place. Even then, it's usually a section that needs rewriting, not the whole program. An assessment should tell you which case you're in before anyone quotes a rebuild.
What should the handover leave you with?
Whoever recovers the system, the job isn't finished until you have:
- Commented, structured source code you own
- As-built drawings that match the panel
- Current backups stored at your plant
- A walkthrough with your maintenance team
- No dependency on one person or vendor to make the next change
Common questions
Our PLC code has no documentation and the original programmer is gone. Can it be fixed?
Almost always. The logic can usually be uploaded from the controller; the work is reverse-engineering what it does, documenting it, and fixing the faults. A short assessment tells you whether it's recoverable or needs a section rewritten.
The PLC is password-protected and the integrator won't release it. What can we do?
Check your contract first; many transfer the application code to you. If the protection can't be lifted, the protected routines can be rebuilt from the machine's behaviour and the rest of the program, which is slower but workable.
How long does it take to take over an undocumented system?
It depends on the size of the system and how far it is from working. Our recovery work starts with a small, fixed-price assessment that ends with a written answer and a firm number.