Cloud or On-Premises LIMS: The Decision Is Not About Security
The security conversation is usually standing in for a question about who administers the system. Name the three constraints that genuinely differ and the choice gets simpler.
In brief
The cloud vs on premise LIMS decision is rarely settled on security. Three constraints decide it: who patches and holds administrator rights, what your laboratory does when the system is unavailable, and whether a budget exists yet. Most labs asking are migrating from an existing system rather than digitising.
Key takeaways
- About a third of labs asking are replacing a system, not digitising. Migration cost is history and validation, not hosting.
- The security argument is usually about administration. A shared admin login on an instrument PC is an FDA finding either way.
- Ask whether your system can export QC rules and specification limits for offline use. One published outage ran 25 days.
- More than half of labs making contact have no approved budget. Until someone is named to run the project, the model can wait.
- On-premises remains right for sovereignty rules, legacy serial instrument connections, and organisations with real IT staff.
Almost nobody decides this on security, whatever the meeting sounds like. The laboratories that stay on-premises mostly do so because switching feels risky and the system they have still works, and that is a legitimate reason nobody says out loud because it sounds like inertia.
Say it out loud and the decision gets easier, because it can then be weighed against the three constraints that genuinely differ between the two models: who administers the thing, what happens when it is unavailable, and whether anyone has approved any money. This covers what a hosted LIMS actually is, those three constraints in order, where on-premises is still the right answer, and what the deployment decision does not decide.
What is a hosted LIMS, and how does it differ from on-premises?#
The vocabulary is muddier than the choice. Cloud, hosted, web-based and SaaS are used almost interchangeably for a LIMS, and in practice they describe one arrangement with variations in who owns the tenancy. On-premises is the other arrangement. The difference is where the server sits and, far more importantly, who is responsible for it.
| Hosted, cloud or SaaS | On-premises | |
|---|---|---|
| Where it runs | The vendor’s or a cloud provider’s data centre; you reach it through a browser | Your own server room or corporate data centre |
| Who administers the platform | The provider: patching, backups, availability, database upkeep | Your IT function, or the one person who set it up |
| How it is paid for | A subscription, scaled by users, samples, sites or modules | A licence plus the hardware, and the people to run it |
| What you still own either way | Configuration, validation, the data model, the audit trail review | The same list, plus the infrastructure |
| What changes about compliance | Nothing. 21 CFR Part 11 and ISO/IEC 17025 obligations apply identically to both | |
Two things on that table are the whole argument. The compliance row is identical, which is why the security conversation is usually about something else. And the administration row is where the models actually differ, which is why that is the first constraint below. Lab management cloud hosting describes the hosted arrangement in detail; how a LIMS works is the same on either model.
What are you replacing?#
Answer this before the deployment question, because it changes the size of the project more than the hosting model does.
In LabLynx’s own inbound enquiries, roughly a third of laboratories describing their current situation already run a LIMS, an LIS or a named laboratory product. Only about one in eight describes paper or notebooks. The recurring phrasing is not “we have nothing” but “we have one and it is outdated”, or “ours will be terminated in about four years”.
That matters because a migration carries costs a greenfield build does not, and none of them are hosting costs.
- The history that does not come across. One published genetics migration review of 461 charts found a 92 percent concordance rate still concealed nine incorrect test results and nineteen records with missing information. Measure migration quality field by field, not by a completeness percentage.
- The validation package. It has to be rebuilt against the new system regardless of where the new system runs. Validation services covers how that work is split between vendor and lab.
- The naming decisions. If two departments call the same test different things today, a new system industrialises that rather than fixing it.
Laboratory data migration is the page for the first of those, and it is the one that decides the timeline.
Who is going to administer it?#
This is the axis the security conversation is usually standing in for. The honest questions are who applies patches, who holds administrative rights, and who is awake when something fails at two in the morning.
An FDA warning letter of 23 January 2025 makes the point without any argument from us. Investigators found computers controlling instruments and storing raw data with insufficient controls: various users shared one login ID with full administrative access, on equipment also used for teaching. That finding is equally available on either deployment model. It is a question of who administers, not where the server sits.
| Question | Hosted | On-premises |
|---|---|---|
| Who patches the operating system and database | The provider, on their schedule | You, on yours, if someone remembers |
| Who holds administrator rights | Scoped by the provider, auditable | Whoever it was given to, often years ago |
| Who responds out of hours | A rota you pay for | A person, usually one, sometimes on leave |
| What a software update can change | Announced, and still worth reading | Deferred, then applied in a batch |
That last row of the table is not hypothetical. An FDA letter of 14 April 2026 records a laboratory whose access restrictions were bypassed after a software update, with deleted sequences found in a recycle bin, and the firm’s response of disabling automatic updates was judged inadequate. Identity and access management is the same control on either model; the question is who owns it.
What happens when the system is unavailable?#
Both models have an answer and neither answer is nothing. The published account worth reading is a US academic medical centre that lost its records system and integrated laboratory system to a cyberattack in October 2020 and ran without them for 25 days.
What broke is specific. Providers could not order electronically, so the laboratory ran on paper requisitions with no collection date and time and no unique patient identifiers. The pneumatic tube system depended on a networked server. Aliquoting and centrifugation on the automation line were unavailable. And quality control ranges and rules were no longer available, so each discipline reprogrammed QC into the analysers by hand.
| What went down | What the lab fell back to | Ask this of either model |
|---|---|---|
| Electronic ordering | Paper requisitions with no collection time and no unique identifier | Can we print a requisition that still carries the identifiers? |
| Quality control rules | Each discipline reprogrammed QC into the analysers by hand | Can we export QC rules and specification limits for offline use? |
| Automation line | Manual aliquoting and centrifugation | What is our manual throughput ceiling per shift? |
| Pneumatic tube | Walking | Which non-obvious systems depend on the network? |
The transferable question is not which model is safer. It is whether your system can export its QC rules and specification limits into a form you could use offline, because consolidation moves risk rather than removing it. Ask that of either model and you will learn something.
What if nobody has approved any money yet?#
More than half of laboratories making first contact tell us plainly that no budget has been established. Fewer than one in ten say a budget exists.
If that is you, the deployment question is premature and answering it will not move you forward. What moves you forward is scoping what is being replaced, and naming who will run the project alongside their existing job. Laboratories are expected to introduce new systems at steady-state staffing, so that person exists and is already busy. Get their name into the business case before the hosting model.
When the pricing conversation does come, the models are priced differently and the difference is structural rather than a discount. A hosted system is a subscription, and the variable that scales it — named users, concurrent users, samples per year, sites, modules — is the number to ask about at 150 percent of today’s volume, because that is the figure that matters in year three. An on-premises system is a licence plus the infrastructure and the people to run it, and the second half of that is the part quotes leave out. Neither is cheaper in the abstract; each is cheaper for a particular laboratory, and the administration question above is usually what decides which.
Where is on-premises still the right answer?#
It is a live option, not a legacy one, and three cases are clear.
Where data sovereignty rules or a written internal policy prohibit external hosting, the decision is made for you and the rest of the argument is academic. Where instrument connections are heavily customised or depend on legacy serial interfaces that assume a local network, the integration work can exceed anything the hosting model saves. And where the organisation already runs comparable systems with real IT staff, the marginal cost of one more is genuinely low.
- A data sovereignty rule or written internal policy prohibits external hosting
- Instrument connections depend on legacy serial interfaces that assume a local network
- The organisation already runs comparable systems with staffed IT and an out-of-hours rota
- A validated system is mid-cycle and the revalidation cost exceeds anything hosting would save
Then the honest version of the inertia argument. A working system that nobody is fighting has real value, and a migration spends that value before it returns any. Building the business case is easier when that cost is stated rather than treated as embarrassing.
What does the software decision not decide?#
It does not decide whether you are compliant. Most of what assessors cite is quality system work no system performs. It does not decide whether the project is staffed. And it does not decide your data model, which is the thing that will still be shaping what you can ask three years from now.
| Decides the model | Does not decide the model |
|---|---|
| Who patches and holds administrator rights | Whether your data is sensitive |
| What you do during an outage | Whether you are compliant |
| Whether a sovereignty rule applies | Whether the project is staffed |
| How customised the instrument connections are | What your data model should be |
If your work is regulated, the 21 CFR Part 11 obligations apply identically to both models: the audit trail has to keep the prior value, and somebody has to review it, wherever the server sits. Types of LIMS covers the selection questions that sit around this one, and the deployment question is the last of them to answer, not the first.
What a LIMS carries in this work#
The same record on either model: the sample as the unit of record, the audit trail that keeps the prior value, the QC rules and specification limits that should be exportable before the day you need them offline, and the validation evidence that has to be rebuilt against the new system whether it runs down the hall or in a data centre. The deployment model changes who keeps the lights on. It does not change what the system has to hold.
Frequently Asked Questions #
What is a hosted LIMS solution?
A LIMS that runs in the vendor's or a cloud provider's data centre and is reached through a browser, with the provider responsible for patching, backups and availability. Cloud, web-based and SaaS describe the same arrangement with variations in who owns the tenancy. Configuration, validation, the data model and audit trail review remain the laboratory's on every model; only the infrastructure moves.
Is a cloud LIMS less secure than on-premises?
That is rarely the question that decides it; the honest comparison is about administration rather than location. The FDA finding that recurs, one shared login with full administrative rights on a computer that also stores raw data, is available on either model. Ask who patches, who holds administrator rights and who is awake at two in the morning.
What should we decide before choosing a deployment model?
What you are replacing. Roughly a third of laboratories asking about systems already run one, which makes the project a migration with costs unrelated to hosting: history that does not transfer cleanly, a validation package that must be rebuilt, and naming conventions a new system will industrialise rather than fix. Size that work first; the hosting model is the smaller decision.
What happens to a laboratory when its system is unavailable?
More than most plans assume. A published account of a 25-day outage at a US academic medical centre records paper requisitions with no collection times or unique identifiers, an automation line reduced to manual aliquoting, and each discipline reprogramming QC rules into analysers by hand. The transferable question for either model is whether QC rules and specification limits can be exported for offline use.
When is on-premises still the right choice?
Three cases are clear. Where data sovereignty rules or written internal policy prohibit external hosting, the decision is made for you. Where instrument connections depend on legacy serial interfaces that assume a local network, integration work can exceed any hosting saving. And where the organisation already runs comparable systems with staffed IT and an out-of-hours rota, one more system costs genuinely little.
We have no budget yet. Does the deployment model matter?
Not yet. More than half of laboratories making first contact say no budget has been established, and for them the deployment question is premature. What moves the project forward is scoping what is being replaced and naming the person who will run it alongside their existing job. Get that name into the business case; the hosting model and its pricing structure come after.
Sources and references
- Warning Letter 696906, Center of Instrumental Analysis, China Pharmaceutical University U.S. Food and Drug Administration
- Are You Prepared? Laboratory Downtime in the Wake of a Cyberattack American Journal of Clinical Pathology (2022)
- Lessons learned in migrating from one commercial laboratory information system to another PubMed Central (2025)
