Why AI alone won’t modernize your legacy system

The lure of an easy fix for legacy code is hard to resist. Over the past couple years, many leaders have been asking a reasonable question: If large language models (LLMs) can write code, can they read an old codebase and convert it into a modern application with minimal human effort? On the surface, it seems like the perfect solution. But, in practice, automated end‑to‑end modernization tools don’t exist. Modernization remains a human‑centred, multi‑disciplinary undertaking that benefits from using AI pragmatically in specific, well‑scoped tasks rather than as an autonomous solution.

Six reasons why the “auto‑modernize” tool doesn’t exist

1. Legacy systems are more than code

Code is only one expression of decades of policy, process, and institutional memory. Rules often live in SQL, batch jobs, scheduled tasks, and spreadsheet macros. They live in the heads of long‑tenured staff. An AI that converts syntax will happily reproduce behaviours it does not understand, including the undesirable ones.

In a previous project with a Canadian provincial court system, we discovered their judicial system was layered with fragmented logic—each layer only ever captured some of the business rules, often incompletely or inconsistently. What wasn’t encoded in COBOL, APIs, stored procedures, batch jobs, and reporting tools was left to clerks and regional practices, creating a patchwork where institutional memory filled the gaps. Each system layer and regional variation meant that no single codebase ever fully represented the criminal code policy or process.

2. Requirements are entangled and often undocumented

Long‑running systems accumulate business rules through urgent fixes and one‑off exceptions. Those rules rarely match any surviving documentation. A faithful conversion risks baking historical drift into the future state. A safe modernization effort requires discovery, validation with real users and staff, and conscious decisions about which behaviours to keep, change, or retire.

3. Architectures don’t have one‑to‑one mappings

A monolith built on a three‑tier pattern, on‑premise schedulers, and direct database access cannot be “translated” line‑for‑line into today’s service‑oriented, event‑driven, and cloud‑secure reality. Think of it like trying to convert a factory assembly line into a network of independent workshops: you can’t just move the machinery as-is; you have to rethink how work flows, how pieces fit together, and how safety checks are done. Boundaries, protocols, deployment models, observability, and risk treatments would need to change. Those are design decisions, not code transformations. AI can translate some languages and propose partitions, but it does not decide service boundaries, data contracts, or the target runtime on its own.

4. Data and integration risks dominate

Most modernization risk sits at the seams: data models, quality, and integrations with upstream and downstream systems. Problems like mismatched formats, duplicated identifiers, and unspoken rules about how data is handled often only show up when you move real data between real systems. No automated tool can guarantee that information will flow accurately and securely without people testing, making trade-offs and confirming that everything works as expected.

5. Non‑functional requirements are first‑class

Security, privacy, accessibility, performance, operability, and compliance don’t emerge from code conversion tools. They are designed, implemented, and demonstrated. Even the best AI‑assisted code must be threat-modelled, load-tested, and observed with real user testing before it earns trust.

6. Change isn’t just technical, it’s social

Modernization often reshapes roles, daily routines, and even incentives. AI can’t identify these adoption risks and a change management strategy is required. Success depends on how well teams prepare for that shift: leadership buy-in, clear communication, training, staged rollouts, and maintaining continuity of service. While AI tools can help deliver the new system, only people can lead the change.

So, where does AI actually help?

As Gordon Ross notes in Does more code, faster, translate into better quality code?, speed gains from AI coding assistants can hide long-term, systemic cost. This is why we keep AI inside tight loops with feedback, while people make the architectural decisions.

AI is excellent when the task is small, the context is tight, and the feedback loop is fast. AI can be used to:

• accelerate reading unfamiliar code, surfacing where key rules live;
• draft unit tests for critical paths, so humans can expand and harden them;
• suggest refactors in well‑isolated modules, making legacy code more testable;
• generate first‑pass documentation that experts correct and endorse;
• propose test data, migration scripts, and checklists that engineers validate.

This is collaborative intelligence. Humans decide what “good” looks like, what’s safe to change, and how to stage the work.

A pragmatic path: human‑centred modernization with AI in the loop

The outline below reflects our experience in modernizing systems across public and private sector organizations. It keeps the organization in control, limits risk, and creates space for AI to contribute without taking the wheel.

1. Start small with a pilot

Pick a self‑contained slice of functionality that matters to users, touches authentic data, and exercises at least one integration. Success criteria should include an outcome beyond “it compiles,” such as completing a user task more quickly or streamlining the steps involved.

2. Gather and generate working knowledge

Collect what exists. Policies, procedures, architecture diagrams, access logs, and any source code. Load only non‑sensitive documents into your AI workspace. Ask AI to summarize flows and surface open questions for humans to verify.

Generate where gaps exist. If documentation is thin, use AI to draft candidate requirements extracted from code and UI behaviour. Treat these as hypotheses. The project team can then confirm the truth with users and operational staff.

3. Validate with users

Use standard research practices to test with users. Run quick, moderated sessions with frontline staff and service users to confirm tasks, rules, and edge cases. Iterate language and flow. Expect surprises. Capture them as explicit decisions.

4. Choose a target architecture knowingly

Choose your architecture with care, weighing options such as cloud or on‑premise, managed services or custom, message queues or HTTP, relational or document store. Align with enterprise constraints. Document the security model early, including identity, access, logging, and audit.

5. Migrate by strangling, not by rewrites

Favour incremental techniques such as the Strangler pattern and self‑contained systems. This approach means building a controlled connection between the old and new systems so they can work together without conflict. At first, only a small, low-risk part of the workload is shifted to the new system to test stability. Once it’s proven reliable, more functions are gradually moved. This step-by-step process lowers the risk of major disruptions and steadily builds confidence in the new system.

6. Design for testability, then automate

Before you write new code, decide how you will know it works. Use AI to draft unit tests and scaffolding, then have engineers complete, run, and interpret them. Build contract tests for each integration. Add automated testing for the user’s happy path.

7. Plan service continuity

Map cutover, fallbacks, and rollback triggers. Schedule staged releases around the calendar realities of your organisation. Communicate with users and support teams well before anything changes. Treat communications as part of the product.

Putting it together: a simple, staged plan:

1. Pilot a meaningful slice with real users and data. Define outcomes.
2. Document what’s true today, using AI for summaries and gap lists. Humans validate.
3. Co‑design the target experience with users and operational staff.
4. Select an architecture and security model, in writing.
5. Build the first slice behind an anti‑corruption layer. Use AI for tests and refactors, not for end‑to‑end generation.
6. Release in stages, observe, and expand.
7. Repeat until legacy capabilities are fully retired.

The bottom line

There is no end‑to‑end tool that will modernize a legacy application without human involvement. Modernization is a disciplined, iterative effort that blends service design, engineering, security, and change management. Generative AI belongs in that effort as a helper inside tight feedback loops. It will make good teams faster, documentation clearer, and refactors safer. It won’t make the hard decisions for you, and it won’t carry the operational risk on your behalf.

If you are facing a legacy system that your organization has outgrown, start small, prove value, and expand with care. Bring AI along as a partner, not a pilot.