Quick answer
To plan a legacy code modernisation with AI coding agents, start by having the AI explain and document the old system, not rewrite it. Capture current behaviour with tests, then migrate one small module at a time, checking each against those tests. Keep a developer reviewing every change, run old and new side by side, and only switch over once the results match.
Key takeaways
- Document first: ask AI to explain what the old code does and why
- Capture behaviour with tests before changing anything
- Migrate in small slices, one module or report at a time
- Run old and new side by side until outputs match
- Keep a person accountable for every merged change
📘 Main article: This guide supports GPT-6.5 Leak? MiniMax M3.1 Flash, Gemini 4 Carbon and Kimi K3.1 Explained. OpenAI says its latest models are much better at understanding languages such as COBOL, Fortran and Visual Basic. This guide turns that into a careful plan.
Plenty of businesses still rely on an old system: a stock database, a bespoke invoicing tool or a spreadsheet full of macros. They work, but nobody quite knows how. AI coding agents are getting better at reading this kind of code, which makes a careful upgrade more realistic.
Why is legacy code hard to change?
Because it holds years of business rules that nobody wrote down. The original developers have often left, and small quirks may be doing important jobs, such as rounding VAT a certain way.
What should AI do first?
Explain, not rewrite. Give the agent read-only access to a copy of the code and ask it to produce:
- A plain-English summary of each module and what it is for
- A list of business rules it finds, such as discounts, tax and date handling
- A map of inputs and outputs: files, databases and reports
- A list of questions for the people who use the system
💡 Tip: Ask your staff to check the AI’s list of business rules. They will spot anything the code does that the AI has misunderstood.
How do you migrate safely?
- Write tests that record what the old system outputs for real sample inputs.
- Pick one small module, such as a single report, to migrate first.
- Have the agent translate it, with a developer reviewing the change.
- Run both versions side by side on the same inputs and compare outputs.
- Switch over only when results match, then move to the next module.
Set clear limits on what the agent can change and deploy. Our guide to human approval boundaries covers this, and our agent feedback loop helps you review each step.
What can go wrong?
| Risk | How to reduce it |
|---|---|
| Hidden rules lost | Test with real historical data before switching |
| Agent changes too much at once | Limit each task to one module and review every change |
| Sensitive data exposed | Use anonymised copies of data for AI work |
| No way back | Keep the old system running until the new one is proven |
Read the news behind this guide: GPT-6.5 Leak? MiniMax M3.1 Flash, Gemini 4 Carbon and Kimi K3.1 Explained.
Frequently asked questions
Can AI convert COBOL to a modern language?
It can help a lot, especially with explaining and translating code. A developer should still review every change and test it against the old system’s output.
Do I need a developer if I use AI agents?
For anything your business depends on, yes. AI speeds the work up, but someone needs to own the result.
How long does a legacy migration take?
It depends on the size of the system. Migrating one small module at a time is slower at first but much safer.
Should I let an AI agent work on live systems?
No. Work on a copy, with anonymised data, and only deploy changes after testing and review.
Related posts
- GPT-6.5 Leak? MiniMax M3.1 Flash, Gemini 4 Carbon and Kimi K3.1 Explained
- How to Set Human Approval Boundaries for AI Workers
- How to Build an AI Agent Feedback Loop: Brief, Check, Score, Repeat
