Can AI actually convert a legacy codebase to modern code?

For large-scale conversion, yes, but only as an orchestrated effort, not a single prompt. The model does the translation; someone has to design the harness, drive it across thousands of files, verify the output, and govern the cost. That orchestration is where projects succeed or stall.

Do you write ABAP or COBOL yourself?

No. Your domain engineers and the model handle the language. I orchestrate the conversion: the harness, the agent workflow, the verification gates, the cost governance, and the coordination that turns scattered AI knowledge into one managed migration.

How do you keep an AI migration from running up a huge model bill?

Routing so the frontier tier is reserved for the hard conversions, caching the shared context, batching, output caps, and a per-file budget set before the run. At codebase scale this is the difference between a proportional bill and a runaway one.

We already have AI-capable people. Why do we need you?

Scattered AI knowledge is not the same as a managed migration. The missing piece is usually an owner: one person accountable for getting the whole codebase converted, verified, and shipped on a timeline. That is the role I fill, working with your people rather than replacing them.

AI-Orchestrated Legacy Code Migration

You have the legacy code, the modernisation deadline, and a model you are convinced can do the conversion. What you do not have is the person to orchestrate it. That is the role I fill.

Legacy modernisation stalls for one reason: converting a large codebase with AI is not a prompt, it is an orchestration problem. An ABAP estate moving to cloud SAP, a COBOL core, an aging Java monolith. Someone has to design the harness, drive the agents through thousands of files, keep the output verified, and keep the token bill from exploding. Most teams have a model they trust and a couple of AI-capable engineers scattered across the org. Few have someone whose only job is to run the conversion to done.

The gap I fill

You are not short on AI belief or on domain experts. You are short on orchestration. I sit between your legacy code and the model:

I design the conversion harness. How files are chunked, converted, tested, and reconciled, so the work is repeatable across the whole codebase, not a demo on one module.
I drive the agents and coordinate your AI-capable people. Their scattered knowledge becomes a single managed effort with an owner, instead of two side projects that never finish.
I keep the output honest. Verification gates, diff review, and a human in the loop wherever correctness cannot be assumed. A migration that compiles is not a migration that is correct.
I govern the cost. At scale, agentic conversion is one of the most expensive things you can run on a frontier model. Routing, caching, and budget caps keep the bill proportional to the work. It is the same discipline in the Fable 5 cost guide.

Your experts, your language, my orchestration

I do not need to be the ABAP or COBOL expert, and I do not pretend to be. The model and your domain engineers handle the language. I handle the part that is actually missing: turning “the AI can probably do this” into a converted, tested, production codebase on a timeline someone can sign off. The orchestration is the same whether the target is clean-core SAP, a rehosted mainframe, or a monolith broken into services.

How it works

Scope first. Before any engagement I write a fixed-price scope: which parts of the codebase, in what order, with what verification, at what cost, delivered within 24 hours and in a form you can forward to whoever signs off. You see the plan and the price before you commit. Here is a representative sample scope.

If you are modernising a legacy codebase with AI and need someone to run the conversion, that is the engagement. It is the same practice I bring to any AI-native engineering team.