The PLC Was Replaced. Where Is the Program?
TL;DR: Hardware is replaced within hours; what keeps the machine down is a missing source project for the program inside it. Archiving that file with its version and date takes half an hour, and not having it costs days of production.
When a controller fails, everyone thinks about the spare part first. The service engineer arrives, swaps the card, and you assume the job is done. The replacement, though, ships empty: your machine's program is not on it. Until that program is loaded, the machine only consumes electricity.
And the question at that moment is always the same: who has the program?
Where the program usually lives
- With the machine builder. The most common case, and if they are still trading it is resolved with a couple of e-mails.
- With the integrator who did the project. Companies close, move or lose the engineer who knew the system.
- On an old laptop. Somewhere on a shelf in the store room, and nobody is sure it still boots.
- Nowhere. The answer we meet most often on site: "we must have a copy somewhere", followed by a search that ends empty-handed.
If the source cannot be found, two options remain: obtain it again from the company that built the machine, or have the program rewritten. The second takes days, sometimes weeks, and the machine may not behave exactly as it did before.
"We can read it back off the card" is not always true
On some systems the program can be read back from a running controller. That does not mean you hold the source:
- What comes back usually has no comments and no symbol names, leaving code that is hard to work on at the next service call.
- Blocks protected by the vendor cannot be read at all.
- If the card failed completely, there is nothing left to read.
So "we will just pull it off the card" is not a backup plan. Removing a memory card from a running machine also stops production, which makes it planned-downtime work at best.
What the archive should contain
| Item | Why it matters |
|---|---|
| Source project for the controller program | The actual content to load onto a new card |
| Operator panel (HMI) project | Screens, buttons and alarm texts live in a separate file |
| Recipe and parameter lists | They rarely travel with the program and are usually kept apart |
| Which software and which version opens it | The wrong version either refuses the file or damages it on open |
| Date of the backup and who took it | The only way to tell two similar files apart later |
| A short note on the last change | Answers "what changed in this version" a year from now |
Where it should be kept
Keeping the file on the PC beside the machine is not enough; that PC can fail in the same incident. The archive belongs in the company backup system, with one copy held offline.
Access should be limited. The file has commercial value and, in the wrong hands, can change how the machine behaves. Someone should be able to say who can open that folder.
Who archives, who loads
The distinction matters: archiving the file is IT work, loading it onto a controller is automation work. We build the archive and store the file safely; when a card is replaced, we hand it to the authorised service or the machine builder. We do not load programs and we do not modify them.
That boundary protects you as well: the party responsible for how a machine behaves should be the party that wrote its logic.
Put it in the contract for new machines
The easiest fix is to prevent the problem at purchase. When buying a machine or commissioning an automation project, add a clause: on completion, the source projects for the controller and the panel are handed over, together with the software version needed to open them. Delivery of those files becomes part of the acceptance paperwork.
For machines you already own, contacting the company that installed them today is enough. Asking while they are still in business is far easier than searching years later.
How Yamanlar Bilişim helps
Our part is to inventory which files exist for each machine, prepare the list of what to request from the companies that installed them, archive those files with version and date, and connect the archive to the company backup routine. When a card is replaced, the file is ready to hand to the service engineer. The rest of our work for production sites is on the manufacturing and workshops page, and the wider backup discipline sits in backup and disaster recovery.
Frequently asked questions
Frequently Asked Questions
Isn't the program already inside the controller?
The running code is, but the source project is separate. If the card fails, the code goes with it. What you need to hold is a source file that can be loaded onto a new card and worked on when required.
Should we obtain the file, or the service company?
In most cases the machine builder simply provides it; your job is to ask and to record that you received it. Where programming software or access rights are needed, the authorised service extracts the file and you archive it.
How often should the archive be updated?
Every time the program changes. When an automation company adjusts something, asking for the updated file before they leave should become routine. On a machine that never changes, the file stays valid for years.
Can we copy the memory card from a running machine?
Not while it runs — the machine stops. That work belongs in planned downtime, supervised by whoever knows the system. In most cases it is unnecessary anyway, because the file already exists at the company that built the machine.
What if the program is password protected?
Blocks the vendor has protected cannot be opened, and that is normal. In that case what you archive is the file exactly as the vendor delivered it. Attempting to break that protection conflicts with both the contract and machine safety.
Author
Serdar YAMAN
Yamanlar Bilişim Expert
Writes content on IT infrastructure, cybersecurity, and digital transformation at Yamanlar Bilişim. Get in touch for any questions.
Professional Support
Get help on this topic
Let's design the Business Continuity and Disaster Recovery solution you need together. Our experts get back to you within 1 business day.
support@yamanlarbilisim.com · Response time: 1 business day
Keep Reading
Related Articles
The 3-2-1 Backup Rule: Practical Implementation for SMEs
The 3-2-1 backup rule is an SME's most reliable defense scheme against data loss. This guide explains what the rule means, the scenarios where it saves you, and how to apply it step by step in an SME office.
What Are RTO and RPO? Setting Your Disaster Recovery Targets
RTO and RPO are the two foundational numbers of a disaster recovery plan. This guide shows how SMEs should set these metrics, with example calculations and how they translate into a backup strategy.
Veeam vs Acronis vs Synology Active Backup: SME Backup Comparison
The three most common backup platforms at SME scale — Veeam, Acronis, and Synology Active Backup. This guide compares them across licensing, scope, restore flexibility, and total cost.