On paper it's a one-to-one conversion. It never is.

Migrations like this get sold as one-to-one. Take the old system, replicate what it does in new hardware and software, hand it back behaving exactly the same. Clean scope, easy to sell — on the cover page it reads like a copy-paste with a budget attached.

There’s a particular kind of subsystem that quietly proves that cover page wrong, and once you’ve fought one you start seeing it everywhere: an old Mitsubishi FX-series PLC, a program written in the 1990s, in ladder logic, in GX Developer — the older generation of Mitsubishi’s MELSEC programming software. The job is to move it into ABB 800xA, rebuilt as a control module and coded in Function Block Diagram instead of ladder. “Same behavior, new platform.” That’s the instruction. Here’s where the instruction runs out.

“One-to-one” is a sales sentence, not an engineering one

I don’t think anyone’s lying when they call it 1:1. From the customer’s side it’s true: same buttons, same sequence, same output, the line runs like it always did. That’s the outcome they’re paying for, and it’s a fair way to describe it.

But same outcome and same logic are two different jobs, and the gap between them is where most of the work hides. Three things in a subsystem like this open that gap up. None of them are on the cover page.

One: ladder and FBD don’t think the same way

Ladder logic and FBD aren’t two dialects of one language. They’re two different ways of imagining a machine. Ladder reads like rungs of contacts and coils, current flowing left to right — a mental model that made sense back when it was describing literal relay panels. FBD reads like signals flowing through blocks. Different generations, different instincts.

So translating one into the other isn’t mechanical, in either direction. A pattern that’s one obvious rung in ladder can become an awkward cluster of blocks in FBD, and something clean in FBD would be a mess of rungs going back. The trap is that you can usually get the output to match while the structure underneath ends up nothing like the original — which feels like success right up until an edge case behaves differently. Reproducing the exact behavior is the genuinely hard part. Not because the new platform can’t do it, but because proving the new version behaves identically means understanding the old one far more deeply than just reading it top to bottom.

Two: the parts with no equivalent

Some of what these old programs lean on simply has no twin in 800xA. It doesn’t translate; it has to be rebuilt by hand, and you only find each one by reading carefully.

• Jump instructions. The ladder uses conditional jumps (CJ) to skip whole sections of logic — and anything caught inside a skipped section holds its last state rather than resetting, including timers, which freeze rather than clear. There’s no like-for-like jump to drop into the FBD, so that control flow has to be re-expressed as execution order and enable conditions — a different mental model, not a swapped instruction. Reproduce the freeze-don’t-reset behavior, or you’ve introduced a silent edge-case difference.
• Physical adjustments wired into the logic. Not every setpoint lives in the code. Some values — things like timer presets — were tuned on the actual machine through physical potentiometers. On the FX those pots don’t hold the value directly: they land in special data registers (D8030/D8031), and the program scales those into a preset. In the new world they become parameters in the control module, which forces a decision the original never wrote down: what was meant to stay field-adjustable, and what was just how you did it in 1995.
• Special auxiliary relays. These programs lean on M8000-series system relays — for example M8028, which switches the timebase on a block of timers — to shape parts of the logic. Those are platform-specific system bits. 800xA has its own mechanisms, so each use has to be understood for what it was actually doing and then re-created with whatever the new platform offers — never just copied across.

Three: the integration model hiding inside the “1:1”

This one isn’t visible until you go looking, and a like-for-like brief is the worst-placed document to catch it.

A controller never works alone. It talks to whatever sits around it — other controllers, I/O, the wider line — and how it talks is part of what it does, even though none of that shows up when you read the program top to bottom. The quiet assumption baked into a 1:1 brief is that this conversation carries over untouched. It often doesn’t. Move from a decades-old platform to a modern one and the integration model itself can change: how this corner of the system connects to everything else, and what that connection is even made of.

Sit with what that means. Same function on the floor, a different nervous system behind it. You can’t replicate a connection that no longer exists in the same form — you have to re-engineer how the thing talks to the rest of the system, and that’s real work the cover page never priced. It isn’t exotic. It’s just invisible from the program listing, which is exactly why a brief written off that listing keeps missing it.

How I read a program written before I was born

I’m early enough in this trade that a 1990s ladder program is genuinely foreign to me — I’m 21, about eighteen months in. I was never going to out-experience code like that. So I lean on the tooling, deliberately, and I’ll say how, because the method is half the point.

The move is to get the old program out of its native environment and into plain, readable form — export it to PDF, or any format that preserves what the logic actually does — and then use an AI model as a reading aid (making sure to work on a company-based, on-prem ML platform — and only after you’ve verified it’s cleared with your company, the customer, and anyone else whose data is involved): explain this section by section, with annotated snippets I can check straight back against the rungs. That turns a program nobody has touched in decades into a readable map. From there you work out which parts won’t survive the move — the jumps, the specials, the field-set presets — and reason through how a given block of ladder should be rebuilt as FBD.

I want to be honest about the limits, because an automation audience will rightly distrust this. The AI is wrong sometimes. It guesses at intent, occasionally with confidence it hasn’t earned. It’s a reading aid and a thinking partner, not an authority — every conclusion gets checked against the real program and the real behavior before it goes anywhere near the new code. But as a way to turn an opaque 1990s artifact into something you can reason about in days instead of weeks, it earns its place. This is exactly the easy work the tooling is good at: not making the engineering call, just clearing the brush so you can.

The same trick, pointed at the answer

Reading the old program is only half of it. The other half is proving the new one matches — and the same approach works there too. Export both programs to text that mirrors their logic — the ladder and the FBD each dumped to PDF, or any format that preserves what the code actually does — and feed both to an AI at once, asking it to compare them logically and functionally and report where they diverge. It won’t rebuild anything for you, but it’s a fast, tireless second reader: the rung that didn’t survive the move, the edge case the FBD handles differently, the output that quietly changed — it flags them for you to chase down. Same caveat as before: every flag gets checked against the real behavior before you trust it. But pointing the tooling at both sides at once turns “does this match?” from a week of manual cross-reading into something you can iterate on in an afternoon.

The takeaway

A one-to-one migration is real from the customer’s chair and a fiction from the engineer’s, and both can be true at once. The danger isn’t the label — it’s when the people scoping the work believe it.

So here’s what a job like this teaches, and what’s worth doing on the next one before you touch a single rung: when something is sold as one-to-one, go hunting for the three places it can’t be.

• The paradigm gap — wherever the source and target tools think differently (ladder to FBD), behavior is hard to prove, not just to write.
• The orphans — the platform-specific bits with no equivalent (jumps, system relays, field-set presets) that have to be rebuilt by hand.
• The integration model — how the thing talks to everything around it, which a “like-for-like” brief loves to assume stays the same when it doesn’t.

Find those three early. Price them honestly. Then “one-to-one” stops being a lie you discover halfway through and becomes a plan you can actually stand behind. The label was never the problem — believing it was.