That 20-year-old system can finally go. Carefully.

Almost every established organisation has one: a system written decades ago, often in COBOL or an old in-house framework, that still runs payroll, billing or the core of the business. The people who wrote it have retired, the documentation is thin, and everyone is afraid to touch it.

The cost of replacing such systems was never mainly the new code. It was the months of archaeology needed to understand the old code first. That is exactly where AI coding tools have become strong. Microsoft and GitHub have published how they use AI agents on COBOL migrations, IBM has built its own tooling, and in February 2026 Anthropic promoted Claude Code for the discovery and documentation stages of COBOL modernisation.

• Reading code nobody remembersExplaining what each program does in plain language, including the odd corners that matter.
• Mapping dependenciesWhich programs call which, which files and tables they touch, and what breaks if one changes.
• Documenting business rulesTurning buried logic, like how a discount or a penalty is calculated, into a readable list that the business can check.
• Writing tests for today's behaviourTests that record what the old system does now, so you can prove the new one does the same.
• Drafting the new codeA fast first version of each replacement piece, for engineers to review, improve and own.

AI speeds up the understanding. It does not remove the reasons migrations go wrong:

• Hidden behaviour. Old systems often do things no one wrote down, like a month-end job that quietly fixes bad data. Miss it, and the new system is "correct" but the business breaks.
• Data. Decades of records with odd formats, duplicates and exceptions rarely move cleanly.
• The big-bang switch. Turning off the old system and switching on the new one in a weekend leaves no way back when something unexpected happens.
• Trusting the machine too much. AI-translated code can look right and still be subtly wrong. Every piece needs testing and review by people who understand the business.

The approach that works best is the strangler fig, named by software author Martin Fowler after a tree that grows around its host until the host is no longer needed. Instead of one big switch, you replace the old system piece by piece.

1. Step 1: UnderstandUse AI to document the system, map its dependencies and list its business rules. Have the business confirm the rules are right.
2. Step 2: Capture behaviourWrite tests that record what the old system does today, including its quirks.
3. Step 3: Put a front door in placeRoute requests through a layer that can send each one to the old system or the new one.
4. Step 4: Replace one pieceStart with something valuable but low risk. Build it, test it against the old behaviour and run both side by side.
5. Step 5: Switch, then repeatMove traffic for that piece to the new system, watch it closely, and move on to the next. Retire the old system only when nothing depends on it.