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.

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.

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.
Layer on top: Leave the existing LIMS running the bench and add the new system for the things it does better — report delivery, patient communication, an online storefront, AI interpretation. No migration event at all. Only works where the new system is designed to sit alongside rather than replace, and it does not help if the problem is the bench workflow itself.

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.

The option where there is no migration

PingMeDoc™ is built for the fourth approach above, so treat this section as interested rather than neutral. The design premise is that the AI layer, report delivery, patient communication and the patient-facing storefront sit on top of whatever LIMS a lab runs today, rather than requiring it to be replaced first.

What that genuinely gets you: the decision becomes reversible. You are not betting the bench on a vendor you have used for a fortnight, and if it does not suit you, you turn it off and nothing about your core workflow changed.

What it honestly does not solve: if your problem is the bench — registration is slow, worklists are unusable, verification is manual — then a layer on top does not fix it, and you need a real migration. In that case the parallel-run approach above is the one to plan for, and the checklist 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.

Try it without migrating anything

The platform runs alongside your existing LIMS, so you can see it against your own data without a cutover date, a parallel run, or a decision you cannot reverse.

Start a free trial →Request an invite