AI helps map Britain’s ageing government software

The Student Loans Company used AI-assisted analysis to examine 33 applications written in Clojure in less than a day, the Government Digital Service reported on 14 October. The traditional approach had been estimated at around five weeks. The work clarified dependencies and informed migration planning towards supported versions of Java; it did not complete that migration.[1]

The distinction explains the opportunity. Before replacing an old application, an organisation needs to know what relies on it. GDS describes estates with incomplete documentation and knowledge concentrated in a few specialists. Faster analysis makes that hidden structure easier to investigate.[1]

The cost of not knowing

A simple hypothetical example shows why this matters. Suppose three services calculate eligibility, authorise payment and send a notification. Replacing the payment application looks manageable until an undocumented overnight job turns out to connect all three. Discovering that connection before choosing the migration sequence changes the project plan; discovering it after a switch can stop the service. This example illustrates dependency analysis, not an incident reported at the Student Loans Company.

The wider problem predates the current AI pilots. In its March 2025 report, the Public Accounts Committee recorded DSIT’s estimate that 28% of central-government systems met its legacy definition in 2024. That definition included unsupported or unmaintainable products, uneconomic systems and systems above an acceptable risk threshold. Age alone was not the criterion.[2]

The committee also reported that 21 of the 72 highest-risk systems prioritised in the 2022–25 roadmap still lacked remediation funding at the time. It called for clearer measurement of both the costs of repair and the costs of inaction. Those historical figures describe the challenge the programme inherited, not a fresh count of unfunded systems today.[2]

The practical connection is between technical knowledge and a spending decision. A budget proposal becomes more concrete when it identifies the dependencies to untangle, the tests to preserve and the order in which work can proceed. Faster discovery can reduce the cost of producing that proposal; funding and delivery still determine whether the upgrade happens.

GDS says successful pilots depended on experienced teams, system access and clear ownership. Its next step is a playbook, still undergoing user testing and review. The immediate gain is better knowledge of systems already serving the public.[1]

Report an error or suggest a correction