The most dangerous legacy system is the one you don’t fully understand

If a critical application failed tomorrow, could you explain who depends on it, which rules it enforces, what data it moves - and what would break if you changed it?

If the answer to any part of that question lives only in one person’s head, an old diagram or a supplier’s memory, you do not have a complete system map. You have a dependency disguised as knowledge.

That may be the most consequential form of legacy risk. The oldest platform is not always the most dangerous. The most dangerous is the one that matters to citizens and staff yet is only partially understood.

Legacy risk starts with an unanswered question

The 2025 State of digital government review estimated that 28% of systems in central government departments were classified as legacy in 2024. More troublingly, it found that most public-sector organisations did not have comprehensive registers or a quantified view of the legacy risk they carried.

So, the immediate question is not simply, “How much legacy do we have?” It is, “How confident are we that we know?”

Legacy applications rarely stand still. Policy changes become conditional logic. Temporary integrations become permanent. Data structures evolve while documentation falls behind. Exceptions accumulate because real services must cope with real life. Then experienced colleagues move on; suppliers change and the rationale for yesterday’s decision disappears.

The result is a widening gap between what an organisation needs to know to change a service safely and what it can recover through conventional interviews, workshops and manual code review. We call this the comprehension gap.

AI changes the economics of understanding

Traditional discovery remains essential, but it is expensive to begin with a blank page. Modern AI tools can analyse large collections of approved legacy artefacts - source code, database schemas, configuration, interface definitions, test suites, tickets, support guidance and process documents - and assemble a first-pass account of how a service appears to work.

Used well, that can produce a useful evidence pack much earlier in discovery:

• an application and dependency inventory;

• candidate business rules and exceptions;

• data flows, entities and likely ownership boundaries;

• service journeys and operational hand-offs;

• tests that capture existing behaviour; and

• questions, contradictions and evidence gaps for users, engineers and subject-matter experts to resolve.

This is not just faster documentation. It changes the quality of the conversation. Instead of asking a subject-matter expert to reconstruct twenty years of service behaviour from memory, a team can put a traceable rule catalogue, dependency map or prototype in front of them and ask: “Where is this wrong? What is missing? Which exception matters most?”

People are usually better at critiquing something concrete than narrating a complex system from scratch. AI gives discovery something tangible to challenge.

An AI-generated map is not the territory

The danger is replacing one form of false confidence with another. A fluent explanation can still be incomplete or wrong. Code may describe behaviour that is no longer used. Documentation may describe behaviour that was never implemented. Logs may show what happened without explaining why.

Every AI-generated finding should therefore carry its provenance: the file, schema, record, log pattern or document from which it was inferred. It should also carry a confidence level and a clear route to validation.

The objective is not automated discovery. It is augmented discovery: machines accelerate the reconstruction of evidence; people test it, interpret it and remain accountable for the decisions.

What disciplined AI-assisted discovery looks like

Set the boundary before selecting the model

Agree which service, repositories, data classes and environments are in scope. Identify secrets, live personal data and operationally sensitive material before analysis begins. The data classification and threat model should determine where processing can happen and which tools are acceptable - not personal preference or novelty.

Build an evidence base, not a document dump

Prepare approved artefacts in a consistent, searchable form. Preserve links back to source. Record versions, ownership and date. Then use AI to extract candidate rules, dependencies and contradictions. This creates a living evidence base that can evolve through discovery and delivery, rather than a report that starts becoming stale as soon as it is published.

Use more than one analytical lens

Different models and methods notice different things. We use Claude and OpenAI tools as practical analysis assistants: navigating unfamiliar codebases, comparing code with documentation, surfacing likely business rules, drafting behavioural tests and translating technical findings into artefacts that non-technical experts can challenge.

Where useful, we compare results across models and against deterministic analysis such as static code scanning, schema inspection and automated tests. Model plurality is not complexity for its own sake; it is a check against false confidence.

Put enterprise controls around the work

Microsoft technologies provide a familiar enterprise foundation for identity, access, secure cloud engineering, monitoring and integration with the wider delivery environment. Depending on the client’s constraints, that may include Microsoft Azure, Azure AI Foundry and Azure OpenAI, Entra ID, Key Vault, Azure Monitor and established DevOps controls.

The practical point is not that one vendor is always right. It is that model choice, hosting pattern and workflow should be matched to the information being analysed and the assurance required. Claude, OpenAI and Microsoft capabilities can be combined where approved; for more sensitive workloads, private or on-premise options may be the right answer.

Validate with the people who run and use the service

Engineers test technical findings. Service owners and policy experts validate business rules. Frontline staff expose workarounds and edge cases. Users reveal whether the old behaviour is meeting their needs. The team records what is known, assumed and still unknown - and who owns the next piece of evidence.

Decide what deserves to survive

Once the service is understood, modernisation becomes a set of deliberate choices. Preserve capabilities that still create value. Improve those that frustrate users or staff. Retire obsolete behaviour and unnecessary complexity. Introduce new capabilities only where they serve a validated need.

AI should not make those decisions. It should make the evidence behind them clearer.

Security is not an appendix

Legacy discovery can expose source code, architecture, configuration, data models and business logic. In public services, those artefacts may be sensitive even when they contain no personal data. A credible approach must make the controls visible from the start.

• Classify and minimise: remove live records, credentials and unnecessary sensitive content; analyse only what the agreed question requires.

• Control access and egress: use enterprise identity, least privilege, multi-factor authentication, managed secrets, restricted network routes and auditable environments.

• Verify provider terms: where external model services are approved, check the actual retention, training, processing-location and support-access terms for the chosen service and configuration. “Enterprise” is not, by itself, a security control.

• Treat outputs as untrusted: require traceability, peer review, testing and standard security scanning before any artefact informs delivery or enters a codebase.

• Threat-model the discovery process: include prompt injection, malicious or compromised artefacts, dependency risk and the possibility that generated analysis omits a critical exception.

• Close access cleanly: revoke temporary permissions, rotate credentials, archive agreed evidence and delete working data in line with the client’s retention policy.

These controls do not slow the work down. They make it possible for security, information governance and delivery teams to trust the method - and to repeat it across an estate.

The leadership question is no longer whether AI can read old code

It can. The more important question is whether your organisation is ready to turn that capability into governed, validated knowledge.

Could you answer these questions today?

• Which critical services depend on each application - and what is the citizen or operational consequence of failure?

• Which business rules and exceptions are embedded in code rather than documented policy?

• What data moves through the service, where does it go and who is accountable for it?

• Which integrations, credentials, unsupported components and supplier dependencies create hidden risk?

• Who can validate the answers, and how will you know when your understanding is good enough to act?

If the honest answer is “not with confidence”, that is not a reason to postpone modernisation. It is the place to start.

Start with one service

At Storm ID, we combine public-sector service design, software engineering, data and AI expertise with deep experience of the Microsoft ecosystem. We use Claude, OpenAI and Microsoft tooling pragmatically, within controls designed for the information and risk in front of us.

A useful first step is not an estate-wide promise. It is one bounded, important application: agree the security boundary, assemble the evidence, test how much understanding AI can recover, and validate the result with the people who know the service.

If you want to find out how much of your legacy environment is truly understood - and where AI could help close the gap - contact us.