Replacing a LIMS is a different project from implementing one for the first time. You are not starting from a blank page: you have years of results, specifications, audit trails and signed records that must remain trustworthy, and a lab that cannot stop testing while you work. Labs move off a wide range of platforms, including established commercial systems such as STARLIMS, LabWare, LabVantage and Thermo SampleManager, as well as homegrown databases and spreadsheet-based tools. The reasons are usually about lifecycle and fit rather than any single product: an aging version that is expensive to upgrade, customizations that have accumulated over many years, consolidation after a merger, a move to cloud infrastructure, or new requirements the current setup was never designed for. Whatever the starting point, the same disciplines apply. This playbook walks through each phase, from assessment to decommissioning, with the decisions and pitfalls that matter most.
Key takeaways
- Migration is a data quality and validation project as much as an IT project. Involve QA and data owners from day one.
- You do not have to migrate everything. Decide deliberately what moves, what is archived and how archived records stay readable for their full retention period.
- Redesign master data rather than copying it. A new system is the best opportunity you will have to clean up specifications, methods and naming.
- Run repeated trial migrations and reconcile every one. The first full load should never be the production load.
- Plan cutover around in-flight work, especially long-running stability studies and open investigations.
- Keep legacy records retrievable until their retention periods end, and test that retrieval actually works.
Phase 1: Assessment and planning
Start by understanding what you have, not what the original documentation says you have.
- Inventory the current system. Modules in use, sites and labs, user counts, interfaces (instruments, ERP, CDS, label printers), reports and CoA templates, scheduled jobs and every customization.
- Profile the data at a high level. Record counts by entity, date ranges, database platform and version, and any data held outside the LIMS in spreadsheets or shared drives that people treat as part of the record.
- Find out what is actually used. Long-lived systems accumulate fields, reports and workflows nobody touches. Usage logs and interviews will tell you what matters.
- Establish governance. Name a business owner, a system owner, a QA representative and a data owner for each major domain (products and specifications, methods, stability, environmental monitoring and so on). Data owners make the decisions about what is correct.
- Define the regulatory scope. Identify which records are GxP-relevant and which regulations apply, because that drives the depth of validation for the migration.
The output is a migration strategy, usually documented in a data migration plan that sits under the overall validation plan. It should state scope, approach, roles, acceptance criteria and how deviations will be handled.
Phase 2: Data inventory and cleansing
Detailed profiling almost always reveals problems that are invisible during day-to-day use:
- Duplicate products, customers or methods created under slightly different names
- Free-text fields used to hold information that should be structured
- Inconsistent units, decimal precision or date formats
- Obsolete master data that is still marked active
- Orphan records, such as results whose parent sample was deleted or renamed
- Specification versions without clear effective dates
There are two ways to fix these issues, and each has implications.
Cleansing in the source system means correcting records in the legacy LIMS before extraction. In a GxP system this is itself a regulated change: it needs change control, it will appear in the audit trail, and it should be approved by the data owner.
Transforming in flight means applying documented rules during migration, for example mapping three spellings of a unit to one controlled value. This leaves the source untouched, but every rule must be specified, reviewed, tested and traceable in the migration documentation.
Most projects use both. Whatever you choose, keep a cleansing log so that an auditor can follow how any migrated value relates to its original.
Phase 3: Decide what to migrate and what to archive
This is the most consequential decision in the project, and it should be made by the business and QA together, not by default.
| Option | What it means | Advantages | Drawbacks |
|---|---|---|---|
| Full historical migration | All records move to the new system | One place to search and trend | Highest effort, cost and validation burden; old data quality issues come along |
| Selective migration | Master data, open work and a defined window of history move; older records are archived | Balances continuity with effort | Requires a clear rule for what is “in” and a working archive for the rest |
| Archive in place | The legacy system stays available in read-only mode | Records remain in their original context | Ongoing infrastructure, licensing, security and support for an aging platform |
| Export to an archive repository | Records, metadata and audit trails are exported to a controlled repository in readable formats | Retires the legacy system while retaining records | Must preserve context and audit trails; retrieval must be tested and maintained |
Keeping legacy records readable
Retention obligations do not end when a system is retired. Regulations expect records to be retrievable, readable and complete, including their metadata and audit trails, for the full retention period. The relevant expectations include 21 CFR 11.10(b) and (c) on producing accurate copies and protecting records for ready retrieval, the archiving section of EU GMP Annex 11, and record retention provisions such as 21 CFR 211.180 for drug cGMP records and 21 CFR 58.195 for GLP studies, alongside your own retention schedule.
Practical points:
- An archive is only useful if you can find and read records in it. Define how an inspector’s request for a specific batch or study would be answered, then test it.
- Preserve the audit trail and electronic signature information with each record, not as a separate, disconnected file.
- If the legacy system stays in read-only mode, harden it: restrict access, remove write permissions, keep it patched or isolated, and include it in periodic review.
- Schedule periodic retrieval checks for the life of the archive.
Criteria for the decision
Consider how often older records are consulted, whether you need to trend across old and new data (stability programs and annual product reviews are common examples), the complexity of the records, the quality of the legacy data and the cost of each option over the retention period.
Phase 4: Map master data
Master data determines how the new system behaves, so mapping it deserves more attention than mapping transactional records.
| Master data domain | What to watch for |
|---|---|
| Products, materials and sample types | Duplicates, naming conventions, retired items |
| Specifications | Version history, effective dates, limits, reporting and rounding rules, market or grade variants |
| Methods and test definitions | Components, units, calculations, replicate handling, method versions |
| Test plans and stability protocols | Pull points, conditions, linked specifications |
| Instruments and equipment | Identifiers, calibration and maintenance status, links to methods |
| Reagents and standards | Lot tracking, expiry, preparation records |
| Users and roles | Re-provision accounts and roles in the new system; do not migrate passwords |
| Customers, sites and locations | Hierarchies, addresses, contact details |
| Lists of values and codes | Units, reasons for change, status codes |
Three principles help:
- Redesign, do not replicate. Model master data the way the new system is designed to use it, and resist rebuilding workarounds that existed only because of old limitations.
- Preserve historical meaning. Historical results must stay linked to the specification version that was in force when they were evaluated, not to today’s limits.
- Re-verify calculations. Recreated calculations must produce the same results, with the same rounding and significant figures, as the originals.
Capture all of this in a mapping specification that lists each source field, its target, the transformation rule, the responsible owner and how it will be verified.
Phase 5: Trial migrations and parallel running
Trial migrations
Build the extraction and load process early and run it repeatedly in a non-production environment. Each trial run should be reconciled, should feed defects back into the mapping rules, and should be timed so you know how long the production cutover window needs to be. By the final rehearsal, the process should run end to end without manual intervention.
Parallel running
Running both systems side by side sounds reassuring, but full parallel operation means analysts enter everything twice, which is costly and introduces its own discrepancies. Alternatives are often more effective:
- Parallel testing: Re-run a representative set of historical samples through the new system’s configuration and compare results, specification evaluations and reports with the originals.
- Time-boxed pilot: Run a single lab or product line in the new system for a defined period while the rest continue in the legacy system.
Whichever approach you choose, define acceptance criteria in advance and set an end date.
Phase 6: Validate the migrated data
EU GMP Annex 11 expects that when data is transferred to another format or system, validation includes checks that the data is not altered in value or meaning. Migration validation is typically planned and reported as part of the overall system validation, with a risk-based depth of testing. Our article on moving from CSV to CSA covers how to apply risk-based thinking.
Common verification techniques include:
- Record count reconciliation for each entity, between source extract, transformed data and target
- Checksums or control totals on key numeric fields
- Field-level comparison of critical data such as results, limits, statuses, dates and signature information, often for every record
- Statistical sampling for lower-risk data, with a documented sampling rationale
- Automated comparison scripts, which themselves need to be verified before you rely on them
- Visual review of rendered records, reports and CoAs, to catch formatting and display issues
Pay attention to the details that cause subtle errors: time zones, date formats, character encoding, numeric precision and how migrated electronic signatures are represented. A signature applied in the legacy system cannot be re-executed; it should be carried over as historical information and clearly identified as migrated.
The migration report summarizes what was migrated, what was archived, the results of every verification activity and how each deviation was resolved. Our data integrity and ALCOA+ article explains the attributes migrated records still need to demonstrate.
Phase 7: Cutover
Big bang or phased
| Strategy | How it works | Best suited to | Main risks |
|---|---|---|---|
| Big bang | All labs and sites move at once | Single sites, smaller labs, tightly integrated workflows | Problems affect every lab at once; heavy support load at go-live |
| Phased by site or lab | One site or lab at a time | Multi-site organizations, labs with different processes | Temporary interfaces between systems; longer overall timeline |
| Phased by module or workflow | Core testing first, then stability, environmental monitoring and so on | Labs with distinct, separable workflows | Data split across systems during the transition |
Handling in-flight work
Decide early how open work will be handled. Two common approaches are a run-down, where work started in the legacy system finishes there while new work starts in the new system, and migrating open records at their current status. Long-running stability studies deserve special attention. Some labs complete existing studies in the legacy system, while others migrate them with their full history so pulls and trending continue in one place. Either can work if the decision is documented and justified.
The cutover plan
A cutover plan should include a data freeze, the final delta migration, verification steps, interface switchover (ERP, instruments, label printers), explicit go/no-go criteria, a rollback plan and a hypercare period with extra support on hand. Rehearse it.
Phase 8: Hypercare and decommissioning
After go-live, monitor closely, track issues and support users through the first review and release cycles. Then retire the legacy system with a documented decommissioning plan: confirm the archive is complete and retrievable, remove or restrict access, update SOPs and the system inventory, and close out validation documentation.
Common pitfalls
- Underestimating data cleansing. Problems found during the first trial load can reshape the timeline.
- Defaulting to “migrate everything.” It increases cost and validation effort and carries old problems forward.
- Rebuilding legacy customizations. Recreating every old workaround defeats much of the purpose of replacing the system.
- Losing audit trails or signature context. Migrating values without their history weakens the record.
- Treating migration as an IT-only task. Data owners and QA must make and approve decisions.
- Skipping reconciliation on trial runs. Defects found late are expensive to fix.
- Forgetting interfaces and outputs. ERP connections, label formats and CoA templates are often discovered late.
- No plan for long-running work. Stability studies and open investigations need explicit decisions.
- Untested archives. An archive that cannot answer a retrieval request on demand is a compliance gap.
- Thin training. Users who learned workarounds in the old system need time to learn the new one.
If you are still choosing the replacement system, our LIMS buyer’s guide covers requirements, evaluation and total cost of ownership, including how to budget for migration.
How HDLIMS approaches this
Our LIMS migration service is built around the phases above: assessment, mapping specifications, repeated trial loads and reconciliation, planned together with your QA team so the work supports your validation. We help you decide what to migrate into HDLIMS and how archived records will stay retrievable for their retention periods. Learn more about our implementation services or talk to our team about your current system.