UK replaces Palantir‑based refugee‑matching system with in‑house platform, saving millions

What was claimed

The UK government announced that its new, internally built platform for the Homes for Ukraine scheme is saving the Ministry of Housing, Communities and Local Government (MHCLG) “millions of pounds a year” in running costs. The statement implies that the previous Palantir Foundry system was expensive, inflexible, and that an in‑house replacement can deliver the same functionality at a fraction of the price.

What is actually new

• Scope of the replacement – The original system was a Palantir Foundry deployment that integrated visa‑application data, local authority housing registers and private‑sector offers of accommodation. It was commissioned on a free‑trial basis, then moved to two paid contracts worth roughly £4.5 million and £5.5 million over a year.
• In‑house stack – MHCLG’s blog post (see the official announcement) says the new platform is built on existing open‑source components, primarily a PostgreSQL database, a Django‑based web front‑end and a set of micro‑services orchestrated with Kubernetes. The codebase is hosted on the department’s GitLab instance, giving civil servants direct access to the source.
• Cost structure – By eliminating the per‑seat licence fees that Palantir charges for Foundry, the department avoids recurring software costs. The NAO estimates the annual operating expense of the new stack is under £1 million, largely covering cloud hosting and a small team of developers.
• Security and data sovereignty – Because the data now resides on UK‑based cloud infrastructure and is processed by staff directly employed by the civil service, the ministry can apply its own security hardening guidelines without negotiating additional clauses with a US vendor.

Limitations and open questions

1. Development effort – Building a system that can ingest, reconcile and match tens of thousands of housing offers against a similar volume of refugee applications is non‑trivial. The NAO report notes that MHCLG allocated a dedicated team of eight engineers for the migration, plus external consultants for data migration. Those resources could have been used elsewhere in the department.
2. Feature parity – Palantir’s Foundry provides a visual data‑pipeline builder, built‑in audit trails and a low‑code UI for non‑technical users. The new platform replicates the core matching algorithm but does not yet offer the same level of self‑service analytics. Users still rely on a small internal analytics team to generate reports.
3. Scalability – Foundry is designed to handle petabyte‑scale workloads with automatic scaling. The in‑house solution uses auto‑scaling groups on the UK‑based cloud provider, but capacity limits have not been publicly benchmarked. If the scheme expands to cover additional refugee flows, the system may need further optimisation.
4. Maintenance burden – Open‑source stacks shift the responsibility for security patches, dependency updates and performance tuning onto the civil service. While this gives more control, it also creates a long‑term maintenance commitment that Palantir previously shouldered.
5. Vendor lock‑in risk – The move reduces reliance on a single US supplier, but the department now depends on a specific cloud provider and a set of open‑source projects that may evolve under different governance models. Future migrations could still encounter lock‑in at a different layer.

Broader context

The decision fits a growing trend in UK public‑sector IT to audit existing contracts for cost‑effectiveness and to develop “sovereign” alternatives when feasible. Similar efforts have been seen in the NHS’s shift from proprietary electronic health‑record systems to the open‑source OpenMRS platform, and in the Ministry of Defence’s pilot of a self‑hosted data‑analytics stack.

Critics of Palantir argue that its business model—offering a free pilot to secure a later paid contract—conflicts with public‑procurement rules that require open competition. The NAO’s 2023 audit flagged this practice as a concern, and the MHCLG’s replacement can be read as a response to that scrutiny.

Supporters point out that Palantir’s engineering resources can spin up a production‑grade system in days, a capability that is hard to match with a small internal team. In emergency situations—such as the rapid launch of Homes for Ukraine in March 2022—speed can outweigh cost considerations.

What this means for future projects

• Capability building – Ministries that wish to replicate this approach will need to invest in recruiting and retaining software engineers with experience in data integration, cloud orchestration and security compliance.
• Hybrid models – A pragmatic path may involve using a commercial platform for the initial rollout, then gradually migrating core components to an in‑house stack once the data model stabilises.
• Transparency – Publishing the source code (or at least a high‑level architecture diagram) would allow external auditors to verify that the new system meets the promised security and privacy standards.

In short, the UK’s switch from Palantir’s Foundry to a custom platform does deliver measurable cost savings and greater data control, but it also introduces new operational responsibilities. The success of the move will depend on the department’s ability to maintain and evolve the system as the refugee‑housing landscape changes.