CTM buyer resource
Legacy LIMS stabilization checklist
Use this printable decision tool to organize evidence about an inherited or aging laboratory system. It is not incident response, does not prove recoverability, and does not authorize production changes.
Print this checklist
- Name the legitimate business owner, technical owner, administrators, vendors, and people authorized to approve change.
- Record known hosting, operating system, database, storage, network, scheduled-job, reporting, and integration dependencies.
- List daily workflows, reports, labels, exports, and interfaces that cannot be disrupted.
- Identify recent incidents, recurring manual workarounds, unsupported components, and single-person dependencies.
- Locate existing backup, restore, restart, monitoring, maintenance, and support documentation without exercising it.
- Write the decision to be made: stabilize, repair, upgrade, migrate, replace, support, or gather more evidence.
Evidence to gather
Gather architecture notes, inventories, owner and vendor contacts, contracts, runbooks, change records, version records, incident history, monitoring records, and existing backup documentation. Record the source and date for each fact. A file named “backup” is not proof that the required data is protected or restorable; keep backup existence, coverage, retention, and tested recovery as separate questions.
Map critical workflows and outputs to their dependencies. Note access boundaries and where credentials are supposed to be stored, but do not copy secrets into this checklist. Identify maintenance windows, business continuity expectations, and any external party whose authorization or documentation is required.
Red flags
- Ownership or authorization is unclear, shared accounts are the only access path, or credentials are being passed informally.
- The system depends on undocumented hosts, jobs, libraries, integrations, or one person’s memory.
- Backups are assumed from filenames or snapshots without known scope, retention, and recovery evidence.
- A repair or upgrade is proposed without current inventory, rollback, acceptance checks, or protected outputs.
- People want to test directly in production because no representative environment exists.
- An emergency symptom is being treated as permission for an unbounded modernization.
Do not change production
Do not restart services, rotate credentials, patch packages, edit the database, run cleanup scripts, test a restore, or alter workflows while preparing this checklist. Preserve logs and current evidence. Route active incidents through the authorized incident process. Any later intervention needs explicit authority, current backup and rollback evidence, bounded steps, and verification tied to the laboratory’s critical paths.
Use the result
The checklist should make uncertainty visible, not manufacture confidence. CTM can use it to scope a read-only assessment and rank stabilization, repair, upgrade, migration, and support options. Some questions may remain unresolved until authorized technical inspection. That is safer than promising a repair or replacement outcome from incomplete evidence.
Describe your systems need