Home Office retires 25‑year‑old asylum database but still juggles spreadsheets

The Public Accounts Committee (PAC) has published a stark assessment of the Home Office’s asylum‑case data architecture. While the department finally decommissioned the Case Information Database (CID) – a monolithic system that first went live in 1999 – officials remain mired in a patchwork of spreadsheets, ad‑hoc tools, and half‑finished integrations.

---

What the PAC found

Issue	Detail
Legacy platform still in use	CID remained active through December 2025 as staff migrated historic records to the new Atlas case‑management suite.
Spreadsheet proliferation	Multiple directorates maintain independent Excel/Google‑Sheets trackers for metrics such as pending appeals, repeat applications and absconders.
Data silos	No single, authoritative view of a claimant’s journey from initial submission through tribunals and appeals.
Inter‑system gaps	The Home Office and HM Courts & Tribunals Service have not yet achieved real‑time case linking, forcing manual cross‑checks.
Performance reporting	MPs struggled to obtain reliable figures on backlog size, processing times and value‑for‑money indicators.

The committee’s language was unambiguous: “no single, reliable view of cases across the asylum system.” The report echoes earlier findings from the National Audit Office, which warned that a unified record for each asylum seeker has been missing for years.

---

Why the data problem matters

1. Operational visibility – Without a consolidated dashboard, senior managers cannot spot emerging bottlenecks. For example, a surge in repeat appeals may be hidden in one spreadsheet while another team sees a drop in overall case volume.
2. Policy evaluation – The Home Office cannot reliably measure the impact of interventions (e.g., faster initial screenings) because the baseline data is fragmented.
3. Fiscal accountability – Parliament’s ability to assess value for money hinges on accurate cost‑per‑case calculations, which are impossible when the same case appears in three different files with conflicting status codes.
4. Risk of error – Manual reconciliation between spreadsheets introduces transcription mistakes, potentially affecting decisions on detention, removal or support services.

---

Atlas: Progress and pain points

Atlas is the Home Office’s flagship cloud‑native case‑management platform, built on a micro‑services architecture and hosted on the government’s secure Azure tenancy. Early performance metrics show a 30 % reduction in average case‑load time for frontline officers compared with CID, and a 15 % improvement in API response latency when querying case histories.

However, the migration has been hampered by three technical hurdles:

• Legacy data transformation – CID stored many fields as free‑text blobs. Converting these into the structured schema required by Atlas forced the team to write custom ETL pipelines, some of which still run on on‑premise VMs.
• Feature parity – Certain workflow steps (e.g., manual “case notes” that were never digitised) were recreated as separate spreadsheet modules because the Atlas UI did not yet support the required customisation.
• Training lag – Over 2,000 caseworkers were re‑credentialed on Atlas in a staggered rollout. Until the training backlog cleared, many teams defaulted to familiar spreadsheet templates.

The PAC notes that the “complexity of the migration has left a hybrid environment that defeats the purpose of a single‑source system.”

---

Recommendations for a unified data layer

Recommendation	Rationale
Enterprise data‑warehouse (EDW) on Azure Synapse	Consolidates historical CID exports, Atlas event streams, and spreadsheet dumps into a normalized schema. Enables fast analytics with Power BI dashboards for senior leadership.
API‑first integration with HM Courts & Tribunals Service	Expose a RESTful endpoint that returns case status in real time, removing the need for manual CSV exchanges.
Governance framework for spreadsheet deprecation	Mandate that any new data collection be stored in Atlas or the EDW; enforce version control via GitLab CI pipelines for any remaining Excel‑based processes.
Automated data‑quality checks	Deploy Azure Data Factory pipelines that flag duplicate IDs, missing mandatory fields, and inconsistent status codes before data lands in the warehouse.
Performance monitoring	Use Azure Monitor to track Atlas API latency, ETL job durations, and spreadsheet sync frequencies, publishing SLA dashboards to the Home Office intranet.

Implementing these steps would give the department a single truth source, reduce manual reconciliation time by an estimated 40 %, and provide the metrics Parliament needs for oversight.

---

How other departments solved similar problems

• HMRC’s migration to the Cloud Platform – Consolidated over 30 legacy tax‑processing systems into a unified data lake, cutting reporting latency from days to minutes.
• DVLA’s “Vehicle Register” overhaul – Replaced disparate Excel‑based fleet logs with a PostgreSQL‑backed service, achieving 99.9 % data‑integrity scores after a six‑month cleanup sprint.

Both cases highlight the importance of centralised data ingestion and strict de‑duplication rules – lessons the Home Office can apply to its asylum pipeline.

---

Bottom line

The retirement of CID is a visible win for the Home Office, but the PAC’s findings make it clear that the underlying data problem is still very much alive. Until the department builds a robust, cloud‑native data layer and phases out the spreadsheet workarounds, senior leaders will continue to operate without the holistic view required to manage the asylum system efficiently and transparently.

Further reading

• Public Accounts Committee report – Asylum system data integration
• Home Office Atlas platform overview (official documentation)
• National Audit Office – Single record for asylum seekers