LIMS implementation checklist: from kick-off to go-live and beyond

The phases at a glance

Phase 1: set-up and governance

• Name a process owner from the lab and a QA owner who will approve the validation.
• Write a one-page charter: which labs, which sample types, what is in and out of scope.
• Decide the delivery model: configured product, custom build or a mix.
• Draft the validation plan early, so the approach is agreed before work starts.
• Agree how decisions and changes will be approved during the project.
• Book analysts’ time; a LIMS cannot be designed without the people who use it.

Phase 2: requirements

• Map the current process for each sample type, including paper and spreadsheet steps.
• Write the URS as numbered, testable requirements, marked GxP or business.
• Include data-integrity requirements: audit trail, access control, e-signatures, backup.
• List every instrument, data system and business system the LIMS must exchange data with.
• Have QA review and approve the URS before selection or design is finalised.

Our LIMS URS template is a practical starting point. If you have not decided between a product and a custom build yet, read custom vs off-the-shelf LIMS first.

Phases 3 and 4: design, build and configuration

• Assess the supplier’s quality system and development practices, and record the result.
• Write functional and configuration or design specifications that trace to the URS.
• Prepare master data early: products, specifications, methods, limits, units, users and roles.
• Have master data checked by a second person; a wrong limit is a GxP error.
• Build interfaces one instrument or system at a time, with test data from the real device.
• Hold regular demos with analysts so problems surface before formal testing.

Environments: keep testing and production apart

Plan the environments before the build starts. Most regulated projects use at least three: development, where the supplier or team builds and configures; a controlled test or validation environment that mirrors production, where formal testing runs; and production, used only for real GxP work.

• Record the versions and configuration of each environment, so test results can be trusted for production.
• Move configuration and code between environments by a controlled, repeatable process.
• Never test with live patient or batch data unless it has been approved and protected.
• Keep a test environment after go-live for changes and upgrades.

Phase 5: data migration

Migration is the step most often underestimated. Decide what moves, and how you will prove it moved correctly.

• Decide which records migrate, which are archived in the old system and which stay on paper.
• Map each field from source to target, including units and status values.
• Run trial migrations and fix mapping errors before the final run.
• Verify migrated data with a documented check, such as full comparison for critical data and sampling for the rest.
• Keep the audit trail and approval history where they are needed to understand the record.

Phase 6: validation

• Complete the risk assessment against the URS and agree test depth with QA.
• Install in a controlled environment and record versions and settings (IQ).
• Test functions, especially audit trail, signatures, calculations and access (OQ).
• Test real workflows with trained users and realistic data (PQ).
• Log and resolve deviations; retest where needed.
• Complete the traceability matrix and the validation summary report for QA approval.

The full list of documents is in our explainer on what a validation package contains.

Phases 7 and 8: training, cut-over and hypercare

• Update or write SOPs for sample handling, review, audit-trail review, access and backup.
• Train every user on the validated system and SOPs, and record the training.
• Write a cut-over plan: freeze date, final migration, parallel running if any, go/no-go criteria.
• Get QA approval of the validation summary report before GxP use.
• Run a hypercare period with fast support and a visible issue log.
• Schedule the first periodic review and hand over to change control.

After go-live the system is only as validated as its change control. Every patch, new instrument or new test method goes through impact assessment before release.

Who you need on the team

Small labs combine some of these roles, but each responsibility should have a named person:

• Process owner — usually the lab head; owns the requirements, makes process decisions and accepts the system.
• QA owner — approves the validation plan, URS and summary report, and decides whether deviations are acceptable.
• Project manager — runs the plan, the risks and the issue log, and keeps decisions recorded.
• Key users — experienced analysts and reviewers who help design workflows, check master data and run PQ.
• System owner and IT — infrastructure, security, backups, user administration and the environments.
• Validation lead — writes or coordinates the validation documents and the traceability matrix.
• Supplier or development team — delivers the configured or custom system, specifications and developer evidence.

The roles that are most often left empty are key users and the system owner. Without key users the workflows are designed from assumptions; without a system owner nobody runs access reviews, backups or periodic reviews after go-live.

Instruments and interfaces

Interfaces deserve their own checklist, because each one is a small project with its own risks:

• List every instrument and data system, with its software version and what it can output.
• Decide for each one: direct interface, file import, or controlled manual entry with a second-person check.
• Collect real output files early and test parsing against them, including error cases.
• Make sure the raw data stays linked to the result in the LIMS.
• Agree what happens when an import fails or a value is out of range.
• Include interface changes, such as instrument software upgrades, in change control.

Where LIMS projects usually slip

• Analysts are not released from routine work to help design.
• Master data turns out to be inconsistent across sites or teams.
• Instrument outputs differ from what the specification assumed.
• The URS changes late without going through change control.
• Validation starts after the build instead of alongside it.

We build LIMS in phases with the validation deliverables written alongside the code, so these risks show up early. See our LIMS development service for how a project runs.

Frequently asked questions