Modernizing legacy government systems without breaking citizens.

Auto-generated and lightly edited. Let us know about errors.

Adaobi Eze: Today's session is about a project that ran for almost three years — modernising the citizen registration system for a West African country with around 14 million registered citizens. Kofi, you led the programme on the ground. Kofi Boateng: The system was originally built in 2002 in Visual Basic against a Sybase database. It had been modified continuously for two decades. Nobody on the original team was still there. The documentation was incomplete. The system was the source of truth for citizen identity, voter rolls, and a dozen government services downstream. Adaobi Eze: Which means you can't take it down. The number-one rule of citizen-facing legacy modernisation is: the lights stay on. Whatever you build, whatever you migrate, citizens have to be able to register a birth, update an address, request a national ID — through the entire migration. Kofi Boateng: We used a strangler-fig pattern, which is well-known as a concept but harder than people expect to execute. The idea is — you put a routing layer in front of the legacy system. Then for each function — birth registration, address change, identity verification — you build a modern equivalent. You point that single function at the new system. The legacy keeps serving everything else. Adaobi Eze: And critically, you run both systems for a period — sometimes six months, sometimes a year — where the new system handles the write and the legacy receives a shadow copy. That lets you verify correctness without risking citizen data. You compare outputs. You catch the edge cases. Kofi Boateng: The migration order matters too. We chose to migrate the read-heavy functions first — identity verification, document download — because those have a clearer rollback path. Writes came later. And we left the most politically sensitive function — voter roll updates — until last, after we had two years of operational confidence in the new platform. Adaobi Eze: One thing I want to emphasise. The hardest part of this project was not the engineering. It was the change management. Government staff had been using the legacy interface for years. We could have built a beautiful new web UI on day one, and they would have rejected it because it looked unfamiliar. So we built the new system with an interface that intentionally mirrored the old workflows for the first phase, and then evolved it gradually. Kofi Boateng: We also invested heavily in training. We sent engineers to physical district offices to sit with the staff and watch them work. That uncovered workflow assumptions the system documentation didn't capture — things like, the clerk in this district always processes births in batches of twenty because that's what fits on the printed forms. If you don't see that, you build a system that breaks their workflow. Adaobi Eze: And backward compatibility lasted years. The downstream systems — pension agencies, the electoral commission, the passport office — each had their own integration with the legacy system. Each had to be migrated separately. We kept the legacy APIs alive for almost three years after the new system was authoritative. Kofi Boateng: A practical lesson — don't promise a hard cutover date. Promise a migration milestone. The political optics of saying the new system is live are tempting, but if you say it before it's truly authoritative, you will spend the next year defending it instead of improving it. Adaobi Eze: The new system has been the authoritative citizen registry for fourteen months now. We're processing 12,000 registrations a day, up from 4,000 on the legacy. We've cleared a backlog of over 200,000 unresolved records that the legacy could never have processed at scale.