DEV Community

Marc Newstead
Marc Newstead

Posted on

Using AI to Map Legacy Code Without Rewriting Everything

#ai #legacy #softwareengineering #devops

Using AI to Map Legacy Code Without Rewriting Everything

If you've ever inherited a fifteen-year-old Java monolith or been asked to "modernise" a COBOL system that's been running since before you were born, you know the real problem isn't the code itself — it's understanding what the hell it actually does.

The business logic is tribal knowledge. The original developers have long since moved on. The documentation, if it exists at all, is either outdated or actively misleading. And yet, this code is mission-critical.

This is where AI tooling is starting to show genuine value — not by magically rewriting everything (please don't), but by making legacy systems legible enough to modernise incrementally.

The Documentation Gap Is What Actually Kills You

Let's be honest: the blocker on most legacy migrations isn't technical complexity. It's the fact that nobody knows what the code is supposed to do.

You've got thousands of lines of procedural COBOL or deeply nested Java that's been patched and extended for decades. Business rules are embedded in the code itself. There are no tests. The person who understood the invoice calculation logic retired in 2012.

Traditionally, you'd need to:

  • Reverse-engineer the business logic by reading code
  • Interview subject matter experts (if they still exist)
  • Run the system with test data and observe outputs
  • Document everything manually

This takes months. And it's boring, error-prone work that nobody wants to do.

Enter AI-Assisted Mapping

Modern LLMs (GPT-4, Claude, even specialised models) can:

  • Parse legacy code and generate plain-English summaries of what functions do
  • Trace data flows across modules
  • Identify dependencies and side effects
  • Suggest which components are safe to decouple

Here's a simple example. You've got a 500-line stored procedure that calculates something financial. You feed it to an LLM:

-- Legacy stored procedure from 2005
CREATE PROCEDURE calculate_customer_discount
  @customer_id INT,
  @order_total DECIMAL(10,2)
AS
BEGIN
  -- 500 lines of nested IF statements
  -- and undocumented business rules
END
Enter fullscreen mode Exit fullscreen mode

You prompt:

"Summarise what this procedure does, list all business rules, and identify external dependencies."

The output won't be perfect, but it gives you a starting point that would've taken hours of manual analysis. You can then:

  • Validate the summary with a domain expert
  • Use it as documentation for the replacement service
  • Identify edge cases that need testing

This approach is already being used across UK enterprises — financial services and public sector teams are documenting legacy systems at a pace that simply wasn't feasible before. For a broader view on how organisations are tackling this, see this pragmatic guide for UK enterprises.

Strangler-Fig with AI: Incremental Wins

The strangler-fig pattern is still the safest way to modernise: you build new services alongside the old system, gradually routing traffic over, until the legacy code can be retired.

AI tools can act as a co-pilot here:

  1. Identify bounded contexts — which chunks of the monolith can be safely extracted?
  2. Generate interface contracts — what inputs and outputs does this component expect?
  3. Scaffold replacement services — create boilerplate for new microservices based on analysed legacy behaviour
  4. Compare outputs — run both old and new implementations in parallel and flag discrepancies

You're not trusting the AI to do the work unsupervised. You're using it to speed up the tedious parts so you can focus on the hard decisions: architecture, trade-offs, risk.

Where AI Breaks Down (and You Still Need Humans)

Let's be clear: LLMs don't understand your business logic. They pattern-match. They hallucinate. They'll confidently give you plausible-sounding nonsense.

Don't use AI for:

  • Final architectural decisions — a human needs to own that
  • Validating business-critical logic — always verify with domain experts
  • Security-sensitive code — treat AI output as untrusted input
  • Anything without code review — hallucinations are real and dangerous

AI is a documentation accelerator and a mapping tool. It's not a replacement for engineering judgement.

Practical Takeaways

If you're staring down a legacy modernisation project:

  • Start with documentation, not code replacement — use AI to map what exists before you change anything
  • Validate everything — treat AI output as a first draft, not gospel
  • Focus on knowledge capture — the real value is making implicit knowledge explicit
  • Use AI for boring, repetitive analysis — free up your team to solve actual problems

Legacy systems aren't going away. But with the right tooling and a pragmatic approach, you can make them understandable — and that's half the battle.

If your team is exploring how AI fits into modernisation work, agencies specialising in AI automation and software development can help structure these programmes without the hype.

What's your experience with legacy code and AI tooling? Have you used LLMs to document or analyse old systems? Let's hear it in the comments.

Top comments (0)