Migrating an Obsolete PLC on Paper Container Machinery: A Planning FAQ

An eastern European converter kept a single used control board in its store as insurance for a cup line whose controller had been obsolete for years. When a driver fault finally took the controller down, the plant swapped in the spare and understood that the insurance was now spent; the next failure would mean days of downtime while a board was hunted down. The plant chose a planned migration instead. Yoco Group supplies and services paper container lines, and control obsolescence is a risk buyers often discover late. This FAQ answers five questions about migrating a legacy PLC on container machinery.

What is a legacy PLC migration and how is it different from a rebuild?

A legacy PLC migration replaces an obsolete controller and its program with a supported platform while keeping the machine, its drives and its mechanics. It is a control project rather than a mechanical one, because the steel and the process equipment stay and everything that decides how the machine moves is renewed. A rebuild, by contrast, addresses the mechanical condition of the machine as well. The distinction matters for planning, because a migration is measured in weeks of preparation and a short cutover, while a rebuild is measured in months and a longer stop.

Why is an obsolete controller a risk even while it is running?

Because a working controller gives no signal that it is about to become unsupportable, and the risk accumulates quietly through several channels. Spare parts disappear as the maker stops stocking boards, the software tools needed to change the program fall out of support, the documentation is lost, and the engineers who understand the machine retire or leave. Each of these closes an option, and the plant generally discovers the closure at the moment it needs the option, which is the worst possible time. Keeping a single used board in the store delays the problem without removing it.

What are the phases of a well-planned migration?

A well-planned migration has five phases, and the plant should insist on all five. The first is scope, deciding whether the project covers only the controller or also the drives, the safety circuit and the network. The second is recovery, obtaining the existing program or reverse engineering the logic from the machine and documenting it station by station. The third is build, writing and simulating the new program against that documented logic. The fourth is test, proving the new controller off-line. The fifth is cutover, switching the machine in a planned window with a rollback plan in place.

How should a plant choose the cutover window?

The window should be chosen from the order book rather than the calendar alone. The best window is a period when the line is genuinely not needed, which for many container plants is a scheduled holiday, a seasonal lull or a planned maintenance stop. The window should be long enough to cover the switch and a day of proving, and it should include a rollback plan that returns the line to the old controller if the new program does not behave. A rollback that is written and rehearsed is what allows the plant to commit to a window at all. The plant that plans is choosing a short controlled stop over an unknown uncontrolled one.

What should the handover include after the migration?

The handover should leave the plant able to understand and change its own machine. That means the program source, the drawings, the credentials and a written description of the logic, delivered as part of the project rather than as an afterthought. A plant that receives a new controller but not the means to understand it has traded one dependency for another. The migration is also the moment to design the network boundary, because the network is being touched anyway, and to verify that the safety circuit still matches the machine as the guarding standards expect.

Prepared by 燕七.