Go-live is the moment you claim a controlled state—and accept responsibility for defending it under audit. In regulated environments, that claim means a validated CMMS or EAM system go-live, not simply deploying software. It is the point where you are saying: this system is operating within defined controls, and we can prove it.
This is exactly where most implementations stall. Some teams treat every useful feature as a go-live requirement and delay the project indefinitely. Others move forward without the controls needed to defend the system’s validated state. Both mistakes create risk.
This post gives you a practical go-live gate. Use it to decide what must be true before launch, what can remain manual in Phase 1, and what is genuinely optional until later.
These gates assume the system supports good manufacturing practice (GMP)-relevant maintenance and/or calibration records. If a gate is not applicable to your intended use, document why. The point is deliberate, risk-informed decisions, not a blanket checklist applied without judgment.
Each item below follows the same structure: what must be true, what the evidence looks like, and who typically owns it. These are the conditions under which you can claim a state of control and defend that claim to an auditor.
If any of these are missing, your evidence set will not hold up when the go-live decision gets questioned—and that is avoidable inspection risk.
Intended use and GMP impact are defined, documented, and approved by quality assurance (QA).
The validation or assurance approach is documented and explicitly risk-based — aligned with FDA’s Computer Software Assurance (CSA) framework for production and quality system software where applicable, or with your organization’s equivalent risk-based methodology.
A system inventory exists that identifies GMP relevance and current validation status.
An approved intended-use statement that defines what the system does, what records it manages, and which regulatory requirements apply (21 CFR Part 11, EU Annex 11).
A validation or assurance plan referencing your risk classification approach.
A system inventory or register showing in-scope modules and their GMP relevance.
QA/Validation Lead (approval), System Owner (drafting), IT (technical input).
Clear, documented roles for Process Owner, System Owner, QA, IT, and any service providers.
Decision rights and escalation paths are explicit — not buried in committee structures or assumptions.
Each role understands their accountability for the system’s validated state.
A RACI (responsible, accountable, consulted, informed) matrix or equivalent document signed by stakeholders.
Governance charter or project roles section in the validation plan.
System Owner (primary), QA (validation governance), IT (technical operations).
For a detailed walkthrough of how CSA’s risk-based framework applies to GMP software, see FDA’s CSA Guidance Is Final: What It Means for Your Validation Strategy.
Asset and equipment inventory is loaded, reconciled, and sufficient for maintenance and calibration control.
Data owners are defined — who owns assets, locations, preventive maintenance (PM) schedules, and calibration master data.
Calibration program rules are implemented: written schedules, tolerance limits, and remedial actions consistent with 21 CFR 211.160(b)(4).
Data migration and conversion checks confirm that values and meaning were not altered during transfer (EU Annex 11, Section 4.8).
Master data for in-scope assets, locations, PMs, and calibrations is clean, with criticality and status clearly assigned.
A data migration report with reconciliation evidence showing source-to-target verification.
An approved data ownership matrix.
Calibration history (certificates and trend data) supporting established intervals, plus standard operating procedures (SOPs) governing interval-setting methodology.
Maintenance/Calibration Manager (data content), Data Migration Lead (technical execution), QA (verification and approval).
System access is limited to authorized individuals. Roles are enforced, not advisory.
Administrative activities are controlled and segregated from routine GMP work.
A privilege review cadence is defined and auditable.
No shared user accounts exist for routine GMP work — unique IDs are required.
System time settings and clocks are controlled and traceable for contemporaneous records.
A role-based access control (RBAC) matrix showing each role’s permissions.
Evidence that admin accounts are separate from operational user accounts.
A documented privilege review schedule.
Configuration evidence showing unique user ID enforcement.
IT (technical implementation), QA (policy and review), System Owner (approval of role assignments).
Audit trail is enabled for all GMP-relevant changes. Reasons for change are captured where required.
Audit trails are exportable, available, and retrievable in a human-readable format.
An audit trail review SOP exists, defining the frequency, scope, and method for review. A common approach is periodic sampling of records at defined intervals — quarterly or annually — rather than exhaustive line-by-line review.
Audit trail records are technically protected from modification or deletion, including by system administrators.
Audit trail configuration documentation showing which fields and actions are trailed.
An approved SOP for audit trail review with defined triggers, frequency, and responsible roles.
A test result confirming that administrators cannot modify or delete audit trail entries, and that changes to audit trail configuration are logged.
QA (SOP ownership, review execution), IT (configuration), System Owner (ensuring operational compliance).
Backup files exist for all computerized records. Copies are exact, complete, and secure.
Restore capability has been tested and verified with documented evidence.
Records are maintainable and retrievable throughout their required retention period.
A documented backup configuration aligned to your retention policy.
A restore test report showing successful recovery of GMP records.
Retention schedule mapping record types to regulatory retention requirements.
IT (execution), QA (policy requirements), System Owner (verification that restore meets GMP needs).
Training is completed for every user performing GMP-relevant tasks. Competence is sufficient — not just attendance.
Training is linked to SOPs and data integrity expectations, not limited to system navigation.
Superuser coverage and support readiness are confirmed so go-live does not collapse under operational questions.
Training records with completion dates and competency assessments.
Training curricula mapping roles to specific SOPs, system functions, and data integrity expectations.
A documented superuser network with coverage across shifts and locations.
Training Lead (delivery), QA (curriculum approval), Superusers (operational support).
For a deeper look at building training programs that survive past go-live week, see Building Training Programs and User Controls That Last Beyond Go-Live.
Core SOPs are drafted, QA-approved, and staff are trained — at minimum covering:
Approved SOP documents with effective dates prior to go-live.
Training records showing affected personnel completed SOP training before system access.
QA (approval), System Owner (drafting), Training Lead (delivery tracking).
Plan SOP revisions early. In paper-heavy organizations, 50 or more SOPs may reference manual processes that change when you go digital. Inventory affected SOPs at project kickoff and build revision timelines into your project plan—not as a last-minute task during user acceptance testing (UAT).
A controlled change and configuration management process is defined and operational.
Release and update impacts are assessed before deployment. A periodic evaluation plan exists.
Supplier agreements are in place with clear responsibilities. Supplier qualification evidence is retained.
An approved change control SOP with tiered categories.
A vendor update assessment procedure.
A supplier qualification file with service agreement, SOC 2 or equivalent evidence, and update evidence commitments.
System Owner (change control execution), QA (policy), IT (vendor management), Procurement (contracts).
Change control done right is what keeps your validated state intact over time. For more on managing changes without creating audit surprises, see After Go-Live: A GMP Playbook for Vendor Partnership.
Cutover criteria are defined: what triggers the switch, what happens to the legacy system, and how long dual systems will coexist.
Historical data availability is confirmed — either migrated or accessible in read-only legacy archives with documented access procedures.
A support model is established: hypercare period, support channels, escalation paths, and access to system configuration expertise.
A cutover plan with dates, responsible parties, and go/no-go criteria.
Legacy data access procedures documented and tested.
A hypercare plan defining duration, support channels, and escalation contacts.
Project Manager (cutover logistics), System Owner (go/no-go decision), IT (legacy access), Superusers (front-line support).
These capabilities are non-negotiable when you automate them in the system. But if your organization currently handles them through documented manual procedures—paper-based signatures, manual hand-offs on out-of-tolerance findings—you can deploy the system and continue those procedures at go-live. Automate them in Phase 2 when your team is ready.
The key: your current manual process must be proceduralized, trained, and auditable. You are not deferring a compliance obligation. You are choosing when to automate it.
If the system is configured to use electronic signatures at go-live, signed records display the signer’s name, date and time, and meaning of the signature.
Signatures are linked to their records in a way that prevents excision, copying, or transfer.
If the organization continues using paper-based signatures at go-live, current SOPs are trained and followed, and the system does not generate records that require unconfigured electronic signatures.
If automating: test evidence showing e-signature rendering with all required elements and configuration documentation showing identity verification controls.
If manual: current SOP with effective date and training records confirming wet-ink signature procedures are in place.
QA/Validation Lead (requirements), IT (configuration), System Owner (verification).
If the system is configured with automated out-of-tolerance (OOT) triggers at go-live, the system recognizes OOT entries and automatically triggers non-conformance workflows.
Asset status locks upon OOT detection, preventing the instrument from being used until investigation closes.
If the organization continues manual OOT hand-offs at go-live, SOPs define the manual process for recognizing OOT results, isolating the instrument, and initiating investigation.
If automating: test results showing automatic non-conformance generation on OOT entry and asset status lockout.
If manual: current SOP with effective date and training records.
Calibration/Metrology Manager (requirements), QA (workflow design), IT (configuration).
The following items are genuinely optional capabilities—not deferred compliance obligations. They add operational value, but none of them are regulatory requirements. You can implement them in Phase 2, Phase 5, or never, depending on your business needs. Your procedures and current systems cover these functions adequately as-is.
If you do want to track these items on a roadmap, a brief rationale note—why you are not implementing now and when you plan to revisit—makes the conversation straightforward if a decision comes up during an inspection or management review. This is good project discipline, not a regulatory requirement.
This checklist is meant to give you clarity, not ammunition for scope creep. The go-live gate above represents what regulators and auditors actually expect—not the gold-plated wish list that keeps projects in perpetual UAT.
Both FDA’s Part 11 scope and application guidance and the quality risk management (QRM) framework in ICH Q9 R1 explicitly caution against overly broad interpretations that increase costs without corresponding improvements to product quality or patient safety. The goal is proportional control: enough evidence to defend your system’s intended use, and enough discipline to know when “more” does not mean “better.”
If your project team has been circling the go-live question for months—adding scope, requesting one more test cycle, or debating whether a non-critical report needs validation before launch—use this checklist to break the deadlock. Walk through the 10 gate items. If they are all true, you are ready. If not, you know exactly what to fix.
