Most organisations we speak to are running at least one system that everyone is afraid to touch: a monolith written a decade or two ago, thin on tests, thinner on documentation, and dependent on two people who know where the bodies are buried. It still makes money, which is precisely why replacing it is so hard.
What changed in the last two years is not the strategy, which remains incremental, but the economics of the hardest part: understanding the old code. Large language models can now read, summarise and cross-reference legacy codebases far faster than a new team can. Used well, that shortens discovery and lowers risk. Used carelessly, it produces confident translations of code nobody understood in the first place. Here is the playbook we use at RixlSoft.
Start with outcomes, not technology
Modernization is expensive, so it has to be justified by something the business cares about: faster release cycles, lower run costs, retiring an unsupported platform, reducing security exposure, or unlocking data for analytics and AI. Write these down with a baseline. If you cannot say what will be measurably better in twelve months, you are not ready to start.
Then map the estate. For each application, capture business criticality, rate of change, technical health and dependencies. The classic options still apply: retain, rehost, replatform, refactor, rebuild or retire. It is common to find that a meaningful share of the portfolio can simply be retired or consolidated, which is the cheapest modernization there is.
Be explicit about the operating model too. A modernization programme needs a product owner with authority to make trade-offs, a small platform team building shared foundations, and domain-aligned delivery teams that own each migrated capability end to end. Without that structure, programmes drift into an endless technical exercise that the business stops funding.
Use AI to understand the system before changing it
The biggest time sink in legacy work is discovery. We now pair engineers with AI tooling to accelerate it. Models are indexed over the codebase, database schema, job schedules and whatever documentation exists, and engineers use them to answer targeted questions: where is this business rule enforced, what writes to this table, which batch jobs depend on this file.
The output of this phase is not generated code. It is a living knowledge base: capability maps, data lineage, sequence diagrams for critical flows, and a catalogue of business rules with references back to the source lines. Every AI-generated claim is verified by an engineer against the code or by running it, because models can and do hallucinate plausible behaviour.
- Generate module-level summaries and dependency graphs, then have engineers correct them.
- Extract business rules into plain language and confirm them with domain experts.
- Produce characterisation tests that capture current behaviour, including its quirks.
- Flag dead code, duplicated logic and undocumented integrations for triage.
The strangler fig pattern, applied properly
The strangler fig pattern remains the safest default for anything critical. You put a routing layer, often an API gateway or reverse proxy, in front of the legacy system, then peel off one capability at a time into a new service. Traffic for that capability moves to the new implementation, the old code path is retired, and you repeat. At every point the business has a working system.
Two details make or break it. First, choose seams well: start with capabilities that are relatively self-contained, frequently changed and valuable, rather than the most tangled core. Second, invest early in the facade and the anti-corruption layer that translates between old and new data models, so the new services do not inherit the legacy design. Run old and new side by side with shadow traffic or parallel runs, compare outputs automatically, and only cut over when the diff is clean.
Data migration is the real project
Teams consistently underestimate data. Legacy databases contain decades of edge cases: nullable fields that are never null except when they are, codes whose meaning changed in 2011, and records only valid under rules that no longer exist. Plan data work as a first-class workstream, not a weekend task before go-live.
Profile the data early, agree target models with the business, and build repeatable, automated migration pipelines rather than one-off scripts. Where both systems must run concurrently, use change data capture to keep them in sync and make reconciliation reports part of every rehearsal. We aim for at least two full dress rehearsals of any cutover, with timing, validation and rollback all tested.
- Profile volumes, quality and anomalies before designing the target schema.
- Automate migration and reconciliation so every run is repeatable.
- Use change data capture for coexistence periods instead of dual writes from application code.
- Define rollback criteria and a tested rollback procedure before cutover day.
Where AI-assisted code generation fits
AI coding assistants are genuinely useful in modernization, within limits. They are strong at translating well-understood, well-tested routines, writing boilerplate for new services, generating test scaffolding, and upgrading frameworks or language versions across many files. They are weak at inferring intent from ambiguous code and at making architectural decisions.
Our rule is simple: generate only against a safety net. Characterisation tests must exist before code is translated, and the translated code must pass them. Human review focuses on behaviour, security and design rather than syntax. Line-by-line translation of a monolith into a new language without redesign mostly gives you the same problems in a newer syntax.
Governance matters as well. Decide which code and data may be sent to which AI services, prefer enterprise agreements that exclude your code from model training, and keep secrets and customer data out of prompts. Log which changes were AI-assisted so reviewers know where to look harder. None of this slows teams down much, and it avoids uncomfortable conversations with security and legal later.
Sequencing and managing risk
A realistic programme sequences work in waves. Wave zero builds the foundations: CI/CD, observability, a cloud landing zone, the routing facade and the knowledge base. Wave one migrates two or three low-risk but visible capabilities to prove the pattern and the team. Later waves take on progressively more central domains, with the database core usually last.
Keep the risk register honest. The common failure modes are well known: scope creep into redesigning every process at once, feature freezes that last too long and erode business support, key-person dependency on legacy experts, and cutovers without rehearsal. Short waves, visible wins, parallel running and an explicit decommissioning plan for each retired component keep momentum and trust. Modernization is finished not when the new system launches, but when the old one is switched off.
Key takeaways
- Tie every modernization to measurable business outcomes with a baseline.
- Use AI to accelerate understanding, and verify every claim it makes against the code.
- Strangle the monolith capability by capability, with parallel runs and automated diffs.
- Treat data migration as its own workstream with automated reconciliation and rehearsed cutovers.
