Skip to content
Back to blog

Moving a clinic off paper registers without losing a week

The migration that fails is the one that tries to digitise ten years of history first. Start at the front desk and let the archive stay on paper.

Qlinio
4 min read

Most clinic software migrations do not fail during the software part. They fail during the fortnight when staff are running the old system and the new one simultaneously, patients are waiting, and someone decides it was easier before.

The way to avoid that fortnight is to be much less ambitious about history.

Do not backfill the archive

The instinct is to enter every existing patient before going live. It is the single most reliable way to abandon a migration.

A clinic with 8,000 historical patient files, at four minutes of data entry each, is 533 hours of work. Nobody has 533 hours. So it gets done partially, the data quality is poor, and the resulting patient list is a mix of complete records, half-records and duplicates — which is worse than starting clean.

The alternative: migrate patients as they walk in. A returning patient gets entered at their next visit, when the receptionist has their file open anyway and the marginal cost is two minutes. After six months you have digitised the patients who actually attend, which is the only cohort that matters. The rest stay on paper, where they were doing no harm.

What to migrate up front

Two things only:

The active patient index — name, phone, age, sex, and a reference to the paper file number for anyone seen in the last twelve months. Not their clinical history. Just enough that reception can find them and the paper file can be pulled if needed.

Anything with a legal retention obligation that you cannot afford to lose to a flood or a fire. Medico-legal cases, Schedule H1 registers, anything under dispute.

Everything else can wait, possibly forever.

Duplicates are the real data problem

The single largest quality issue in Indian clinic databases is the same patient existing three times: once as "Ramesh Kumar", once as "R Kumar", once as "Ramesh Kumar S/o Suresh". Different phone numbers, because the family shares one.

Decide the rule before you start, not after:

  • Phone number is not a unique key. Families share phones. Multiple patients per number must be supported.
  • Name plus date of birth plus phone is a reasonable duplicate check.
  • Your software should warn on likely duplicates at registration and offer a merge, not silently create a second file.

If you are going to capture ABHA numbers, this gets easier over time — a 14-digit ABHA is a unique key. But the duplicates you create in the first six months will outlive that.

Sequence the modules, do not switch everything on

A clinic running registration, doctor notes, pharmacy, lab and billing does not move all five at once.

  1. Registration and the queue first. Highest volume, lowest clinical risk, immediate visible benefit. Reception learns the system on the simplest task.
  2. Billing next. Also high volume, and it is where errors are noticed immediately, which is good for a shakedown period.
  3. Clinical notes and prescriptions. Only after the desk is fluent. This is the module doctors resist, and the resistance is much lower when the rest of the clinic is already running smoothly.
  4. Pharmacy and lab last. They depend on orders flowing correctly from the clinical module.

Each step should run for at least two weeks before the next begins.

The data protection dimension

Migration is processing. The DPDP Rules, notified November 2025 with full compliance due May 2027, apply to the records you move as much as the ones you create.

Two practical implications:

Set the retention period during migration, not after. You are already touching every record; decide then how long records are held after a patient's last visit. Retrofitting a retention policy onto a database you have already filled is much harder.

The intermediate files are the risk. Migrations generate exports — spreadsheets on a laptop, a CSV in someone's email, a backup on a pen drive. These are the copies that get forgotten, and they are patient data. Track them, and delete them when the migration completes.

What "done" looks like

Not an empty filing cabinet. Done is:

  • Every patient who walks in today is registered digitally
  • Reception has not touched the paper register in a month
  • The paper archive still exists, untouched, for the patients who have not returned

That last point is the one clinic owners find hard to accept, and it is the reason the migration finishes.

Bringing your clinic online?

See how Qlinikit and the Qlinio platform fit your workflow — book a short walkthrough.