Migrating from a legacy LIMS: what actually changes

Most public health labs are not choosing between a good system and a better one, they are choosing between a system built for a hospital and one built for public health. Legacy LIMS platforms are typically adapted from clinical, hospital-oriented software, retrofitted over years to handle accessioning surges, state ELR feeds, and surveillance workflows they were never designed for.

Salus was built from the ground up for public health workflows: high-volume batch intake, lab-defined test building with LOINC and SNOMED coding, state ELR feeds, and surveillance, rather than adapted from a clinical hospital system.

Migration is treated as a first-class part of onboarding, not a task a lab is left to figure out alone. Legacy structures, tests, result sets, specimen histories, and reference data, are mapped into the modern, normalized Salus schema as part of implementation.

Because every test a lab runs is rebuilt in the Test Builder with its acceptable result set, reference ranges, and interpretive logic, and assigned LOINC for the observation and SNOMED CT for coded results and organisms, migration is also a natural point to clean up years of ad hoc test configuration, not just carry it forward unchanged.

Three things move: test and result-set definitions (rebuilt with proper coding, not just copied), historical specimen and result data (mapped into the new schema so history stays queryable), and interoperability configuration, ELR identifiers, facility details, and instrument interfaces, which live in configuration rather than code so onboarding a new feed does not require a new build.

What does not move automatically: your lab's actual workflow decisions. Reflex-testing rules, routing logic, and report templates are configured deliberately during onboarding, which is also the point where automation rules from the legacy system can be reconsidered rather than blindly replicated.

A typical path: map and validate test definitions and historical data first, stand up ELR to at least one destination end to end, then bring accessioning live for a subset of specimen types before cutting over fully. Reflex rules, reporting templates, and analytics dashboards are layered in once the core accessioning-to-result path is proven.

Because tests, workflows, and report templates are shareable, versioned artifacts inside Salus, a configuration that works well for one lab in a network can be published for the next lab to adopt, so a second or third migration in the same state moves faster than the first.