Most clinical and specialty labs change LIS once or twice a decade. The transition is not glamorous work, but it shapes go-live more than any other implementation activity. This post walks through what data actually has to move, what can stay behind, and how to design a migration the inspector and the bench will both sign off on.
Why migrations fail (and how to avoid it)
Common failure patterns:
- Migrating everything. Trying to move every historical result into the new system can turn migration into an open-ended archaeology project. Scope history around clinical use, retention obligations, decommissioning plans, and the data the bench actually needs.
- Migrating nothing. Cutting all historical context creates problems on day one — providers calling about prior results, billing chasing claims that have no source data, QC trends starting from scratch.
- Doing the mapping in spreadsheets only. Order codes, units, reference ranges, and panel definitions are deceptively easy to map on paper and brutal in production when an OBX comes through with the wrong unit.
- No risk-based rehearsal. Skipping representative migration loads, reconciliation, and end-to-end validation leaves mapping and workflow defects to surface during cutover.
A working migration plan answers six questions clearly: what comes forward, in what shape, by when, validated how, owned by whom, and rolled back how.
The data classes a real LIS migration touches
Group source data into classes — each has its own migration pattern.
1. Master / configuration data
This is the foundation: test catalog, panels, reflex rules, reference ranges, units, specimen requirements, ordering codes, payer setups, fee schedules, user accounts, role definitions, and printer/router config.
- Pattern: rebuild in the new LIS, do not migrate. Use the legacy system as the source of truth, but configure deliberately. This is the single best opportunity in a decade to clean up the catalog.
- Risk: legacy systems accumulate dead orderables — drop them.
- Validation: order each panel against test specimens; confirm units, ranges, and reflex behavior end-to-end.
2. Patient demographics
Active patient records — name, MRN, DOB, sex, addresses, contact, insurance.
- Pattern: define the active subset around the lab’s patient mix, longitudinal-result needs, retention policy, and legacy-access plan. Pre-cleanse before migration: deduplicate, normalize phone formats, and fix obvious DOB errors.
- Risk: MRN collisions and duplicate patient records that look identical except for a stray space.
- Validation: spot-check counts by clinic, month, and insurance plan; reconcile against EMR ADT feeds.
3. Active orders & specimens in flight
Orders received but not resulted — the work-in-progress at cutover.
- Pattern: drain the queue before go-live where operations allow it. Where testing cannot pause, define exactly which active orders move, which finish in the legacy LIS, and how status, accession number, and specimen-tracking state will be reconciled.
- Risk: specimens with split barcodes, or accession numbers that overlap with a new accession sequence in the new system.
- Validation: confirm every active accession after migration is countable on bench reports.
4. Historical results
The biggest decision and the biggest data volume.
- Common patterns:
- Read-only archive. Keep the legacy system available in read-only mode for the period defined by the lab’s retention and access plan. This avoids transforming every historical result but may require a continuing legacy-vendor contract.
- Selective migration. Bring forward the result history needed for active-patient context, delta checks, and trends. Define the cutoff by clinical use and policy rather than a universal number of months.
- Full migration. Migrate all historical results when the legacy system must be fully decommissioned and the lab has accepted the added mapping, validation, and storage scope.
- Risk: historical results are loaded with reference-range, unit, and method changes over time. Do not let those drift into the new test catalog through migration.
- Validation: result counts by year, by analyzer, by panel — reconcile to legacy reports.
5. QC history
Levey-Jennings continuity matters because Westgard rules look at the last N points.
- Pattern: migrate the QC history required to establish the lab’s chosen continuity and review baseline. Confirm the amount with the laboratory director and quality team, because the necessary window depends on lot changes, instrument history, configured rules, and the legacy-access plan.
- Risk: lot numbers, control IDs, and instrument IDs all need to match the new configuration exactly.
- Validation: rebuild a Levey-Jennings chart in the new system and confirm it matches legacy.
6. Documents & images
Result PDFs, requisition images, chain-of-custody documents.
- Pattern: migrate by reference (link to legacy storage) where possible. Full migration only when the legacy system is going away.
7. Billing / claims data
Charges in flight, accounts receivable, write-offs, denial history.
- Pattern: typically does not migrate into the LIS. The billing/RCM partner handles AR continuity. The LIS migrates the test catalog, payer rules, and modifiers — not the historical claim ledger.
- Risk: double-billing or missed billing during the cutover window.
A migration plan with readiness gates
Migration is one workstream inside the broader implementation. LIMS IQ projects are phased from discovery through configuration, interfaces, validation, training, and go-live, but the schedule is scoped to the lab’s catalog, sites, interfaces, historical-data decision, validation depth, training plan, and partner readiness. Use exit gates instead of assuming a fixed week count:
| Phase | Work | Ready to advance when |
|---|---|---|
| Scope | Choose each data class, owner, source, destination, archive plan, and cutover pattern | The lab approves what moves, what stays, and how retained data will be accessed |
| Extract & cleanse | Obtain representative source files; profile duplicates, missing fields, encodings, and code drift | Source counts and known data-quality exceptions are documented |
| Configure & map | Build the target catalog, panels, ranges, rules, users, sites, interfaces, and crosswalks | High-volume and high-risk records map to active target definitions |
| Rehearse | Load a non-production extract; run order-to-report paths and reconciliation reports | Counts, exceptions, and deliberate differences have named owners and acceptance criteria |
| Validate & train | Execute the lab’s approved validation cases and train each operating role | The laboratory director accepts the validated scope and staff can run the cutover workflow |
| Cut over | Freeze or delta-extract approved sources, route interfaces, reconcile in-flight work, and activate the target | Orders, specimens, results, reports, and interface acknowledgments reconcile to the cutover plan |
| Stabilize | Monitor queues, exceptions, support issues, and legacy access against agreed exit criteria | The lab approves steady-state operation and closes or transfers remaining migration items |
Extraction patterns
Most legacy LIS vendors offer one of three export options:
- Native export (CSV/HL7 batches). The cleanest option when available. Watch for character-encoding issues and truncated free-text fields.
- HL7 ORU replay. Works well for results — point the legacy outbound interface at the new LIS during a controlled replay window.
- Database extract (SQL). Most flexible but requires the legacy vendor’s cooperation or DBA access. Capture the schema, not just the rows.
Always extract twice: once early for mapping, once close to cutover for currency.
Mapping that survives go-live
A few practices that separate mappings that work from mappings that fail:
- Build the mapping in the new LIS, not in a spreadsheet. Every legacy code maps to a real test definition the lab can order against. This catches missing reflex rules, wrong units, and reference-range gaps early.
- Walk the path from order to report. For each high-volume orderable, do a full path test: order entry → accessioning → instrument → resulting → autoverification → reflex → report → HL7 ORU back to the EMR.
- Use legacy reports as ground truth. Run the same date range in legacy and new — counts of accessions, results, panels, and QC points should match within an explainable delta.
- Document the diffs. Every place the new test catalog deliberately differs from legacy gets a written rationale, signed off by the lab director. CAP inspectors will ask.
Parallel running
Where the lab chooses parallel operation, define the window from validation and cutover risk rather than a universal duration. During parallel:
- Some test menus run on the new LIS, others on the legacy. Pick by analyzer or by ordering source.
- Daily reconciliation: order counts, result counts, ack counts, autoverification rate, denial rate.
- A war room or daily huddle with bench leads, IT, and the LIMS IQ team. No defects close without a documented owner.
A good parallel period exposes issues — that is the point. Use it.
Cutover patterns
Three common shapes:
- Hard cutover. All testing flips on a single date; legacy goes read-only the same day. Lowest cost; highest risk. Works best for focused single-site labs with a small interface footprint.
- Phased by specialty / analyzer. Move chemistry first, then hematology, then molecular. Reduces blast radius; extends the migration window.
- Phased by site. Most common for multi-site groups. Each site cuts over on its own date, with a stable HQ tenant during the rollout.
The right shape depends on the lab’s risk tolerance, EMR partner schedule, and the depth of interface re-build.
Rollback — plan for it, even if you never use it
A real rollback plan covers:
- The cutover checkpoint after which rollback is no longer operationally safe, based on interface routing, orders placed, results released, and data entered in the new LIS.
- Who decides rollback (lab director, with the LIMS IQ team).
- What “rolling back” actually means: legacy goes back to read-write, new LIS goes to read-only, in-flight specimens get reconciled, EMR routing reverts.
- Communications: clients, EMR partners, billing/RCM, and any reference labs.
A defined rollback plan makes the cutover decision explicit before production pressure narrows the available options.
What to scope with the LIMS IQ migration team
LIMS IQ onboarding includes expert legacy-data migration within a phased implementation, alongside instrument connectivity, report configuration, training, and go-live support. The exact migration artifacts depend on the source system and contracted scope. During discovery, document who will provide and approve:
- Legacy access, exports, field definitions, and vendor coordination.
- Target configuration for the test catalog, panels, and ranges, rules, users, sites, and reports.
- Transformation rules and migration tooling for each approved data class.
- Rehearsal loads, reconciliation reports, exception handling, and acceptance criteria.
- Interface-routing changes, the in-flight specimen plan, cutover communications, and post-go-live support.
The lab retains ownership of clinical and operational decisions, validation approval, retention policy, and readiness to go live. Confirm the deliverables, owners, and sign-off records for the specific implementation rather than assuming every migration uses the same archive, parallel-run, or cutover package.
Next steps
- Planning the bigger picture: LIS implementation timeline.
- Comparing cloud vs on-prem for the destination platform: cloud LIS software guide.
- Evaluating vendors: LIS Buyer’s Guide.
- Or, walk through your specific legacy migration: request a demo.