Sorry, AI Won't Be Migrating Your Plant This Weekend

The hype is loud. The actual work is quieter — and more interesting than what's being pitched.

Setting the noise floor

No, the AI is not going to migrate your plant this weekend. Or this month. Or this year, regardless of what a sufficiently confident demo might have suggested.

We're saying this carefully because the gap between "AI is doing real work in PLC migrations" and "AI will replace your migration project" has widened to the point of comedy — and most plant managers, somewhere between a vendor pitch in March and a LinkedIn post in April, have stopped being able to tell which version of the claim they're being sold.

The truth is more interesting than either pole. Two years into using language models on real legacy migration work, we can say something specific about what they've changed. The headline isn't AI does the migration. The headline is AI has expanded what a legacy migration project is allowed to be.

This piece is about that shift.

What's actually new

In 2023, taking on a migration meant scoping the project carefully against a hard constraint: most of the engineering hours had to go to mechanical work nobody enjoyed but everyone needed. Reading undocumented ladder logic line by line. Hand-converting routines that hadn't been touched in twenty years. Writing inline documentation that the schedule would inevitably squeeze. Each project budget had a fixed chunk of "necessary tedium" that limited how much engineering judgment could actually be applied to the system.

That chunk has shrunk dramatically. The applications of language models that have proven themselves in our migration work aren't autonomous — they're augmentations of work that already had to happen, applied to the highest-volume mechanical tasks in the workflow:

Restoring the lost narrative in legacy code. A twenty-five-year-old PLC program with no documentation and no living author is, today, readable in a way it wasn't three years ago. Our engineers feed the program in and get back an annotated rendering — what each routine is doing, where the state machines live, where the workarounds are, where the original logic appears to have been amended without comment. The "discovery phase" of a migration used to be three to five weeks of careful archeology. It's now days.

First-pass conversion at scale. Pattern-rich code — most ladder logic, most function block diagrams — converts faithfully and quickly into modern equivalents. The first pass is never the final pass; the senior engineer who knows your plant still walks every line. But the engineer's hours are now spent reviewing and refining instead of typing.

Documentation that actually gets written. The migration that produces a new program nobody fully understands defeats half the purpose of the work. We can now produce thorough, consistent inline documentation as a default — not as a stretch deliverable — across thousands of tags, dozens of routines, the whole codebase.

What's now possible that wasn't

The interesting consequence of these shifts isn't speed. It's scope.

Three years ago, the project to migrate a complex multi-cell installation with substantial undocumented logic was scoped tight. Take the existing program, convert it as-is, change nothing else, get out before the budget overruns. Like-for-like migration as a defensive posture, because anything more ambitious was hard to justify against the tedium budget.

The same project today can credibly include scope that used to be a separate, deferred phase — and is usually never funded. Standardizing alarm logic across cells. Restructuring tag hierarchies. Updating naming conventions to match a modern plant standard. Cleaning up the accumulated archeology of twenty years of workarounds. The engineering hours that used to go to mechanical conversion now go to the systems-level improvements the plant has wanted for a decade.

This is the part the demos don't show. The visible AI productivity gain is "the model wrote the code faster." The actual change is that the project can now include things the plant has been asking for since 2014.

What stays the same

Anything that requires judgment, plant context, or safety certification still requires the people who have all three.

The cutover weekend is still a cutover weekend. The factory acceptance test is still a factory acceptance test. The safety certification still requires engineers who understand what the certification is for. The architectural decisions about how the new system should be structured are still made by people who have run lines like yours. None of that is on the AI side of the ledger, and shouldn't be.

This is, on reflection, the better division. The work that compressed is the work nobody particularly wanted to do anyway. The work that didn't compress is the work that requires expert judgment — and now there's more of it relative to the rest of the project, which is the right shape for an engineering firm.

What this changes for your next migration

If you're staring at a migration that was scoped two years ago — or scoping one now — the calculus has shifted in a way that's easy to miss.

The project that looked like "minimum viable swap" three years ago is now the same dollar figure as "modernize the system properly." The decision to migrate is also a decision about what the resulting system should be — and the cost difference between replicating what you have and upgrading what you have has narrowed to almost nothing.

This is the conversation worth having before the project starts. Not "how fast can the AI write the code." But: what could this migration actually accomplish, now that the tedium budget has dropped? The plants getting the most from the shift are the ones who reopened the scope conversation rather than locking in the 2022 plan.

Where this is going

The plants and engineering firms that figured out how to use these tools well are not the ones running breathless demos. They're the ones whose migration projects quietly include more in the scope, deliver cleaner systems, and produce documentation the next engineer can actually use. The change is real. It just doesn't look like the slide deck.

Forty years of legacy migration work has taught us that the right time to migrate is one year before the failure that forces you to. AI has not changed that. What it has changed is what one year before gets to look like — the scope you can fit into the project, the institutional knowledge you can preserve, the system you end up with on the other side.

If you're sketching out a legacy migration and trying to figure out what's actually possible given how the work has changed, that's the conversation we like having. Talk to us →