Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Go-Live Readiness and Acceptance
The pre-flight checklist
Before a plane leaves the gate, the crew runs a checklist: fuel, doors, controls, weather, flight plan. If one box isn’t ticked, the plane doesn’t go, however late it’s running.
Go-live readiness is that checklist for a new system. Deadline pressure is never a reason to skip it, and especially not a reason to skip user acceptance sign-off.
| Area | What should be in place |
|---|---|
| Testing | System and user acceptance testing complete; UAT signed off; critical defects fixed or formally accepted |
| Data | Conversion completed, reconciled and signed off by data owners |
| Users | Trained; procedures and user guides available |
| Operations | Support model, service desk briefed, monitoring, backup and recovery, job schedules, runbooks, SLAs |
| Security | Access granted to approved roles; test, vendor and developer accounts removed; default passwords changed; system hardened |
| Plans | Implementation runbook, communication plan, rollback plan with criteria |
| Approvals | Business owner acceptance; IT operations or change board approval |
Who says yes
- The business owner accepts the system, confirming it meets requirements and accepting any residual risk.
- IT operations or the change advisory board confirms production is ready to run and support it.
- The project team prepares the evidence but doesn’t approve its own work.
- The auditor may review readiness but doesn’t approve go-live.
Security at go-live
Go-live is the moment test-phase shortcuts turn into real risks. Classic findings: test accounts, vendor accounts, developer access and default passwords left behind in production.
Example. In a pre-implementation review, the auditor finds that the vendor’s implementation team still has administrator accounts in production, and 15 test users with the password “Welcome1” exist. Go-live is approved only on condition that these accounts are removed and a user access review is completed first.
Certification and accreditation
Some environments, especially government and regulated sectors, make readiness formal:
- Certification: a technical evaluation of whether the system’s controls meet requirements. Like a building inspection.
- Accreditation: management’s decision, based on the certification, to let the system operate and accept the residual risk. Like the certificate that says people can move in.
The pre-implementation review
Before go-live, an auditor may check that:
- control and security requirements are met
- testing was adequate, with sign-off
- data conversion was reconciled
- access controls are set up correctly
- operational procedures and documentation exist
- a rollback plan exists
Problems found now are far cheaper to fix than problems found after go-live.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who should approve a system for production | The business owner (with IT operations) |
| Most important prerequisite for go-live | Successful UAT with user sign-off |
| Common security issue at go-live | Test, vendor or developer accounts left in production |
| Management acceptance of residual risk before operation | Accreditation |
| Benefit of a pre-implementation review | Issues fixed before go-live at lower cost |
In short
- Go-live requires completed testing with user acceptance sign-off, successful data conversion, trained users, ready operations, and an approved implementation and rollback plan.
- The business owner (with IT operations) approves go-live; the project team can't approve its own work.
- Operational readiness covers support procedures, monitoring, backups, job schedules, documentation and service desk briefing.
- Security readiness covers access provisioning based on approved roles, removal of test and developer accounts, and hardening.
- Certification (technical evaluation) and accreditation (management acceptance of residual risk) are formal readiness steps in some environments.
- The auditor's pre-implementation review checks that controls are in place before go-live, when fixes are still cheap.
Exam traps
- Go-live pressure doesn't justify skipping UAT sign-off.
- Test accounts, default passwords and developer access left in production are classic go-live findings.
- Accreditation is management's acceptance of risk; certification is the technical assessment.
- Without a rollback plan, a failed go-live can become a business outage.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The pre-flight checklist
Before a plane leaves the gate, the crew runs a checklist: fuel, doors, controls, weather, flight plan. If any box isn't ticked, the plane doesn't go, however late it's running.
Go-live readiness is that checklist for a new system.
Certification and accreditation