How to change lab software: a migration checklist for labs

Labs put off switching software for years, and the reason is rarely the software itself. It is the rate list somebody tuned over years, the referring doctors' commission rates, and the fear of a morning where reception cannot bill a walk-in. None of that has to be at risk. What decides whether a switch goes well is whether the right things move across, in the right order, with a way to check before you commit.

What actually has to move

A lab's software holds four kinds of data that a switch has to carry across correctly. Treat each one as its own checklist item, not a single "data migration" line.

Test list and rate list

Every test, panel and package you charge for, with its current rate, any standing discounts, and any doctor-specific or corporate rates. This is the item worth checking most carefully, because a wrong rate is the one migration error that costs money the same day it goes live. Before anything goes live, bill a handful of real cases in the new system — a walk-in, a package, a referred patient with a discount — and check the total against what your current system would have charged.

Patient master

Names, contact details, and enough history that a returning patient does not look like a stranger to the new system. If your reports go out on WhatsApp or by link, check that phone numbers carried across correctly — a single transposed digit sends someone else's report to the wrong number.

Referring doctors and commission

Doctor names, their rates, and how commission is tracked. This list tends to be informally maintained — a rate agreed on a phone call two years ago — so it is worth reviewing it during the move rather than copying it across unexamined. See how a lab tracks referring doctors without disputes for what this list should look like day to day.

Open cases and historical reports

Any sample collected but not yet reported has to be finishable in whichever system it ends up in. Decide, before go-live, whether open cases stay on the old system until they close or move to the new one — do not leave this to be worked out on the day. Historical reports do not need to be re-typed into the new system, but patients and doctors will keep asking for old results for years, so they need to stay findable somewhere, even if that is just a read-only copy of the old system.

Verify before you rely on it

Whatever a vendor's migration process looks like, the checking is yours to do, not theirs. Before you stop using your current software:

• Pick a sample of patients across different test types and compare their record in both systems.
• Bill a real day's worth of cases — including the edge cases: a package, a discount, a TPA claim, a referred patient — and check the totals match.
• Have your pathologist check that a signed report prints correctly on your letterhead, with the right reference ranges and flags.
• Confirm what a patient actually receives — the WhatsApp message, the link, the printed sheet — looks right, not just what the lab-side screen shows.

Run both systems in parallel

The safest way to switch is to run the old and new systems side by side for a short period — billing real cases in both and comparing the output — rather than switching off the old one the moment the new one is set up. This keeps the decision reversible: if something is wrong with the rate list or the report layout, you find out while the old system is still there as a fallback, not on a morning when it is not. Ask any vendor whether parallel running is something they support, and for roughly how long labs typically run it.

Staff training

The people who feel a switch most are reception and the bench, not the lab owner. A new billing screen with different clicks slows the morning down until it is familiar, and a technician entering results manually needs to trust the new screen's layout before they will use it quickly. Plan the setup calls around these two groups specifically, and keep a printed reference of the new system's basic flows at the counter for the first week.

If your lab is NABL accredited

A change of software is a change to how your records are created and controlled, which is the kind of thing an NABL assessor may want to see documented — what changed, when, and how you confirmed the new system's output was correct before relying on it. Rather than assume what your assessor expects, ask them directly, since expectations can depend on your lab's specific accreditation scope and when it was last assessed.

Your patient data during the move

Patient records are personal data under India's DPDP Act 2023, and that does not pause during a migration. Before you sign with a new vendor, agree in writing what happens to your data on the old system once you stop using it, whether you can export everything yourself in a usable format, and where the new vendor stores it. See what actually drives lab software's price for how migration and support costs typically get bundled into a plan, and read the checklist in how to choose pathology lab software if you have not yet picked a vendor to switch to.

Questions to ask before you commit

• Exactly what gets migrated, and what does not?
• Who checks the migrated data before go-live — you, the vendor, or both?
• Can we run both systems in parallel, and for how long?
• What happens to our data on the old system, and can we get it back out later?
• What does the migration itself cost, and what does it cost if we stop halfway?

A vendor who answers these plainly, and shows you the migrated data before asking you to switch off the old system, is worth trusting with the move.

Where Raydian LIS fits

Raydian LIS migrates a lab's test list and rates, patient master, referring doctors and open cases, then runs both systems side by side for the first few days before you switch off the old one. Migration is free on every plan, including Basic at ₹299 a month, and there is a 10-day trial with no credit card so you can check the migrated data yourself before committing. See how switching to Raydian LIS works.