Practical guide

Switching LIMS without losing a day of work

Most labs stay on software they have outgrown because the switch looks like a week of chaos. It does not have to be. Here is what actually has to move, the four ways labs do it, and what breaks when it goes wrong.

Start free trial Book a walkthrough

Written by the PingMeDoc™ team, last checked 22 August 2026, 8 min read

Why labs stay on software they have outgrown

Almost every lab that complains about its LIMS has been complaining for more than a year. The reason is rarely that the alternatives are bad. It is that the switch carries a risk the lab cannot price: nobody can promise that Monday morning’s samples will be registered, run, verified and reported on a system the staff learned on Friday.

That risk is real, but it is also concentrated. Most of it sits in two places, the test master and the cutover moment, and both can be managed. The rest of a LIMS migration is more tedious than dangerous.

What actually has to move

A LIMS migration is six distinct movements, and they carry very different levels of risk. Treating them as one project is the most common planning mistake.

Patients: Demographics, contact numbers, identifiers. Almost always the easiest. It is a flat export and a flat import. Watch for duplicate records, which every lab has more of than it expects.
Test master: Test codes, names, units, reference ranges by age and sex, panel composition, method, sample type. This is the critical path and the biggest risk. It is also the thing most labs have never had written down in one place.
Price lists: Retail pricing, per-referrer and per-corporate rates, package pricing, discount rules. Errors here are financial rather than clinical, but they are silent. You find out at month-end.
Referrers: Doctors, corporates, collection centres, commission structures. Usually small in volume and easy to move, but easy to forget until the first commission statement is wrong.
Historical results: Optional, and worth a real decision rather than a default. See the cutover-date discussion below.
In-flight samples: The samples that are physically in the lab on cutover day. This is the part that has to be planned to the hour, not to the week.

If you do one thing before talking to any vendor, export your test master to a spreadsheet and read it. Most labs discover tests that are duplicated, obsolete, priced wrong, or carrying a reference range nobody can source. Cleaning that up is worth doing whether or not you switch, and doing it before a migration means you import a clean master instead of carrying the mess across.

The four ways labs actually do it

Every migration is a variation on one of these. The right choice depends far more on your risk tolerance and staffing than on the software.

Big-bang cutover: Stop on Friday, start on Monday. Fastest and cheapest when it works, and the only option if the old system is being switched off for you. The failure mode is that everything goes wrong at once, on a day when the bench is also running samples.
Parallel run: Both systems live for two to four weeks; every sample is entered twice. Expensive in staff time and genuinely unpopular with the bench, but it is the only approach that proves the new system produces the same numbers before you depend on it.
Module by module: Move billing first, then registration, then the bench, then reporting. Lowers the risk of any single step and stretches the pain over months. Needs the two systems to coexist without fighting over the same data.
Phased, reporting first: Leave the existing LIMS running the bench for a few weeks and go live first on the things that reach patients: report delivery, communication, the online storefront, AI interpretation. The bench follows once the lab has watched the new system handle its own samples. One move, split in two, with no fortnight of double entry.

What breaks in a big-bang cutover

If you go big-bang, these are the failures worth rehearsing. None of them are exotic, they are simply the things that are invisible until the first real sample arrives.

Reference ranges silently wrong. An imported range with the wrong age banding produces a result flagged normal that should be flagged high. Nothing errors. The report just goes out. This is the failure that should keep you up at night, and the reason a parallel run exists.
In-flight samples orphaned. Samples registered on the old system on Friday, run on Monday. Decide in advance whether they are completed on the old system or re-registered on the new one, and tell the bench.
Barcode sequences colliding. If the new system restarts numbering, a tube on the rack can match two different accessions. Set the starting sequence above the old system’s highest.
Referrer commissions mis-stated. Discovered at month-end, by the referrer, which is the worst way to discover it.
Report layout regressions. The new report is correct but looks different, and a referring doctor who has read your reports for ten years notices immediately. Get the template signed off before cutover, not after.
Nobody can reprint last year’s report. The old subscription lapsed, and with it read access. Keep the old system readable for at least a year.

Choosing a cutover date, and what to do about history

Pick a date at the start of a financial period rather than mid-month. It makes reconciliation legible and stops a single month being split across two systems’ reports. Avoid the day before a long weekend, when the people who can fix things are away.

On historical results, the pragmatic answer is usually: do not migrate them. Keep the old system read-only, start the new one clean from the cutover date, and give the front desk a documented way to look up an old report. Full historical migration is expensive, error-prone, and mostly serves a completeness instinct rather than an operational need. The exception is if you need historical results computable, for delta checks against a patient’s previous value, or for a longitudinal patient record, in which case migrate the last one to two years and leave the rest read-only.

Cutover week

Test master imported, reviewed line by line, and signed off by whoever owns clinical quality.
Reference ranges spot-checked against the old system for at least twenty high-volume tests.
Barcode sequence set above the old system's highest accession number.
Report template approved by a referring doctor who reads your reports regularly.
In-flight sample policy written down and briefed to the bench.
Price list and referrer commissions verified against last month's actuals.
Old system confirmed readable for at least twelve months, in writing.
Full data export taken and opened, before the old subscription lapses.
A named person on site on cutover day whose only job is this.

How we move you, and why it is reversible

PingMeDoc™ is a LIMS, not an add-on to somebody else’s. Treat this section as interested rather than neutral. We run the third approach above: reporting, delivery and the patient-facing side go live in week one, the bench follows once you have watched the new system handle your own samples. You end on our LIMS either way, the question is only how many weeks it takes.

Why we start at the reporting end: it makes the first fortnight reversible. Your bench keeps running on what it knows while you judge us on real reports, and if we do not suit you, you stop and nothing about your core workflow changed. A vendor who demands the bench on day one is asking you to bet the lab on a fortnight’s acquaintance.

The move itself is ours to do, and it is free. Patient register, test list, rates, referring doctors and historical results come across, both systems run in parallel until you sign off, and we do not switch the old one off, you do. What that does not fix is a bench problem you have not told us about, so tell us on the call what is actually slow. The checklist above applies whoever you buy from.

Common questions

How long does a LIMS migration take?: For a single-centre lab with a clean test master, a parallel run of two to four weeks is typical: one week to configure and import, one to two weeks running both systems side by side, then a cutover. Multi-centre labs and labs with a messy or undocumented test master take longer, and the test master is almost always the critical path rather than the data volume.
Do I have to migrate historical results?: Not necessarily, and deciding this early saves the most time. Many labs keep the old system read-only for historical lookups and start the new one clean from a cutover date. That is legitimate as long as you can still produce a historical report on request, which matters for NABL records and for any patient asking for a result from last year.
What is the riskiest part of changing LIMS?: The test master and price list, not the patient data. Patient demographics import cleanly almost every time. Test codes, units, reference ranges, panel composition and per-referrer pricing are where errors hide, and an error there produces a wrong report rather than a failed import, which is far more dangerous because nothing alerts.
Can I run a new system alongside my existing LIMS?: Sometimes, and it is worth asking. Where the new system adds a layer (patient communication, report delivery, an online storefront, AI interpretation) rather than replacing the bench workflow, it can run on top of what you already have. That turns a migration decision into a reversible trial, which is a very different risk profile.
What should I keep from the old system after cutover?: Read-only access for at least a year, a full data export in a format you can actually open, and your report templates. Labs routinely lose the ability to reprint an old report because access lapsed with the subscription, and that is discovered at the worst possible moment.

Start with the part you need

Use PingMeDoc as your complete operating platform, or connect selected capabilities to your existing workflow where supported. Try it against your own data before you choose a cutover date.

Start a free trial Book a walkthrough