Choosing the Right LIMS for Your Lab

Most labs choose a LIMS once a decade, part-time, next to a day job, from a shortlist of products that all describe themselves with the same eleven words. The vendors on the other side of the table sell a LIMS every week — they’ve given the demo hundreds of times, heard every objection, and know exactly which questions to steer around. A first-time buyer up against practiced sellers: that mismatch, not features or price, is why so many LIMS selections end in software nobody likes.

We’re one of those vendors, so read this knowing where it comes from. But the process below is the one we’d run if we were on the buying side, and it cuts against us as often as for us: follow it honestly and you’ll disqualify LIMSey for some labs by the end of the first section. That’s the point. A LIMS that fits is the only kind worth implementing, and the fastest way to find it is to make every vendor work through your lab — not the idealized one their demo was built around.

Write your requirements before you watch a single demo

The most common selection mistake is starting with demos. Demos are persuasive by design — every product looks clean with the vendor driving on the vendor’s data. Whatever you watch first becomes the yardstick for everything after, and you end up comparing products against each other instead of against your lab.

The fix is a requirements document, and it doesn’t mean a 400-row RFP spreadsheet. RFP checklists get a “yes” in every cell of every vendor’s column — “Has audit trail: ✓” tells you nothing about whether the audit trail would survive your assessor. What actually works is a short document that describes your lab concretely enough that a vendor can tell you, quickly and honestly, whether they fit:

What to capture	What to write down
How work arrives	Who asks for testing, in what form (email, spreadsheet, walk-up), and what a request contains. Attach 2–3 real requests, as they look today
Samples and tests	What you test, roughly how many samples a month, what a sample ID needs to encode, which tests run against which standards
Scheduling	How work gets assigned today, where the queue lives, what “late” means and who notices
Results and review	Where results come from (instruments, manual entry), who reviews, who approves, what happens on a fail
Reporting	Attach 2 finished test reports. These are the lab’s real product — any LIMS you pick must be able to produce them
Equipment	Your instrument list with calibration intervals — our interactive equipment reference template builds this in the browser
Integrations	Which instruments export data, in what format, and what should happen to it — plus any ERP/PLM systems upstream or downstream
Users and security	Headcount by role (lab staff vs. requesters), your identity provider if IT runs SSO, and any data-handling rules
Compliance	One honest sentence: accredited to ISO 17025, working toward it, customer-audited, or none of the above

Two working sessions get this on paper. If you want a head start, our free templates are interactive versions of several of these artifacts — the test request form is a good proxy for “how work arrives,” and the RACI matrix builder is worth ten minutes to settle who owns the selection itself (more on that next). They fill out on the page and print to PDF; no email required.

Send the document to every vendor you shortlist, before the demo. The useful vendors will read it and demo against it. The other kind will give you the standard tour anyway — consider it a free preview of their customer service.

Get all four stakeholder groups in the room

A LIMS touches more people than the lab manager who runs the selection, and the groups that get skipped are the ones that sink adoption later.

• Lab engineers and technicians live in the system many times a day — receiving requests, running tests, entering results, building reports. Their tolerance for clunky software is the binding constraint on adoption. Put at least one skeptical senior tech on the evaluation team, and weight their trial feedback heavily.
• Lab management assigns work, watches throughput and on-time numbers, approves results, and answers for the lab’s performance. They should evaluate the metrics and scheduling views against the questions they actually get asked upstairs.
• Test requesters are the group nearly every selection forgets — and for an in-house lab they’re most of your users. The engineers who send you work will only use a system that makes requesting easier than the emails and spreadsheets it replaces. If submitting a request is too difficult, they’ll route around the LIMS and you’ll be back to inbox triage within a quarter.
• IT won’t use the LIMS, but they’ll be asked to bless it. Bring them in early with the questions they’ll ask anyway: SSO against your identity provider, where data lives, backup and restore practice, security attestations, and how data comes back out if you ever leave. (Our answers are on the security page; the next section is the checklist version.)

This is the reason to make requesters first-class in the evaluation: in LIMSey, the lab pre-defines job templates so a requesting engineer fills in a short form — the Tensile Test Suite above asks the requester for 17 fields and reserves one for the lab — and standardized work arrives without anyone policing formats. Whatever LIMS you choose, ask to see the requester’s experience end to end, not just the lab’s.

Know which types of LIMS you’re actually comparing

“LIMS” covers products that have almost nothing in common. Two axes matter for a shortlist.

