The audit manager had a sample of sixty benefit payments and a question about the forty-first. The department had replaced its benefits system partway through the year. The new platform was running well and the old one, which had been in service since before most of the team joined, had been switched off. The audit was for the annual accounts, and the conversation went like this.
The post-modernisation audit
Audit manager: Sample item 41. The payment went out after cutover, but the award was set up on the old system. I’ll recalculate it myself, so I need the circumstances and rates that applied on each date, and the evidence for each change.
Transformation lead: The new platform has the award as it stood at cutover, and every change and payment since. That’s all on screen.
Audit manager: The award changed twice before cutover, once for a change of circumstances and once on appeal. Where are those?
Transformation lead: We migrated the current state of each claim as an opening position. The history went into an archive extract.
Audit manager: Before I rely on the extract, how do you know it’s complete and accurate?
Transformation lead: We reconciled total caseload and total weekly liability between the two systems. They matched to the penny.
Audit manager: That tells me nothing went missing in aggregate. It doesn’t tell me this claim’s history is right. Can I see the change history for it, with who made each change and why?
Transformation lead: The officer IDs came across. The reason codes lived in a lookup table on the old system, so some are just numbers now. And the links to the case files used the old system’s IDs, which we didn’t migrate, so I can’t point you to the appeal decision from here.
Audit manager: Who has write access to the archive, and is that access logged?
Transformation lead: It’s in a storage bucket with restricted access. I’d have to check the logging.
Audit manager: If I can’t test the history on this claim, I can’t test it on any migrated claim, and that’s most of the caseload. I’ll need to take that to my director, because it may affect the opinion.
Composite of several programmes; roles, not people.
The new platform works, and none of the audit manager’s questions were about that. She was asking whether the department could show, for one specific claim, what was decided, by whom, on what evidence, and that the record hadn’t changed since. The old system could answer, clumsily, because it kept a journal of every change to a claim and linked each one to its case file. The modernisation carried the functionality across and left most of that behind.
Evidence Versus Speed made the general case that evidence has to be produced by the systems themselves, not assembled afterwards. This post is about what happens to that evidence when the system holding it is replaced.
Where the standard migration playbook falls short
The cost-led playbook for legacy system replacement, which is as common in government as in industry, is sound for what it’s designed to do. Move the current state, keep a copy of the history somewhere cheap, prove the new system works through testing and a parallel run, then switch the old one off to stop paying for it. Success is measured by cutover, feature parity, and the cost line that drops when the legacy contract ends.
The auditor’s evidence standard is the same one a commercial auditor applies. The INTOSAI principles that supreme audit institutions draw on say that, in financial audits, the requirements on the auditor are the same as under the international auditing standards. They ask for evidence that is sufficient to persuade a knowledgeable person and appropriate, meaning relevant, valid, and reliable, and they list recalculation and reperformance among the ways to get it. If the evidence an auditor can’t obtain could be material, the opinion is qualified, and if it’s also pervasive, the auditor disclaims (INTOSAI, 2019). What government audit adds is regularity, testing whether transactions comply with the laws and authorities that govern them (INTOSAI, 2019). For a benefits payment, that means showing the award followed the legislation on the dates that mattered, which is impossible without the history.
Records law adds a second layer. In the US, federal agencies running electronic recordkeeping must keep audit trails that track use of records, and must have procedures to migrate records together with their associated metadata when technology changes. The same rule says backups don’t count as a recordkeeping system (National Archives and Records Administration, n.d.). An archive extract in a storage bucket can easily end up closer to a backup than a record. The UK’s National Archives, in guidance written for document and records management systems, warns that audit trails may not export at all, in which case they have to be kept accessible outside the system. It also warns that dates such as a record’s creation date can be reset to the date of migration (The National Archives, 2017).
Records managers know all of this. The trouble is that it often sits outside the legacy modernisation plan. The US Government Accountability Office’s review of the most critical federal legacy systems treated planned disposition of the old system as one of three minimum elements of a modernisation plan, alongside milestones and a description of the work, and found that most of the plans it examined didn’t fully cover all three (Government Accountability Office, 2025).
The engineering disciplines that must deliver for audit
An audit-ready modernisation treats evidence as a workstream with its own requirements, tests, and sign-off, alongside functionality. In practice that comes down to a handful of disciplines.
Migrate the history as data, because this is where government data lineage is either carried across or lost. The change journal, with officer, timestamp, reason, and the before and after values, moves into the new estate as structured records that stay linked to the claim they belong to. Lookup tables travel with it, so a reason code still means something on the other side, and so do the links to case files and decision notices. Original dates are carried as data, never inferred from the load.
Reconcile at two levels. Control totals show nothing went missing. A record-by-record comparison of the old and new positions shows each record is right, and the comparison itself is kept, with every difference explained, because the reconciliation run is evidence an auditor will want to see.
Keep what a recalculation needs. Auditors recalculate entitlement from the legislation, the rates, and the claimant’s circumstances, so the essentials are dated rate tables and the inputs to each decision. Where the new platform holds its rules as versioned, dated artefacts, past decisions can also be explained in the system’s own terms. Keeping the old calculation runnable in a read-only form is a useful extra for claims likely to be revisited, not the core.
Keep the parallel-run results as a record. When both systems calculate the same claims for a period, the comparison is evidence, including the cases where they disagreed and how each was resolved.
Decommission last, against a checklist agreed with the people responsible for audit and records. The National Archives recommends agreeing clear acceptance criteria with suppliers before a migration starts (The National Archives, 2017). Evidence criteria belong on that list, and they’re easiest to agree while the old system is still there to test against.
The evidence layer that moves with the workload
Those disciplines work best with an architectural home of their own: an evidence layer that sits beside the application rather than inside it.
Every consequential action on a claim (an award, a change of circumstances, a payment, or an override) writes a record to a store that the application can add to but not edit. Each record carries who acted, under what authority, on which evidence, and the original timestamp. Records are hash-chained, and the latest chain hash is signed at intervals and stored somewhere the store’s own operators can’t write, so a later change, even by an administrator, shows up when the chain is checked. Corrections are new entries that point to the record they correct. Access to the store is controlled and logged, which is the audit-trail requirement records law already sets. Disposal is designed in from the start too, because records schedules require eligible records to be deleted (National Archives and Records Administration, n.d.). One way is to encrypt each claim’s records under its own key and destroy the key when the retention period ends, so the store can meet its disposal schedule without breaking the chain.
Migration then means loading history into the same layer with its provenance marked: which system it came from, when, and which reconciliation run verified it. An auditor can follow sample item 41 from its first award to the latest payment, with a marker showing exactly where the line between systems fell and which run verified the crossing. The chain only protects history from the moment it’s loaded, so whether the history was right before then still rests on the reconciliation and on the old system’s controls. That’s why the reconciliation is kept.
The layer is also built to outlive the application. Benefits platforms get replaced, and in many departments the next replacement is already being planned. If the evidence lives inside the application, every modernisation has to solve this problem again. If it lives in its own layer, with its own retention rules and access controls, on whichever public sector cloud or data centre the department uses, the next migration moves the application and leaves the evidence where it is.
A lot of government IT transformation is still to come. In its report on government cyber resilience, the UK National Audit Office found departments still running hundreds of ageing legacy systems, with no fully funded remediation plans for half of them (National Audit Office, 2025). The GAO’s list of the most critical federal systems includes several it describes as decades old (Government Accountability Office, 2025). We build the evidence layer into the first wave of a government cloud migration, before go-live rather than after it, as part of Sakura’s Cloud practice.
What good looks like
Same sample, a different programme: item 41 again, this time where the history was migrated into an evidence layer. The audit manager sees both pre-cutover changes, with officers, readable reasons, original dates, and links to the case file and appeal decision. A provenance record ties them to a named reconciliation run, and the rates in force on each date are on file. She recalculates the award and gets the same figure. The migration is still reviewed as a significant change in the year, but against a reconciliation the department already holds, not one it has to rebuild under pressure.
Evidence Versus Speed traced the same move in clinical research and in the audit profession’s own standards, from describing controls to producing evidence for a specific item on demand. Benefits audit has asked for evidence item by item for a long time. Modern platforms make that evidence cheap to keep, as long as the modernisation plans for it.
It does cost something. Migrating history properly takes longer than migrating current state, record-level reconciliation is harder than totals, and an evidence layer is another system to run. Those costs are usually smaller than rebuilding lost history once the old system has gone, and they’re easiest to fund at the start, which is why evidence requirements belong in the business case and the supplier’s acceptance criteria.
Before the old system is switched off, pick one claim that crosses the cutover and try to evidence it end to end. If you want a second pair of hands on that test, our GRC service has run it on live programmes, and the gaps it turns up become the programme’s evidence requirements.
References
Government Accountability Office, 2025. Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems. GAO-25-107795. US Government Accountability Office. Available at: https://www.gao.gov/products/gao-25-107795 [Accessed 1 October 2026].
INTOSAI, 2019. ISSAI 100: Fundamental Principles of Public-Sector Auditing. International Organisation of Supreme Audit Institutions. Available at: https://www.issai.org/wp-content/uploads/2019/08/ISSAI-100-Fundamental-Principles-of-Public-Sector-Auditing-1.pdf [Accessed 1 October 2026].
National Archives and Records Administration, n.d. 36 CFR 1236.20: What are appropriate recordkeeping systems for electronic records? Electronic Code of Federal Regulations. Available at: https://www.ecfr.gov/current/title-36/chapter-XII/subchapter-B/part-1236/subpart-C/section-1236.20 [Accessed 1 October 2026].
National Audit Office, 2025. Government cyber resilience. HC 546, Session 2024-25. National Audit Office. Available at: https://www.nao.org.uk/reports/government-cyber-resilience/ [Accessed 1 October 2026].
The National Archives, 2017. Migrating information between records management systems. The National Archives. Available at: https://cdn.nationalarchives.gov.uk/documents/information-management/edrms.pdf [Accessed 1 October 2026].