TL;DR: AI should not help us rewrite legacy systems faster, it should help us understand them better, modernize them safely, and design stronger architectures for the future.
When developers hear legacy modernization, the conversation often jumps immediately to technology:
- Which framework should replace the old one?
- Should we move to microservices?
- Should we migrate everything to the cloud?
- Can AI convert the codebase for us?
I think that starts the discussion too late.
Before rewriting anything, we should understand what the legacy system actually does.
Legacy code contains business knowledge
A 15 or 20 year-old application contains more than outdated syntax.
It may contain business rules that were never documented, edge cases discovered through years of production incidents, integration behavior other applications depend on and workarounds nobody remembers introducing.
Deleting that code without understanding it can mean deleting business knowledge.
AI makes this discovery process much easier.
It can help:
- Explain unfamiliar code
- Trace dependencies
- Identify duplicated business rules
- Analyze database access
- Document integrations
- Find potentially unused components
- Generate tests around current behavior
The first deliverable of modernization should therefore not necessarily be new code.
It should be:
A map of the existing system.
Code conversion is not modernization
Suppose AI converts an old application into a new language successfully.
- Compilation passes.
- Tests pass.
- The application runs.
Have we modernized it? Maybe not.
If we preserved the same tight coupling, shared database, unclear domain boundaries and problematic dependencies, we have simply moved technical debt into a newer stack.
We created:
A modern implementation of an outdated architecture.
The problem is not whether AI can generate the replacement code.
Increasingly, it can.
The difficult question is:
What architecture should that code implement?
Find business boundaries first
Legacy modules frequently represent historical technical boundaries rather than real business boundaries.
Imagine a module named:
CustomerManagement
Inside it we might discover:
- Customer onboarding
- Customer identity
- Contracts
- Preferences
- Notifications
- Billing integration
These capabilities may not belong together in the future architecture.
Some may need independent scaling.
Some may have stronger security requirements.
Some may change frequently while others remain stable.
Some may belong to completely different teams.
AI can help discover these relationships by analyzing code, APIs (Application Programming Interfaces), databases and terminology.
But it should support architectural discovery, not replace architectural judgment.
Migrate incrementally
I am also skeptical of Big Bang rewrites.
While the replacement is being built, the legacy application usually keeps changing.
New features arrive.
Regulations change.
Bugs get fixed.
Integrations evolve.
The new platform then spends months trying to catch a moving target.
A safer approach is usually incremental modernization.
The Strangler Fig Pattern is one example:
Legacy System
↓
Legacy + Modern Capabilities
↓
Mostly Modern + Remaining Legacy
↓
Modern Platform
New functionality gradually surrounds and replaces the old implementation.
Instead of one huge migration event, modernization becomes a sequence of smaller architectural decisions.
Use tests as the contract
AI can be particularly valuable here.
Before replacing a component, generate characterization tests around existing behavior.
Then compare the new implementation against those tests.
A simplified workflow becomes:
Existing behavior
↓
Automated tests
↓
Modern implementation
↓
Behavior comparison
↓
Migration
For critical workloads, go further.
Use:
- Shadow traffic
- Feature flags
- Parallel execution
- Output comparison
- Controlled rollouts
- Observability
The objective is evidence, not confidence.
Instead of:
“The rewrite looks correct.”
we want:
“The modern implementation has been validated against real legacy behavior.”
Don't default to microservices
Another modernization trap:
Legacy Monolith → Microservices → Success
Distributed systems introduce their own complexity: networking, observability, data consistency, deployment coordination and operational overhead.
A modular monolith may be a much better modernization target for many applications.
Extract a service when you actually need independent:
- Ownership
- Scaling
- Deployment
- Reliability
- Lifecycle
Not because the word microservice appears on the target architecture diagram.
Data is usually the hard part
Application code can be replaced relatively quickly.
Data cannot.
A legacy database may simultaneously support applications, reports, integrations and historical processes.
Modernization therefore requires explicit decisions about:
Who owns the data?
What is the source of truth?
Do we migrate or synchronize?
Can old and new applications write simultaneously?
How do we validate migrated records?
AI can help analyze schemas and generate migration logic.
It cannot make unclear data ownership disappear.
The real opportunity
AI changes the economics of modernization.
Understanding code becomes cheaper.
Generating documentation becomes cheaper.
Creating tests becomes faster.
Repetitive transformation work becomes faster.
That allows engineers to spend more time on what matters:
architecture, business understanding, validation, security and system design.
So I don't think the future of legacy modernization is:
Old Code → AI → New Code
I think it is closer to:
Legacy Knowledge
↓
AI-Assisted Understanding
↓
Architecture Decisions
↓
Incremental Transformation
↓
Modern Platform
AI should not help us reproduce the past faster.
It should help us understand the past well enough to design something better.
Further Reading
If you're interested in exploring legacy modernization, incremental architecture and AI-assisted software engineering further, these are excellent resources:
Martin Fowler - Strangler Fig Application / Rewriting Strangler Fig: A foundational perspective on gradually replacing legacy systems instead of relying on risky Big Bang rewrites.
AWS (Amazon Web Services) Prescriptive Guidance - Strangler Fig Pattern: Practical architectural guidance for incrementally decomposing and modernizing legacy applications.
Microsoft Learn - Application Modernization Guidance for Azure: A comprehensive modernization framework covering assessment, planning, modernization strategies, cloud adoption and AI opportunities.
Microsoft Learn - The 6 Rs of Application Modernization: A useful decision framework covering Rehost, Replatform, Refactor, Rebuild, Retire and Retain.
GitHub Documentation - Modernizing Legacy Code with GitHub Copilot: A practical example of using AI to understand legacy code, map data flows, generate tests and progressively modernize an application.
IBM - Generative AI for Application Modernization: An overview of how Generative AI can accelerate application assessment, transformation and modernization programs.
About the Author
Wallace Espindola is a Senior Software Engineer | Solution Architect | AI & Cloud Enthusiast. Passionate about tech.