By deployment. Multi-tenant SaaS (the vendor runs one current version for everyone, you pay per user), single-tenant hosted (your own copy on rented infrastructure — cloud hardware, on-premise economics), and on-premise (your servers, your IT). We’ve written a full post on what “cloud-based LIMS” really means and what five years of each actually costs, with a worked TCO table — the short version is that below about twenty users the comparison isn’t close, and the deciding rows are the ones that never appear on a quote: servers, backups, upgrades, and the fraction of an IT salary that keeps them alive.

By market. Enterprise platforms built for pharma QC, clinical, and environmental labs — powerful, and priced and implemented accordingly. Vertical products built around one kind of lab and its workflow. Free and open-source systems, where the license is free and the configuration, hosting, and maintenance are your time. And custom in-house builds, which start as a clever database and end as an unfunded software product your lab maintains forever.

The single most useful shortlisting question is: “How many of your current customers look like us?” A vendor whose center of gravity is clinical diagnostics can technically serve an engineering test lab, and the implementation will fight you the whole way — every default, every label, every report template will assume a lab you aren’t. LIMSey’s center of gravity is in-house engineering and materials test labs inside manufacturers; if you’re a high-throughput clinical lab, we’re the wrong tool, and we’ll tell you so on the first call. Every vendor has an equivalent sentence. Make them say it.

Ask the security questions during selection, not after

“Is the LIMS secure” isn’t a procurement checkbox for the end of the process — it’s selection criteria. Not because any serious vendor skips the fundamentals; most don’t. It’s that the variance hides in the specifics that bite later — whether SSO is a paid tier, whether the audit trail exports without a services call, whether there’s a real report behind the badge on the website — and those answers are much easier to get while vendors are still competing for your business. LIMS security, concretely, is: who can reach your test data, how it’s protected in transit and at rest, what gets logged when it changes, and what happens the day a server dies or you decide to leave.

Get written answers to seven things:

1. Where does our data physically live, and who besides us can access it?
2. Is data encrypted in transit and at rest?
3. Does SSO work with our identity provider, and is it a paid tier? Is two-factor available for accounts outside SSO?
4. How granular are roles and permissions — can a requester see only their own projects? Can we restrict a customer-sensitive program to named users?
5. What does the audit trail record, and can we hand it to an assessor without a services engagement?
6. What is the backup schedule, and when did you last test a restore?
7. What attestations exist — SOC 2, ISO 27001 data centers — and can we see the report, not the badge?

Ours are published on the security page — US-based storage in ISO 27001 data centers, encryption in transit and at rest, daily backups with tested restores, SAML SSO, a full audit trail, SOC 2 Type II in progress. For the longer treatment of what each of those means and why it matters in a lab, see our post on LIMS and data security.

Run the evaluation like a test plan

You already know how to do this part — it’s what your lab does all day. Define the procedure, run it identically against each candidate, record results.

Shortlist three or four, no more. You can disqualify most of the long list from vendors’ websites alone: no pricing anywhere, no screenshots of the real product, no customers that resemble you. (We publish prices and real screenshots precisely so labs can do this triage without a sales call — and because in this market, almost nobody else does.)

Script the demos. Send your requirements document ahead and ask each vendor to demo your workflow: a request arriving the way yours arrive, a job scheduled, results entered, a failure handled, your report produced. Note what gets configured live versus what’s answered with “that’s on the roadmap.” Roadmap answers are noes with better manners.

Bring a real report. The report is what leaves the lab; it’s the artifact your requesters and their managers judge you on. Hand each vendor one of your finished reports and ask to watch it rebuilt in their system — sections, sample tables, results, sign-off. If the answer involves professional services, get the price of that answer now, not in month three.

Trial with real work, in parallel. A demo shows what’s possible; only a trial shows what’s usual. Run two to four weeks of real jobs through the system alongside your current process, with success criteria written down first: a requester submits without help by day three, a tech enters a full job’s results without opening the manual, the monthly report takes minutes. Count clicks on the three paths people will walk fifty times a week. This is also your best read on the vendor: how fast questions get answered during a trial is the best support data you’ll ever collect, because you’re seeing them at their most attentive.

Check references that look like you — same industry, similar size, at least a year live. Ask whether the implementation landed where the quote said it would, what broke first, and what they’d ask now that they didn’t ask then. Skip “what do you pay” — deals age and pricing changes, so another customer’s number tells you nothing about your quote; whether the vendor’s quotes come true tells you plenty. On support, be specific about expectations: who answers (an engineer who knows your configuration, or a ticket queue), how fast for a question versus an outage, whether support is included or a tier. And ask for release evidence — a public changelog tells you whether the product moves and whether updates arrive without an upgrade project.

Budget with the full arithmetic

Pricing models vary more than products do: per-user subscriptions, perpetual licenses plus maintenance, tiered “editions,” per-module pricing, and quotes that exist only after three calls. We’ve written a whole post on what a LIMS costs and how to compare the models, so the short version here:

