Most hospital system failures I have been called into were not caused by bad software. They were caused by a migration nobody audited: records that silently did not arrive, patients who now exist twice, a billing table whose foreign keys stopped pointing anywhere. The application demos beautifully. The data underneath it is quietly wrong.

This is the method I use, and why the Kenyan context makes it more urgent than it was five years ago.

Why the pressure is on right now

Three things changed at once.

The Digital Health Act, 2023 created a Digital Health Agency as the custodian of health data nationally, with a mandate covering registries, interoperability standards and the certification of digital health solutions. A hospital system is no longer only a hospital's business.

The Social Health Authority went live on 1 October 2024. Claims moved from paper habits to digital submission, and payment now depends on what your system can produce and prove. When reimbursement is tied to structured data, a data quality problem becomes a cash flow problem.

And the reporting stack matured underneath both. KHIS, Kenya's national DHIS2 instance, aggregates routine data across all 47 counties, with an interoperability layer carrying facility records upward. A hospital that cannot report cleanly is visible.

The result is a lot of facilities changing systems at once, on timelines set by financing rather than readiness.

The eight stages

1. Discovery, before anything is promised

Inventory what actually exists, which is rarely what the org chart says. Every system, every spreadsheet holding real clinical or financial records, every integration, every report someone depends on monthly. Ask who keys data in and watch them do it. The gap between the documented workflow and the observed one is usually where the migration will break.

Output: a system inventory, a data flow map, and a list of every downstream consumer.

2. Schema comparison and field-level mapping

Put the legacy schema beside the target and map field to field. Not table to table, field to field. This is tedious and it is the single highest-value thing in the audit.

What surfaces here: fields with no home in the target, fields the target requires that the legacy never captured, and the dangerous ones, where both sides have a field of the same name meaning different things. A crosswalk document is the deliverable, and it should be signed off by someone clinical, not only by IT.

3. Data quality profiling

Profile before you move. Completeness, accuracy, consistency, timeliness and uniqueness, measured per table and per critical field.

Typical findings: dates of birth stored as free text in three formats, national ID fields holding phone numbers, mandatory clinical fields empty in a third of rows. Decide the rule for each before migration, not during. Migrating dirty data faster does not clean it.

4. Patient identity and duplicate resolution

The one that causes lasting damage. Legacy systems accumulate the same person several times over: a different spelling, a new phone number, a walk-in that never matched the existing record.

Build a master patient index with an explicit matching rule, run it, then have a human review the uncertain band rather than auto-merging it. Merging two different patients is far worse than leaving two records for one patient, and it is much harder to undo. Keep the legacy identifier on every migrated record so any merge can be traced back.

5. Interoperability assessment

Ask what has to leave the building, and in what shape. Aggregate reporting to KHIS. Claims to SHA. Laboratory and imaging interfaces. Any county reporting obligation.

Check the standards the target actually supports rather than the ones its brochure lists. Confirm the reporting periods line up, because a system that cannot produce last quarter in the new format will make the first reporting cycle after go-live unpleasant.

6. Reconciliation testing

Migrate into a staging environment and prove equivalence with counts, not impressions.

Row counts per table. Financial totals per period, which must agree to the shilling. Patient counts by registration month. A sample of complete records traced end to end from legacy to target and read by a clinician. Any variance gets explained, not rounded away. An unexplained 0.4% is a defect, not noise.

7. Cutover and rollback planning

Decide the sequence in advance and write it down: freeze window, final delta migration, verification checkpoints, the named person who declares go or no-go, and the exact conditions that trigger a rollback.

Keep the legacy system readable for a defined period. Not running, readable. It costs almost nothing and it is the only real answer to "what did this record say before?"

8. Findings and the register

Report to a board in the language of risk and money, not schemas. Each finding gets a severity, a plain description of what happens if it is not fixed, an owner and a date. Separate what must be fixed before go-live from what can follow.

What the audit is really protecting

Two things sit outside the technical work and outrank it.

Patient safety. A merged record with the wrong allergy list is a clinical incident waiting for the right day. Identity resolution is a safety activity that happens to be done in SQL.

Data protection. The Data Protection Act, 2019 applies to every copy you make during a migration. Test environments loaded with real patient data, extracts sitting on a laptop, a backup on someone's personal drive. Anonymise test data, log every extract, and delete the copies when the migration closes.

The uncomfortable finding

The most common recommendation I write is not about software. It is that the facility does not yet have agreement on what its own data means. Two departments count an admission differently. Nobody owns the patient register. There is no process for correcting a record after the fact.

A migration exposes that; it cannot fix it. The systems that succeed are the ones where somebody decided those questions before the vendor arrived.