Ask anyone who has replaced an old business system what took the longest, and the answer is rarely the programming. It is the weeks at the start, when somebody has to work out what the old system really does.
That step has changed more recently than in all the years before. Here is how we use AI on modernization projects today, what it is good at, and where an experienced person still has to decide.
The part of modernization nobody budgets for
A typical legacy system arrives with no documentation. The developer who wrote it retired, moved on or simply cannot be reached. What remains is the code: tens of thousands of lines of VB6, Access, FoxPro or early .NET, plus a database, plus a folder of reports.
Inside that code are the rules the business runs on. The discount that applies only to three customers. The order status that quietly blocks an invoice. The calculation someone added years ago and nobody has looked at since. Miss one of those in a rebuild and the new system is wrong on its first day.
So a developer used to read the code, screen by screen, for weeks. It was slow, it was dull, and it was the main reason modernization estimates frightened people. We wrote about the general problem in taking over code nobody documented.
What AI does with an old system
AI reads code quickly and does not get bored. Pointed at an old application, it can:
- Read every form, query, report and stored procedure, not a sample of them.
- List what exists: the screens, the tables each one touches, the reports and where their numbers come from.
- Describe the business rules it finds, in plain English.
- Flag the oddities: code that is never called, two routines that do nearly the same job, rules that contradict each other.
What comes out is a map of the system. It is not the truth yet. It is a very good first draft of the truth, produced in days.
From analysis to specification
The map becomes the starting point for the specification, the plain-English document that says what the new system must do. AI helps here too. It turns interview notes and the analysis into a structured draft, and it is remarkably good at asking the awkward questions. What happens when an order is cancelled halfway through? Who is allowed to change a price?
Our analysts edit that draft and the client reviews it. Nothing in it is taken on trust. More on that step on our business analysis page.
Where the developers come in
Everywhere. That is the point people miss about AI in software development.
Our developers check the map against the running system and against the people who use it, because code does not always tell the whole story. Sometimes the rule in the code is a bug everyone has learned to work around. Sometimes the real process happens in a spreadsheet beside the system. Only a person talking to another person finds that out.
When building starts, AI drafts routine code, writes tests and reviews changes. A developer reads all of it, corrects it, and answers for what goes into the client’s system. Think of it as a very fast junior colleague who never tires and is occasionally, confidently wrong. You would not ship that colleague’s work unread. We do not either.
What it still cannot do
- Decide what the business needs. That comes from conversation.
- Judge which of three workable designs will still be sound in ten years. That comes from having built systems since 1987.
- Replace testing. Faster building leaves more time for testing, not less.
- Take responsibility. A developer signs off on every change.
A recent project
A company had run an inventory and purchasing application on desktop PCs for many years. It still worked, mostly. It could not run in a browser, its reports failed regularly with an error number and no explanation, and nobody was left who knew the code.
We used AI to read the old application and its report files and to catalogue what each part did. Sixteen report files turned out to be nine reports that people still ran, which saved rebuilding seven that nobody would have opened. That analysis became the specification, and the client’s staff corrected it where the code and the real process had drifted apart.
The system was rebuilt as a web application on current .NET, with every screen and report checked against the old one. The reading and cataloguing that normally opens a project like this took a fraction of the usual time. The reporting side of the story is on our Crystal Reports replacement page.
What this means if you are sitting on an old system
The usual reason for putting off modernization is the fear of the unknown: nobody can say what is in there, so nobody can say what it will take. That fear is now much easier to remove. A clear account of what your system does can be the first thing you receive, before you commit to rebuilding anything.
We have set out the whole approach on how we use AI, and the options for an aging system on our legacy application modernization page.
If your business depends on software that nobody fully understands any more, that is the conversation to have.
Book a 20-minute call with our CEO, Lance Keene: https://keenesystems.com/booklance
Related: what to do when you inherit code nobody documented.