Legacy PLC migration without the drama

Why migration projects go wrong

The typical approach is to treat a migration as a straight conversion: take the old code, convert it to the new platform's syntax, test it, and cut over. This works for simple systems. For anything complex, it's a recipe for an expensive mess.

The problem is that most legacy systems have accumulated decades of modifications - patches, workarounds, bypasses, conditional logic that nobody can explain. Converting this code faithfully means converting all the accumulated debt along with it. You end up with a brand new controller running code that's just as unmaintainable as what you started with, so nobody understands it on the new platform either.

The other risk, equally common, is the opposite extreme: deciding to rewrite everything from scratch. This sounds clean in theory, but it means re-specifying every behaviour of a system whose original specification (if it ever existed) is long gone. Inevitably, things get missed. The new system behaves differently from the old one in ways that only become apparent during production, and you spend months chasing issues that the old system had silently handled.

My approach

I start with the existing system, not the existing code. The first phase is understanding what the system actually does - not what the code says, and not what anyone remembers. This means reading the logic, observing the process, talking to the people who run it and the people who fix it, and documenting the actual runtime behaviour. The output is a retrospective functional specification that describes the system as-is.

From there, we can make informed decisions about what to carry forward, what to improve, and what to leave behind. Some of the old logic will be sound and should be replicated. Some will be workarounds for problems that no longer exist. Some will turn out to be genuinely wrong - quietly causing issues for years that everyone assumed were normal. You can only tell the difference if you understand the process, not just the code.

Common migration paths

What you get

A modern, documented, maintainable control system that your team can support from day one. The migration includes a retrospective design specification of the original system, a forward-looking design for the replacement, structured and commented code on the target platform, and a changeover plan that minimises production impact.

I plan changeovers around your production schedule and stay on-site through the transition. If the system needs to keep running during migration, I'll design a phased approach that migrates sections independently while maintaining interoperability with the parts that haven't moved yet.