Migrating in an AI world: the model reads the code, you do the migration

A vendor points a generative model at a piece of thirty-year-old COBOL and has it explain live what the code does. In the room everyone nods. What sticks is a feeling: the migration you have been postponing for years suddenly looks like a matter of months. That is where it starts to go wrong.

The model did nothing wrong. It read the code faster than a human and summarised it reasonably well. The problem lies in the leap the room makes, from 'AI understands the code' to 'AI does the migration'. Those two are far apart, and in that distance most projects perish.

What AI really does in a migration

Start with what is true. Migrating an old system first means understanding what is there, and that is often the hardest part. The people who wrote the code have retired, the documentation is a folder of screenshots, and the business rules are hidden in a procedure no one dares to touch. A model that reads through that code and turns it into readable explanation saves you weeks. That is work that already pays off today.

There are more places where it helps. It maps a data model and compares fields between the old and the new system. It writes tests that show a new module gives the same answer as the old one. Tasks where AI speeds up the slow work and a human keeps it on course. Use them, they earn themselves back.

Notice what those tasks have in common. They help you understand the code and verify the outcome. The choice of which business rule you scrap, and the judgement of whether you may switch over today, that stays with a human. That distinction looks small and it determines whether your migration succeeds.

Where the promise tips over

Gartner looked at the projects that go furthest, companies that want to leave their mainframe entirely. The prediction of June 2026 is sharp. More than 70% of the mainframe exit projects starting in 2026 will not deliver the intended benefits, and the reason Gartner cites is an overestimation of what generative AI can do. The technology often does what it promises. The assumption underneath is what jars, that a model takes over the heavy lifting.

Why does it go this way? A model that converts code produces something that looks good and mostly works. Mostly. The exceptions sit in the edge cases that make your company unique: the client with an unusual contract, the booking that spans two financial years, the discount that is only allowed once a year. There the generated code gives a plausible answer that is just wrong, and no one notices until a client calls. Leave the migration to the model and you lose precisely the knowledge that makes the difference.

The risk drops through the method, not the model

What does make a migration safe is neither new nor exciting. You cut the work into pieces and put a go or no-go behind each piece. If the first module works for real, with real data and real users, you build the next one. If it does not work, you stop before you are deeper in the hole. This is how we build in waves with a decision at each step, and that decision is human work. A model can put the options on the table, you do the signing yourself.

There is a second rule that goes with it. The old system keeps running until the new one proves itself. No Friday on which you pull the plug on the old one and hope on Monday that the new one holds. You run in parallel for a while, put the outcomes of both side by side, and only switch over once the figures line up. That parallel run is slow and dull, and it is the reason you sleep through the night.

Big bang remains the most expensive route

The figures on large projects have not become any prettier. McKinsey, together with the University of Oxford, studied IT projects of more than 15 million dollars. On average they ran 45% over budget and delivered 56% less value than promised. In 17% of cases it went so wrong that the survival of the company was at stake. That study dates from 2012, well before the current AI wave, and that is exactly what makes it useful. It shows the underlying risk of a migration without a model colouring the figures.

AI does not turn those odds in your favour as long as you do not change the approach. A big bang with a language model underneath is still a big bang. Generating code faster and putting it live in one go mainly means you reach the edge of the cliff faster. A model that writes the code leaves the 17% from the study largely in place. At most it shifts to a different kind of error, one you only see once the new system is already running.

Code you own and open standards make every step verifiable

You can only make a go or no-go at each step if you see what is happening. That requires two things. The code sits in your own repository from day one, so that you and your team can read every change and not only the vendor. And the stack runs on open standards, so that you can inspect the data and the systems without asking permission. Our platform is built on that: your code, your data, a standard stack that you run yourself and can hand over. Without that ownership, every check is a matter of trusting what the vendor tells you.

Switching is also easier than it was three years ago. The EU Data Act, Regulation (EU) 2023/2854, has required cloud providers since 12 September 2025 to offer switching options and to phase out switching costs. In 2024 Google Cloud, and then AWS, removed the egress fees for those leaving the cloud, partly under pressure from that same law. The price of leaving a system that does not suit you is falling. Anyone who plans their migration in pieces uses that lower threshold instead of ignoring it.

First map the process, then the tools

Before you turn a model loose on your legacy, there is a step no AI does for you: working out what the current system really needs to keep doing, and what may go. An audit records that, with the business rules and the data flows included, before a single module is built. Only then comes the question of which tools you deploy, and then AI is one of the handiest you have.

In the coming years AI will get better at reading old code and writing tests, and that is good news for anyone who has to migrate something. Where the risk sits does not change: in the switch-over itself, in the edge cases, in the moment you dare to turn off the old system. That remains human work, in pieces, with a way out at every step. Use AI for the work it can handle, and leave the decision with the people who bear the consequences.