Who this is for

Plant owners, maintenance leads, and engineering managers running lines on ageing PLCs who are weighing whether to keep, upgrade, or replace the control system. Also useful for anyone being pitched a controls-modernisation project and wanting to sanity-check whether it's actually needed.

Age is not a reason

The most common bad reason to replace a PLC is "it's old." A 2005 PLC that still runs reliably, still has obtainable spares, and still has people who can program it is doing its job. Replacing it for its age alone spends capital to solve a problem you don't have. Plenty of 15- and 20-year-old control systems are still the right answer.

The right question isn't "how old is it?" — it's "what specific risk or limitation does it impose, and is that risk now material?"

Decision rule: replace a PLC for a named, material reason — obsolescence, spares risk, skills risk, undocumented code, or a blocked business need — not for its age. If you can't name the reason, you don't have one yet.

The five real triggers to replace

1. Spares are no longer obtainable

If the CPU, I/O modules, or power supply can no longer be bought new — and the only source is grey-market or salvaged units of unknown condition — every breakdown is a gamble. When a single module failure could mean weeks of downtime hunting for a part, the spares risk has become material. This is the most common legitimate trigger.

2. The platform is vendor-discontinued / end-of-support

When the manufacturer has formally ended support and stopped producing the line, you are on a clock. Firmware help, documentation, and engineering support dry up. Even if spares exist today, the supply is finite and shrinking. Plan the migration before the clock runs out, not after a failure forces it.

3. You can't hire people who know it

A control platform is only as supportable as the skills available to service it. If your local system-integrator pool no longer has — or charges a heavy premium for — people who can program and troubleshoot the platform, you have a skills risk. A line that only one ageing contractor can fix is a line with a single point of failure that isn't on the shop floor.

4. The code is undocumented and the author is gone

Undocumented PLC code whose original author has left is a latent crisis. The line works until it doesn't, and when it doesn't, nobody can read the logic to fix it. If you have no commented code, no schematics, and no as-builts, you are one fault away from a reverse-engineering project under production pressure. Sometimes the right move is to re-engineer the controls properly while you still can, on your timetable.

5. It blocks a change the business needs

If the existing PLC physically cannot support what the business now requires — additional control logic, recipe management, new sensing, integration to ERP/MES, faster cycles, or a new product — and it can't be extended, then it's a constraint on the business, not just an old box. This is a forward-looking trigger: the line works fine today but caps where you can go.

The decision framework

QuestionIf yes →
Can you still buy spares (CPU, I/O) new?No → strong replace signal
Is the platform still vendor-supported?No → plan migration on your timetable
Can your local SI pool program and fix it affordably?No → skills risk; lean replace
Is the code documented and readable by someone you can call?No → re-engineer while you still can
Can it support the changes the business needs next?No → it's now a business constraint
None of the above — it just feels old?Keep it. Age alone is not a reason.

If one or more of the first five answers is a "no," you have a real case. If only the last applies, you don't — yet. Re-run the framework every 18–24 months; the answers change over time, and the goal is to act on a planned migration before a forced one.

Measure before you modernise — don't replace the PLC to "get OEE"

A frequent and expensive mistake: replacing a PLC because "we can't get OEE data off it." You don't need to. A non-intrusive Tier 1 visibility retrofit measures real OEE without touching the PLC — independent sensors, counters, and current clamps feeding a dashboard. Do that first. The data tells you whether the PLC is actually a problem, or whether your losses are mechanical, scheduling, or operator-driven and a new PLC wouldn't have moved the number. See how to measure OEE on an old line without buying a new PLC and the plastics OEE retrofit case study, where the data deferred a much larger capex.

Failure mode: replacing the PLC on a hunch that it's the bottleneck, then finding after the cutover that OEE barely moved because the real losses were mechanical wear and changeover discipline. Measure first; the data reframes the decision.

If you do replace — do it once, do it right

A controls modernisation (a Tier 2 upgrade in the digitalisation cost tiers) is the chance to fix the underlying problems, not just swap the box:

  • Choose a locally-supportable platform — Siemens (e.g. S7-1500) or Allen-Bradley CompactLogix are the usual safe choices in African markets, with a deep local SI pool and obtainable spares for years.
  • Re-engineer the control philosophy from the mechanicals up, rather than literally copying old logic you don't fully understand.
  • Document properly — commented code, schematics, BOM, as-builts. The thing whose absence caused the crisis should not be recreated.
  • Add a modern HMI in the operators' language — this alone often cuts mean-time-to-repair by telling operators what's wrong.
  • Plan the cutover — minimise the shutdown, keep the old system as a fallback during commissioning where feasible.
  • Buffer the new platform's critical modules at install — see spare-parts strategy.

Typical cost for a controls modernisation in South Africa, 2026: roughly ZAR 600 000–1.2 million per line depending on platform and scope, with an uplift if the line has to be reverse-engineered from the mechanicals because documentation is missing. The reverse-engineering premium is exactly the cost of having let trigger #4 run too long.

Planned vs forced migration — the cost difference

The single biggest lever on PLC-replacement cost is timing. A planned migration happens on your schedule, during a planned shutdown, with the old system available as a fallback and time to document and test. A forced migration happens after a failure you can't fix — under production pressure, at premium cost, often with the old code undocumented and the line down while you reverse-engineer it. The triggers above exist precisely so you can convert a future forced migration into a present planned one.

What CISH does in this part of the process

We assess whether a PLC genuinely needs replacing — often starting with a Tier 1 visibility retrofit to measure the real problem before recommending capex — and deliver controls modernisation on locally-supportable platforms with proper documentation. See Line Upgrade & Digitalisation and what it costs to digitalise a production line.

Frequently asked questions

My PLC is 15 years old — should I replace it?

Not for its age alone. Replace it if spares are unobtainable, it's vendor-discontinued, you can't hire people to service it, the code is undocumented with the author gone, or it blocks a change the business needs. If none of those apply, a reliable 15-year-old PLC is doing its job.

Do I need to replace the PLC to get OEE data?

No. A non-intrusive visibility retrofit measures real OEE without touching the PLC. Measure first — the data often shows the PLC isn't the problem, and a replacement wouldn't have improved the number.

Which platform should I migrate to?

In African markets, Siemens and Allen-Bradley are the usual safe choices — deep local system-integrator skills, obtainable spares, and long support horizons. The right one depends on your existing skill base and spares cupboard.

What does a controls modernisation cost?

Roughly ZAR 600 000–1.2 million per line in 2026, depending on platform and scope, plus an uplift if the line must be reverse-engineered because the original documentation is missing.

Why is a planned migration cheaper than a forced one?

A planned migration happens on your schedule, in a planned shutdown, with the old system as a fallback and time to document and test. A forced one happens after an unfixable failure, under production pressure, at premium cost — often while reverse-engineering undocumented code with the line down.