What you'll take away
Every senior engineer has a legacy system horror story. The monolith that was supposed to be decomposed into microservices three years ago. The Rails application running the core of the business that nobody dares touch because the test coverage is forty percent and the original developers left in 2019. The Java EJB system that still processes ninety percent of revenue because the rewrite project was cancelled after eighteen months and three million pounds.
Legacy modernisation has always been possible. The strangler fig pattern — gradually replacing legacy behaviour with new services, routing traffic incrementally, until the monolith is empty — has been a valid approach since Martin Fowler described it in 2004. The constraint has never been the strategy. It's been the economics: understanding a large legacy codebase well enough to decompose it safely takes enormous senior engineering time that is never available.
AI code assistants have changed that economic equation. Not by writing the new services for you — that's still engineering work — but by dramatically reducing the time required to understand what the legacy code actually does.
The Understanding Problem Is the Real Bottleneck
Before you can strangle a monolith, you need to understand its seams: where are the natural boundaries between domains? Which parts of the codebase are genuinely coupled and which are incidentally coupled? What does a given method actually do in terms of business logic, stripped of all the technical debt?
In a legacy codebase, that understanding lives partly in the code, partly in the heads of engineers who've been working with it for years, and partly nowhere — knowledge that was never written down and was lost when people left. A senior engineer with deep domain knowledge might spend two to three weeks understanding a critical module well enough to safely extract it. AI assistants can compress that to days — not by having domain knowledge, but by being extraordinarily fast at reading and summarising code.
What AI Code Assistants Are Actually Good at Here
- Code archaeology: Asking 'what does this 800-line class actually do?' and getting a structured summary that would take a human hours to produce
- Dependency mapping: Identifying all the places a given function or class is called from, including indirect dependencies that grep would miss
- Business logic extraction: Separating the domain logic from the framework plumbing in tangled legacy code
- Test generation: Writing characterisation tests for legacy behaviour so you have a safety net before refactoring
- Facade generation: Drafting the interface for the strangler facade that will intercept calls to the legacy module
- Migration script generation: Writing data migration scripts between old and new schema representations
The AI-Assisted Strangler Pattern in Practice
Phase 1: Map the Domain Boundaries
Start by using an AI assistant to analyse the entire monolith and identify candidate domain boundaries. Feed it the directory structure, the database schema, and representative samples from each major module. Ask it to map the domains it can identify, the coupling between them, and which modules appear to have the most natural seams. This is not a definitive architecture document — it's a starting hypothesis that your engineers will validate and refine. But it compresses weeks of archaeological work into hours.
Phase 2: Characterisation Tests
Before touching any legacy code, build characterisation tests: tests that document current behaviour rather than specified behaviour. These tests don't assert that the system does the right thing — they assert that it continues to do whatever it currently does. If the legacy code has a bug that downstream systems depend on, the characterisation test captures that dependency. AI assistants are remarkably good at generating characterisation tests: feed them the code and ask for tests that exercise each code path, including the error cases and edge conditions.
Legacy code is a tax you pay every sprint
48-hour turnaround. No obligation.
Phase 3: Strangle Module by Module
Select the first module to extract based on a combination of business value (the domain you most need to modernise or scale independently) and coupling density (start with the module that has the fewest inbound dependencies). Build the strangler facade — a thin routing layer that intercepts calls to the legacy module and can redirect them to the new service once it's ready. Use AI to draft the facade interface and the new service scaffold, then fill in the business logic yourself.
The strangler pattern only works if you have characterisation tests before you begin. Teams that skip this step and rely on 'we'll know it's broken if production alerts fire' end up with subtle regressions that surface weeks after the extraction — by which point they're nearly impossible to diagnose.
What AI Can't Do in Legacy Modernisation
AI assistants are good at reading code and synthesising what it does. They are not good at knowing whether what it does is correct — they have no access to the business context, the stakeholder requirements that shaped the original implementation, or the institutional knowledge of why a seemingly strange piece of code works the way it does. The AI will confidently tell you what a method does. It won't tell you whether it should do that. That distinction is what senior engineers are for.
They're also unreliable for large-scale generation of production-quality code. Characterisation tests, facade stubs, migration script scaffolds — these are tasks where the AI accelerates the work to a point where an engineer reviews and finalises it. Using AI to write the entire new service without deep engineering review is where modernisation projects go wrong.
The Economics of AI-Assisted Modernisation
The projects where we've seen the most leverage from AI-assisted modernisation are the ones where understanding the legacy system was the primary bottleneck. When a senior engineer who would have spent three weeks reading legacy code can instead spend three days reviewing AI-generated summaries and asking follow-up questions, the time-to-confident-extraction compresses dramatically. On a codebase of five hundred thousand lines, that difference compounds: the total modernisation timeline for a twelve-module decomposition shrinks from two years to nine months.
GYSP's Custom Software Development practice has executed AI-assisted modernisation projects for enterprises whose legacy systems were blocking digital transformation. The pattern is consistent: the acceleration is real, but it requires senior engineers who know how to use AI tools in ways that produce trustworthy outputs, not junior developers using AI to avoid reading the code.
“AI doesn't make legacy modernisation easy. It makes the hardest part — understanding what the legacy system actually does — dramatically faster. What you do with that understanding still requires engineering judgement.”
— Rahul, AI/ML Delivery Head — GYSP.tech
