The greatest risk in a legacy rewrite is not reproducing the software. It is accidentally deleting the business behaviour the organisation forgot the software contains.
Teams often approach modernisation as a stack problem: replace an old language, move to cloud infrastructure, introduce APIs, consolidate databases, modernise the front end. Those changes may all be necessary. They are not sufficient. The legacy platform has usually become an undocumented repository of business rules.
Why the specification is often incomplete
A mature system accumulates behaviour through thousands of small changes. A tariff exception was added for one customer type. A dispatch rule changed after an operational incident. A regional team introduced a data workaround. A report became the unofficial reconciliation process. A database trigger enforces something nobody remembers requesting.
The current requirements document, if one exists, normally describes only part of that reality. The true specification is distributed across code, schemas, batch jobs, interfaces, support tickets, operating procedures and the knowledge of long-serving staff.
This is why a direct rewrite from old code to new code can be dangerous. The team may faithfully reproduce technical structure while misunderstanding which behaviours are deliberate, obsolete or accidental.
Treat modernisation as evidence reconstruction
I prefer a discovery model that triangulates five sources: code behaviour, data behaviour, interface behaviour, operational practice and business intent. A rule is not considered understood because it appears in one place. It is compared across sources.
For example, if legacy code applies a surcharge under a particular condition, the team should ask: is that rule visible in current pricing policy? Does the data show it is still exercised? Do operations rely on it? Is it duplicated in another service? Should it exist in the target state?
That process turns archaeology into design.
Where generative AI genuinely helps
Legacy estates contain too much material for people to read line by line. AI can accelerate the evidence work by summarising modules, identifying duplicated logic, generating call graphs, explaining data transformations, clustering similar rules, drafting documentation and suggesting test cases.
The critical word is evidence. The model should point the team back to code, data and artefacts. It should not be allowed to “fill in” undocumented business rules because the output sounds plausible.
A useful pattern is: AI proposes an interpretation, a human engineer validates the technical behaviour, a business analyst or domain expert validates the business meaning, and tests capture the confirmed rule. The resulting artefact becomes part of the modernisation baseline.
Consolidation makes the problem more difficult
When several regional or business-unit implementations are being consolidated, there may be multiple versions of the same rule. The programme has to decide whether differences are legitimate policy variations, historical drift or local customisation that can now be removed.
This is an operating-model decision, not a code-merging decision. The target platform should not automatically preserve every difference simply because it exists. Nor should the programme standardise everything for architectural elegance if local variation is commercially or operationally required.
Create a rule register before you create false confidence
A practical rule register contains the rule, source evidence, owner, affected process, implementation location, test coverage, target-state decision and confidence. This creates a bridge between discovery, architecture and delivery.
It also improves estimation. Once the programme knows how many rules are being retained, changed, consolidated or retired, it can estimate migration and test effort with far more credibility than a percentage-based “reuse” assumption.
Modernisation is complete when the organisation understands the new system
The real success metric is not that the old language has disappeared. It is that the organisation has moved from implicit behaviour to explicit, testable and governable behaviour. The target system should be easier to reason about than the one it replaces.
- Can we trace important business rules from policy to implementation and test?
- Do we know which regional differences are intentional?
- Have hidden batch, report and database behaviours been included in discovery?
- Are AI-generated interpretations linked back to source evidence?
- Is the target architecture removing accidental complexity rather than merely translating it?
That is the difference between a technology rewrite and a genuine modernisation.
Build a rule inventory before you build the replacement
Legacy modernisation often begins with a technical inventory—programs, tables, interfaces and batch jobs. I add a business-rule inventory. For each important behaviour, record the rule, the evidence for it, where it is implemented, who can validate it, whether it is still required and how confident the team is. Some rules will be explicit in code. Others will only become visible when users explain why they correct a record manually every Friday or why one regional instance behaves differently from another.
This inventory changes the migration conversation. Instead of asking whether the new application has feature parity, the team can ask whether each retained business obligation has an intentional implementation. It also gives the programme a controlled way to retire obsolete behaviour rather than accidentally reproducing decades of history.
Use AI to accelerate evidence gathering, not to invent intent
Large language models are genuinely useful for navigating unfamiliar codebases: summarising functions, tracing call paths, grouping similar logic, proposing documentation and identifying likely dependencies. They can compress weeks of reading. But a generated explanation of code is still evidence to be checked. The model cannot know that a strange condition was introduced after a regulatory change unless that context exists in the evidence available to it.
In a multi-instance consolidation, I would therefore compare generated rule candidates across instances, test them against production data patterns and have domain experts adjudicate differences. The output becomes a decision register: common rule, local variation, obsolete rule, unresolved rule. That is a much stronger foundation for a single target platform.
Modernisation success is behavioural equivalence where it matters
The replacement does not need to reproduce every screen or every implementation technique. It does need to preserve the behaviours that protect revenue, customer commitments, regulatory obligations and operational continuity. Framing the work this way gives architecture teams freedom to modernise while giving executives confidence that the organisation is not throwing away hidden business knowledge.
