Lab Software Migration Checklist (2026)

Before you migrate: the data audit

If you're still deciding between systems, that decision belongs in a straight feature-by-feature comparison. This checklist starts once you've chosen and are getting ready to actually move. Every migration problem traces back to the same root cause: something that only existed in the old system's memory, or in someone's head, didn't get written down before the switch. The fix is a proper data audit, done on paper or in a spreadsheet, before you configure a single screen of the new system. At minimum, pull together:

Test catalogue: every test you run today, with its exact name, unit and any methodology notes, not just the ones that come to mind first.
Price list: current prices per test, including any package or panel pricing, and per-branch prices if you run more than one location.
Referring-doctor list: every doctor, consultant and collection centre you deal with, active or dormant, with correct spellings and registration details.
Commission rules: the actual rate agreed with each referrer, per test, not a rounded number from memory.
Reference ranges: the age- and gender-specific ranges you report against for every test, plus any critical values you flag manually.
Patient and report history: how far back you need old reports and results available for comparison and continuity of care.
Outstanding dues: every patient who owes money, and any partial payments or discounts already agreed, so nothing gets billed twice or written off by accident.

None of this needs to be pretty. A photographed register page, an old Excel export or a printout from your current system is enough: the point of the audit is simply that every one of these seven things exists somewhere durable before you start, not scattered across whoever happens to remember it. This is exactly the data HealthFlow's onboarding sets up for you from your lab's existing files and registers (the test catalogue, reference ranges, price list, doctor list and commission rules) all get carried in rather than rebuilt from scratch, with full historical data migration available from ₹9,999. But doing the audit yourself first, even roughly, is what turns a two-week scramble into a two-day setup.

Set up your new system

With the audit in hand, set the new system up against it rather than against guesswork. Four things matter most before you let a single real patient near it:

Branding: your logo, letterhead colours, and lab name and address correct on every report, bill and WhatsApp message before go-live, not fixed after patients start noticing. (White-label branding across reports, bills and the WhatsApp report page is available on a higher HealthFlow plan.)
Users and roles: front-desk, phlebotomy, lab technicians, doctors and the owner each given access that matches what they actually do, not one shared login for everyone.
A dedicated WhatsApp number: set up, tested, and delivering a real report to a real phone before go-live, so day one isn't the first time anyone has seen it work. Your own personal WhatsApp stays untouched: the lab gets its own dedicated, lab-branded number for report delivery.
Templates: report layout, bill format, and any test panels or profiles configured and checked against a printed sample, not just viewed on screen.

This is also the point to confirm the basics you're trusting your data to. HealthFlow keeps each lab's data in its own isolated PostgreSQL database, hosted in the EU (Germany) and encrypted in transit, with an append-only audit trail of every report access and full data export available any time: see how your data is stored and secured for the detail.

The parallel-run week

Do not cut over in one step. Run the old system and the new one side by side for at least a week (ideally through a full billing cycle) so mismatches show up while a phone call can still fix them, not after a patient has already been billed twice.

Bill in both systems, for every patient, on the same day. Don't sample a handful and assume the rest will match.
Compare bill totals line by line, especially package and panel pricing and any discounts, which is where manual re-entry most often drifts from the original price list.
Validate a full report in the new system against the old one (the reference ranges, the Low/Normal/High flags, the layout, the QR verification link, and both signatures) before it ever goes to a real patient.
Send a test WhatsApp report to a real phone and confirm it shows sent, delivered and read, not just that it appears to have gone out.
Check outstanding dues carried over correctly, so a patient who already owed money before the switch doesn't get billed as if starting fresh.

A week feels slow when everyone wants the old system gone. It is the cheapest week you'll spend: every mismatch caught here is a five-minute fix; the same mismatch caught three weeks after go-live is a disputed bill, or a doctor asking why their commission statement doesn't match what they were told.

Cutover and go-live day

Once the parallel week has come back clean, pick a specific day and time to cut over, not "sometime this week." For the reasoning behind why a quiet, planned day beats a rushed weekend switch, see our guide on how to switch lab software without downtime.

Choose a low-volume day rather than your busiest booking day of the week, so any hiccup affects the fewest patients.
Set a fixed cut-off time after which no new entries go into the old system: a clean line, not a gradual handover.
Take a final export of the old system's data and keep it somewhere safe as a static reference, even after you stop using it day to day.
Confirm every user can log in to the new system, with the right role, before the first patient of the day arrives.
Have one person watch the first ten bills and first ten reports go through end to end, rather than assuming the parallel-run week means nothing can go wrong on day one.

The first week after

Go-live day is not the finish line. The first week is when real volume, real edge cases, and real referrers put the new system under load for the first time.

Spot-check reports daily: pick a handful at random and confirm the reference ranges and flags are correct, not just that a report was produced.
Watch turnaround time (TAT): is it holding steady against what you promised patients, or quietly slipping while everyone finds their feet on the new screens.
Confirm WhatsApp delivery is showing sent, delivered and read for real patient batches, not just the one test message from the parallel-run week.
Run your first Pay-Run and check it reconciles against the actual bills raised that period before you settle referring doctors, consultants, collection centres and outside labs (doctor referral payouts are part of a higher plan).
Keep the old system's final export on hand for a defined period (a month is typical) before you consider retiring it for good.

None of this is exotic. It is the same discipline any operational change deserves: know what you have, set the new thing up against it, run both until you trust it, then switch on a day you control, and keep watching for the week after. Labs that treat migration this way genuinely don't lose a day of billing.

See what's included at each plan, including onboarding and data migration →

Frequently asked questions

How long does a lab software migration actually take?

For most independent labs, budget one to two weeks: a few days for the data audit and initial setup, a full week of running the old and new systems in parallel, and a single planned cutover day. Labs with a longer test menu or several branches sometimes need a little longer on the audit step, but the parallel-run week itself rarely needs to stretch beyond seven to ten days once the data going in is correct.

Will patients notice the switch?

They shouldn't, beyond a cleaner bill and report. Bills and reports continue to print under your lab's own name and letterhead, and report delivery keeps arriving on WhatsApp. The only visible change for a patient is a new dedicated WhatsApp number sending the message, not a change in who the lab is. The point of a parallel-run week and a planned cutover day is precisely that patients never experience a gap in service.

What data has to migrate, and what can be left behind?

Your test catalogue, price list, reference ranges, referring-doctor list and commission rules should always migrate first: the new system cannot bill or report correctly without them. Patient and report history is more of a judgment call: many labs bring across a defined window, such as the last one to two years, for continuity of care and comparisons, and migrate the remainder only on request, since full historical migration is usually a separate, priced step rather than something that has to happen on day one.

Lab software migration checklist: how to switch without losing a day of billing