Migrating a Biometric Database Without Losing Identities or Getting Locked In
Who owns a national biometric database? On paper, the government or the institution that collected it. In practice, often the vendor whose matcher is the only software able to read it. This becomes visible at the worst moment: when the contract ends, when the hardware has to be replaced or when a new standard arrives. Where a biometric register is the main defense against duplicate and fake identities, losing part of it in a migration is not an option. Below I describe what makes these migrations hard and how to plan one.
Why migrations happen
There are four usual reasons. A contract with a vendor ends and the new tender is won by another company. The system is old, and the vendor no longer supports it or asks too much for it. A new modality is added, for example iris to a fingerprint register. Or the standard changes. The last one is happening right now: ICAO requires that from 1 January 2030 newly issued travel documents encode biometric data in ISO/IEC 39794 instead of ISO/IEC 19794, and the new format is not backward compatible with the old one. Inspection systems have had to read it since 1 January 2026, while documents with the old encoding stay in circulation for years. Every system that reads, issues or stores passport biometrics has to be ready for both.
Even the best-funded projects struggle
Consider the US Department of Homeland Security. Its biometric system IDENT, in use since 1994, held more than 268 million identities in 2021. Its replacement, HART, was planned for years, and GAO reports describe the result: the transition of users from IDENT to HART slipped three years against the original plan, technical challenges included the approach to customer migration and biometric matching, and IDENT had to stay in operation longer, with additional cost. In 2023 GAO reported that the 2022 rebaseline added $354 million to the cost estimate and pushed initial capabilities 33 months past the 2019 plan, with the full program schedule not yet planned.
If a project of this scale, with a large budget and experienced contractors, struggles with migration, a ministry with a smaller team and a single vendor contract has every reason to plan it carefully.
What is actually in the database
A biometric database is not one thing. Typically it contains:
- Raw images of fingerprints, irises and faces, sometimes in a standard container, sometimes in a vendor variant of it.
- Proprietary templates, the vendor's own mathematical representation used for fast matching. Another vendor's matcher cannot read them, and they cannot be converted.
- Standard templates, such as ISO/IEC 19794-2 or ANSI 378 fingerprint minutiae, which other systems can read with some loss of accuracy.
- Biographic data, sometimes stored inside the biometric files themselves, which matters for data protection.
- Transaction history: enrollments, verifications, de-duplication decisions.
The key point is the second item. If the original images were not kept, or were kept in a quality that is too low, the only way to move a person to a new system is to enroll them again. For a national register this means millions of people coming back to an enrollment site. This is the real vendor lock, and it is decided on the day the first system is designed, not on the day of migration.
Standards help, but variants remain
ISO/IEC 19794 was created exactly for interoperability, and NIST ran its IREX I evaluation in 2009 to show that standardized iris image formats can be interoperable and compact. Still, a standard leaves room for interpretation, and in our conversion work we regularly see files that follow a vendor's variant of a format and are rejected by other systems. Systems that exchange data with several agencies meet several generations of formats at once. A migration therefore needs a converter that understands the variants, not only the standard.
How to plan a migration
- Audit first. Take a representative sample, a few thousand records from different years and enrollment sites, and measure: which formats and variants are there, what is the image quality, how many records have only proprietary templates, how many contain personal data inside the files.
- Convert to open standards. Images go to standard containers, templates are re-extracted from images where needed, biographic data is separated from biometric files.
- Verify on both systems. Match the same sample on the old and the new system, and explain every difference. De-duplication results should be compared as well, otherwise duplicates appear or disappear silently.
- Switch over in stages. Keep the old system running until the new one gives the same answers. Archive the original images, because they are the only thing that will make the next migration possible.
On top of that, write the exit into the contract with the next vendor: standard formats for storage, access to images, and a test conversion as part of acceptance.
How we help
At Iriscan we built BDI, a biometric data interchange converter based on NIST's open-source NBIS and BiomDI libraries. It converts fingerprint and iris data between vendor variants of the baseline image formats, extracts and converts minutiae templates and extracts biographic data from biometric files. Its fingerprint conversion engine is open source on GitHub, and you can try it in your browser on the biometric data conversion page without uploading anything. For large registers it runs on the customer's premises.
Sources: GAO-21-386, DHS Needs to Fully Implement Key Practices in Acquiring Biometric Identity Management System, 2021; ID Tech, GAO holds HART to account (again), on GAO-23-105959, 2023; RvIG, New encoding of biometric data (ICAO transition to ISO/IEC 39794); NIST, IREX I: Performance of iris recognition algorithms on standard images, 2009.