Migrating hospital data without losing a week to it

Ask hospitals what went wrong with their last software rollout and the answer is rarely the software. It is that three weeks after go-live, outstanding patient balances did not agree with the old system, and nobody could say which was right.

Migration is the highest-risk part of any HMS implementation, and it is systematically under-planned because it looks like a technical task. It is mostly a decision-making task.

Decide what not to move

The instinct is to move everything. It is usually wrong, because every additional record type multiplies the reconciliation work, and the value of a ten-year-old outpatient record is low against the cost of validating it.

A workable default split:

• Must move: active patient master records, outstanding balances, current pharmacy stock with batch and expiry, current admissions, active staff and roles.
• Usually should move: patient visit history for some bounded window, two or three years being common, enough for continuity of care without dragging the entire archive.
• Usually should not move: historical billing detail beyond your retention requirement, long-inactive patient records, superseded staff accounts.

Anything you decide not to migrate still has to remain accessible, since retention obligations do not disappear. Keeping a read-only export of the old system is almost always cheaper than migrating data you will not use.

The failure modes, in order of how often they bite

Duplicate patient records

The most common and most damaging. The same patient exists three times because the phone number was entered differently each visit. Migrating as-is carries the duplication forward permanently and corrupts every subsequent count you produce.

Deduplicate before migrating, not after. Decide the matching rule explicitly, phone plus name is typical, and accept it will be imperfect. Review the ambiguous cases manually rather than letting an automated rule merge two different people, which is far worse than leaving two records for one person.

Balances that do not reconcile

If outstanding balances do not tie out to the rupee on cutover day, you will be arguing with patients about money using two systems that disagree. Freeze the old system, take a balance snapshot, migrate, and reconcile the total before anyone transacts. Do not go live on a partial match and plan to fix it later.

Pharmacy stock counted at the wrong moment

Stock moves continuously, so a count taken on Monday and loaded on Thursday is wrong on arrival. Physical stock-take should happen as close to cutover as operationally possible, ideally during a genuine pause in dispensing.

Patients mid-admission at cutover

A patient admitted before go-live and discharged after it has a record split across two systems, and their final bill needs charges from both. Decide in advance: either migrate in-flight admissions fully, or hold them in the old system until discharge. Both work. Deciding on the day does not.

Sequence that reduces the blast radius

1. Extract and inspect early. Pull a sample well before cutover and look at it. Data quality is always worse than remembered, and finding that out a week ahead is very different from finding out on the night.
2. Do a full dry run. Migrate everything into a test environment and have actual staff, not the vendor, check their own records. Your pharmacist will spot a wrong batch number instantly; a project manager will not.
3. Reconcile against agreed totals. Patient count, outstanding balance total, stock value. Agree the tolerance beforehand, and for balances it should be zero.
4. Cut over during genuine low volume. Not merely a quieter afternoon.
5. Keep the old system readable. Not writable, readable, for at least a few months. It is the cheapest insurance available.

The question to settle before signing

Ask the vendor who does the data cleaning, and get the answer in writing. “We will migrate your data” often means “we will load whatever file you give us”, which leaves deduplication and correction with you, unbudgeted, during the busiest fortnight of the project.

Our own rollouts run four to six weeks precisely because this work is real and gets scheduled rather than assumed. Our buyer’s guide covers the other questions worth asking before you commit.