• Compare five-year totals, not year one. Licenses front-load, subscriptions don’t, and the crossover math is meaningless until implementation, maintenance, infrastructure, and upgrades are in both columns.
• Price the requester seats. For an in-house lab this is the number that decides whether your engineers are actually in the system. Full-price seats for occasional requesters quietly push labs back to email. It’s why we price requester seats at $45 against $300 for lab seats — the request-and-track role is a different job and should cost like one.
• Get implementation quoted up front, in writing. Ours is scoped before you commit — for many labs it’s zero; when it isn’t, you know the number first. Any vendor can do the same; the ones who won’t are telling you something.

Red flags we’d walk away from

Any one of these is survivable. Two or more and we’d quietly shorten the shortlist:

• No pricing anywhere, and no willingness to give a real number on the first call.
• No screenshots of the actual product on the website — renders and stock photos instead.
• No trial, under any conditions, even after a serious demo.
• Every hard question answered with “it’s configurable.” Translation: consulting hours.
• Interface and integration prices that only appear after the demo — per-instrument charges can double a quote.
• Requester or read-only users priced like full seats — see above; this one decides adoption.
• References all come from a different kind of lab than yours.
• Customers run different versions — ask who schedules upgrades and what the last one cost; the answer is your future.

A 90-day selection plan

Selection expands to fill whatever time it’s given, so give it a quarter:

Weeks	Work
1–2	Requirements document; stakeholder team named (use the RACI builder); IT’s security questions collected
3–4	Long list to shortlist of 3–4 using website evidence: pricing, screenshots, customers like you
5–8	Scripted demos against your requirements; trial with real parallel work and written success criteria
9–10	References, security review, support and SLA answers in writing
11–12	Decision, five-year budget, and an implementation plan with dates — our implementation guide covers that next chapter

LIMS selection FAQ

How do I choose a LIMS for my lab?

Write a short requirements document first — how work arrives, what you test, the reports you must produce, your instruments, your compliance posture. Shortlist three or four vendors whose current customers resemble your lab, make each demo your workflow rather than their standard tour, then trial the finalists with real work against written success criteria. Requirements, demos, trial, references — in that order.

What should a LIMS requirements checklist include?

Nine areas: how test requests arrive, samples and test types with volumes, scheduling and assignment, results entry and review, the reports the lab must produce (attach real ones), equipment and calibration tracking, instrument and ERP integrations, users and security including SSO, and compliance context such as ISO 17025. Concrete artifacts — real requests and real reports — beat feature checklists.

Which LIMS requires minimal IT involvement for daily operations?

A multi-tenant SaaS LIMS. The vendor hosts, patches, backs up, and updates the system, so IT’s role shrinks to single sign-on setup and a one-time security review rather than a standing responsibility. On-premise and self-hosted open-source systems put servers, backups, and upgrades on your IT team permanently. LIMSey is fully SaaS — daily operations need no IT involvement at all.

What SLAs and support coverage should a lab expect from a LIMS vendor?

In writing: response times by severity (hours for the system being down, a business day for questions), who actually answers — someone who knows your configuration, or a tier-one queue — whether support is included or a paid tier, and the release cadence with a public changelog as evidence. Test all of it during the trial, when the vendor is at their most responsive; it only gets slower after the contract.

How do I choose a LIMS for a multi-location laboratory network?

Favor a cloud LIMS — one current version, no per-site servers — and check three things: permissions that can scope users, equipment, and jobs by site while letting management see across all of them; reporting that rolls up per-lab and network-wide; and per-user pricing that doesn’t charge per site. Then run the trial from your most remote location, not headquarters.

What are the main types of LIMS systems?

By deployment: multi-tenant SaaS, vendor-hosted single-tenant, and on-premise. By market: enterprise platforms aimed at pharma QC and clinical labs, vertical products built for one kind of lab (LIMSey is one, for engineering and materials test labs), open-source systems where configuration and hosting are your time, and custom in-house builds. Match the vendor’s center of gravity to your lab before comparing features.

How long does LIMS selection take?

About ninety days of part-time work for an in-house lab: two weeks on requirements and stakeholders, two to shortlist, four for scripted demos and a real-work trial, two for references and the security review, and two to decide and plan implementation. Selections that run longer usually skipped the requirements document and are re-deriving it one demo at a time.

Make the vendors work through your lab

The whole method compresses to one sentence: describe your lab precisely, and make every vendor respond to the description. If your lab is an in-house engineering or materials test lab, we’d like to be on the shortlist — book a demo, send us the requirements document from the first section, and we’ll run the demo against it: your request flow, your reports, your instruments, with pricing you can check before we ever talk.