Legacy System Modernisation with AI
Using AI to understand a system nobody fully understands any more — extracting the business rules, generating the characterisation tests, and migrating incrementally rather than attempting the rewrite that has already failed twice.
The problem with a thirty-year-old system is not the language it is written in. It is that the behaviour was never written down, the people who knew it have retired, and the business depends on rules that exist only as code nobody dares change. AI is genuinely useful here, and it is useful for comprehension rather than for translation.
AI-assisted legacy modernisation applies language models to understanding an existing system — mapping its structure, extracting the business rules embedded in its code, and generating tests that characterise its current behaviour — so that incremental migration can proceed with evidence rather than with archaeology.
Where AI genuinely helps, and where it is dangerous
| Task | AI contribution | Required verification |
|---|---|---|
| Mapping structure and dependencies | High. Fast and reliable across large codebases | Spot-checked against the running system |
| Explaining what code does | High. Turns unreadable code into readable description | Reviewed by whoever still knows the system |
| Extracting business rules | High value, medium reliability | Every rule validated by a business owner |
| Generating characterisation tests | High. Tests run against the real system and prove themselves | The test passing is the verification |
| Writing documentation | High, given verified inputs | Reviewed like any other document |
| Translating code to a new language | Low. Produces plausible code with subtle behaviour changes | Full behavioural equivalence testing |
We do not do automated code translation as a strategy
Language models produce syntactically convincing translations that differ from the original in ways nobody notices until a quarter-end run. The value here is comprehension — understanding what the system does so a proper migration can be planned — not a machine-generated rewrite that has to be verified line by line anyway.
How the work runs
Map the system as it is
Modules, dependencies, data flows, entry points, batch jobs and integrations, derived from the code rather than from documentation that stopped being accurate in 2011. The map alone frequently changes the plan, because it reveals dependencies nobody had accounted for.
Extract business rules and get them validated
Conditions, thresholds, calculations and exceptions surfaced from the code and presented in business language. Every rule goes to a business owner for validation, and the ones nobody can justify are as valuable a finding as the ones they confirm — a meaningful share turn out to be obsolete.
Generate characterisation tests
Tests that capture what the system currently does, right or wrong, run against the real system. These are what make change safe, and they verify themselves: a test that passes against the existing system is describing real behaviour, whatever produced it.
Find the dead code
Paths that have not executed in years. Establishing this with runtime evidence rather than static analysis alone routinely removes a large fraction of what would otherwise have been migrated.
Migrate incrementally, behind a facade
New functionality built alongside, traffic moved gradually, the old system shrinking. The full rewrite is the approach with the worst record in this industry, and it is usually attractive for reasons that do not survive the second year.
Modernise the data alongside
The data model is normally as much of the constraint as the code, and it moves on its own track. See legacy data migration and modernisation.
What we hand over
- A verified system map that reflects the code as it runs, not as it was documented.
- A validated business rule catalogue, in business language, with the obsolete rules identified and the owner named for each.
- A characterisation test suite that passes against the current system and makes future change safe.
- A dead code report backed by runtime evidence, reducing the migration surface.
- A sequenced migration plan using the strangler pattern, with the facade and cutover points defined.
- Whatever was migrated in this engagement, running in parallel and reconciled before cutover.
The first three are valuable even if migration is deferred, which is why they come first. An organisation that understands its legacy system has options; one that does not has only the rewrite it cannot afford.
How the engagement runs
Comprehension is delivered and validated before any migration is attempted.
Comprehension
Structure, dependencies and data flows mapped from the code; runtime evidence gathered on what actually executes.
Rule extraction and validation
Business rules surfaced and taken to business owners; obsolete rules identified and agreed.
Characterisation tests
Tests generated and run against the real system until current behaviour is captured.
Migration plan
Strangler sequence, facade design, cutover points and rollback defined and costed.
First increments
Priority functionality migrated, run in parallel, reconciled and cut over.
What you receive
Understanding first, then incremental migration — never a rewrite dependent on a machine translation.
System map
Modules, dependencies, data flows, entry points and integrations, derived from code and spot-checked.
Business rule catalogue
Rules in business language, validated by owners, with obsolete ones identified.
Characterisation test suite
Passing against the current system, making subsequent change safe.
Dead code report
Paths not executed, evidenced at runtime, with the migration surface reduced accordingly.
Migration plan
Strangler sequence with facade design, cutover points, rollback and cost per increment.
Migrated increments
Priority functionality delivered, run in parallel and reconciled before cutover.
Is this the right engagement?
Worth being direct. Legacy System Modernisation with AI is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- A critical system is understood by very few people, or none.
- Change is avoided because nobody can predict what will break.
- A previous rewrite attempt stalled or was abandoned.
- The business rules exist only in code and need to be recovered.
- The platform is out of support or the skills are unobtainable.
Choose something else if
- The system is well documented and adequately tested already.
- A replacement product has been selected and the requirement is data migration. See data migration.
- You want an automated code translation, which we do not offer as a strategy.
- Nobody in the business can validate extracted rules, which leaves them unverifiable.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Can AI rewrite our legacy system automatically?
No, and treating it as though it can is how these projects fail expensively. Language models produce plausible translations that differ from the original in ways nobody notices until a quarter-end run. The genuine value is comprehension — mapping the system, extracting the rules, generating characterisation tests — so that a proper incremental migration can be planned.
How reliable are AI-extracted business rules?
Useful enough to be worth doing and not reliable enough to be trusted, which is why every rule is validated by a business owner before it enters the catalogue. The extraction turns months of archaeology into weeks of review, and the review is not optional.
What are characterisation tests and why do they matter?
Tests that capture what the system currently does, correct or not, so that any change can be checked against existing behaviour. They are the thing that makes a legacy system safe to modify, and they verify themselves — a test that passes against the running system is describing real behaviour regardless of how it was written.
Should we rewrite or migrate incrementally?
Incrementally, in almost every case. The full rewrite has the worst track record in this industry: it takes longer than planned, the old system keeps changing underneath it, and the cutover is all-or-nothing. The strangler pattern — new functionality alongside, traffic moved gradually — is slower to feel dramatic and far more likely to finish.
What if we do not migrate at all after this?
You still hold the system map, the validated rule catalogue and a characterisation test suite, which is a substantially better position than before: the system becomes safe to change and possible to staff. Several clients stop there deliberately, and that is a legitimate outcome rather than a failure.
Often paired with this
Most clients combine two or three engagements from the AI Integration and Process Automation pillar. These are the ones that most often run immediately before or after.
RPA Modernisation with AI
An honest robot-by-robot audit: retire, re-platform onto APIs, or extend with AI where judgement is needed.
Read more →AI API and Middleware Development
A versioned, authenticated, rate-limited service layer so many applications can consume AI safely and cheaply.
Read more →Internal Knowledge Management AI
Answers across your internal systems with source, date and permissions respected — and stale content actively removed.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.