Go-Live Readiness Review: [Solution or release name]
Evidence-based review that decides whether a solution, release or
migration wave is ready to go live on the planned date. It confirms
scope, test completion, operational acceptance, data migration,
cutover rehearsal, external dependencies, organisational readiness,
support readiness, security and compliance, and open defects and
risks, then records a go, conditional go or no-go decision with
owners and dates. Structure aligned with the go-live checklist areas
in the Microsoft Dynamics 365 implementation guide and with the
readiness-for-service questions of the UK Gate Review 4 (NISTA,
guidance updated August 2026), written for any technology. Replace
every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [GLR-001] |
| Solution or release | [Solution name] [Release, wave or rollout] |
| Planned go-live (T-0) | [YYYY-MM-DD HH:MM time zone] |
| Review type | [Dry run / Formal (T-14) / Confirmation (T-1) / Re-review after no-go] |
| Review date | YYYY-MM-DD |
| Decision forum | [Steering committee / Change advisory board / Programme board] |
| Version | [0.1] |
| Status | [Draft / Under review / Decided] |
| Owner | [@programme-director] |
| Approvers/reviewers | [@business-owner], [@service-owner], [@solution-architect], [@independent-reviewer], [@security-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Cutover plan], [Test completion report], [Hypercare plan], [RAID log] |
Approvals
| Role | Name | Decision | Date |
|---|
| Business owner (decision owner) | [@name] | [Go / Conditional go / No-go] | YYYY-MM-DD |
| Programme director | [@name] | [Recommendation] | YYYY-MM-DD |
| Receiving service owner | [@name] | [Accept into hypercare / Do not accept] | YYYY-MM-DD |
| Independent reviewer | [@name] | [Rating agreed / Dissent recorded] | YYYY-MM-DD |
| Security and compliance | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Dry-run review at T-6 weeks |
| 1.0 | YYYY-MM-DD | [@name] | Example: Formal review at T-14; conditional go with seven conditions (GLC-01 to GLC-07) |
| 1.1 | YYYY-MM-DD | [@name] | Example: T-1 confirmation; six conditions closed, one waived by the business owner |
Contents
1. Review scope and timing
1.1 What goes live
| Item | Value |
|---|
| Business capability | Example: Order-to-cash and procure-to-pay for two legal entities |
| Users at go-live | Example: 640 named users in 4 sites; 120 warehouse device users |
| Systems replaced | Example: Legacy ERP sales, purchasing and finance modules for entities DE01 and FR01 |
| Integrations | Example: 23 interfaces (14 outbound, 9 inbound), 3 with external partners |
| Rollout position | Example: Rollout 1 of 3; later rollouts reuse this review structure |
| Cutover window | Example: Saturday 06:00 to Monday 06:00 |
1.2 Decision and timetable
| Milestone | Timing | Purpose |
|---|
| Dry-run review (Example) | T-6 weeks | Find gaps while there is time to close them; no formal decision |
| Formal review (Example) | T-14 days | Rate every area and decide go, conditional go or no-go for the date |
| Condition follow-up (Example) | T-14 to T-2 days | Owners close conditions; status reviewed twice a week |
| Confirmation (Example) | T-1 (24 to 48 hours before T-0) | Confirm conditions closed; feeds GNG-2 in the cutover plan |
| Last no-go date without external cost (Example) | T-10 days | After this, partner test slots and contractor bookings are charged |
1.3 Review panel
| Member | Role in review | Independent of delivery? |
|---|
| [@name] | Chair, business owner | No |
| [@name] | Independent reviewer, quality or assurance function | Yes |
| [@name] | Receiving service owner | Partly |
| [@name] | Solution architect | No |
| [@name] | Security lead | Yes |
| [@name] | Finance or controlling representative | Yes |
2. Criteria and rating method
2.1 Rating scale
| Rating | Meaning | Effect on the decision |
|---|
| Ready | All criteria met with evidence | None |
| Ready with conditions | Criteria not fully met, but a dated, owned action closes the gap before T-0 or an accepted workaround exists | Conditional go; condition tracked in section 14 |
| Not ready | A blocker remains with no credible plan before T-0 | No-go unless the business owner accepts the risk in writing and the independent reviewer records the dissent |
| Not assessed | Evidence not provided | Treated as Not ready |
2.2 Blocker definition
A criterion is a blocker when failing it would stop a critical business
process, cause loss or corruption of data, breach a legal or contractual
obligation, or leave the service without the ability to restore or
support it. Mark blockers with B in the criteria tables.
2.3 Evidence rules
- Each criterion cites at least one artefact with a location and date.
- Test evidence comes from the latest complete cycle, not from a
selected earlier run.
- Sign-offs name a person, not a team.
- A waiver states the reason, the residual risk, the person accepting
it and the date it expires.
Criteria IDs use GLR-<area>-NNN, where the area is the section number
of this document. The scorecard in section 13 counts ratings by area.
3. Solution scope confirmation
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-3-001 (Example) | Business processes in scope listed and agreed with process owners | B | Scope baseline v1.4, signed YYYY-MM-DD | [Rating] |
| GLR-3-002 (Example) | Descoped items listed with workaround and target release | | Descope register | [Rating] |
| GLR-3-003 (Example) | Customisations, extensions and third-party add-ons in the release are known and supported | | Release content list, support contracts | [Rating] |
| GLR-3-004 (Example) | User numbers, sites and legal entities confirmed for this rollout | | Rollout plan | [Rating] |
| GLR-3-005 (Example) | Licences purchased and assignable for all go-live users | B | Licence report | [Rating] |
| [GLR-3-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
4. Test completion
| ID | Test level | B | Exit criteria (from the test plan) | Result | Signed by | Rating |
|---|
| GLR-4-001 (Example) | System integration testing | B | All interface scenarios passed, including partner-down scenarios; no open severity 1 or 2 defects | 412 of 418 passed; 6 deferred with workaround | [@test-manager] | [Rating] |
| GLR-4-002 (Example) | User acceptance testing | B | All in-scope processes passed with migrated data and production roles | 96 % passed; 2 severity 2 open | [@business-owner] | [Rating] |
| GLR-4-003 (Example) | Performance and volume testing | B | Peak-hour volume processed within agreed response times; batch window met | Met except report R-17 | [@performance-lead] | [Rating] |
| GLR-4-004 (Example) | Security testing | B | No open critical or high findings; medium findings accepted with dates | 1 high open, fix scheduled | [@security-lead] | [Rating] |
| GLR-4-005 (Example) | Regression testing of untouched systems | | Automated suite passed on the release baseline | Passed | [@test-manager] | [Rating] |
| GLR-4-006 (Example) | Accessibility testing for user-facing screens | | Conformance target met or exceptions recorded | Exceptions recorded | [@ux-lead] | [Rating] |
| [GLR-4-NNN] | [Level] | [B] | [Criteria] | [Result] | [@name] | [Rating] |
Reference the Test Completion Report (quality/test-completion-report)
for detailed numbers. Record any test level not run and why.
5. Operational acceptance
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-5-001 (Example) | Backup runs on schedule and a restore was performed and timed by operations staff | B | Restore test record, restore time 3 h 40 min | [Rating] |
| GLR-5-002 (Example) | Disaster recovery tested against the agreed recovery time and point objectives | B | DR test report | [Rating] |
| GLR-5-003 (Example) | Monitoring covers availability, latency, errors, queues and batch jobs; alerts routed to the rota | B | Alert routing test, dashboard links | [Rating] |
| GLR-5-004 (Example) | Runbooks exist for start, stop, failover, common errors and batch reruns | | Runbook set reviewed by operations | [Rating] |
| GLR-5-005 (Example) | Batch schedule documented with dependencies, owners and rerun rules | | Schedule export | [Rating] |
| GLR-5-006 (Example) | Capacity headroom confirmed for the first 12 months | | Capacity plan | [Rating] |
| GLR-5-007 (Example) | Certificates, secrets and credentials have owners and expiry alerts | | Secret inventory | [Rating] |
| GLR-5-008 (Example) | Configuration items recorded in the CMDB with relationships | | CMDB extract | [Rating] |
| [GLR-5-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
The Production Readiness Review (dev/service-readiness) holds the
detailed service checks for each component; cite its outcome here
instead of repeating it. For recovery design see Disaster Recovery Plan
(ops/disaster-recovery-plan).
6. Data migration readiness
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-6-001 (Example) | At least two full-volume mock loads completed; the latest passed all reconciliations | B | Mock load reports ML-2 and ML-3 | [Rating] |
| GLR-6-002 (Example) | Load duration fits the cutover window with contingency | B | Dress rehearsal timing | [Rating] |
| GLR-6-003 (Example) | Business owners signed data quality and reconciliation results per object | B | Reconciliation sign-off sheet | [Rating] |
| GLR-6-004 (Example) | Data cleansing backlog closed or accepted with known impact | | Cleansing tracker | [Rating] |
| GLR-6-005 (Example) | Migration scripts and mappings under version control and frozen | | Repository tag | [Rating] |
| GLR-6-006 (Example) | Migration data handled under the data classification rules, extracts deleted after use | | Data handling procedure, deletion log plan | [Rating] |
| [GLR-6-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
See Data Migration Strategy (architecture/data-migration-strategy)
and Data Migration Reconciliation (project/data-migration-reconciliation).
7. Cutover readiness
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-7-001 (Example) | Cutover plan approved with owners, durations, predecessors and verifications for every step | B | Cutover plan v1.0 | [Rating] |
| GLR-7-002 (Example) | Dress rehearsal completed inside the window | B | Rehearsal result REH-03 | [Rating] |
| GLR-7-003 (Example) | Rollback procedure rehearsed and its duration measured | B | Rehearsal result REH-04 | [Rating] |
| GLR-7-004 (Example) | Go/no-go checkpoints, point of no return and rollback deadline agreed with the business owner | B | Cutover plan sections 7, 8 and 10 | [Rating] |
| GLR-7-005 (Example) | Command centre staffed for every shift with named backups | | Roster | [Rating] |
| GLR-7-006 (Example) | Change record approved for the production window | B | Change record [CHG-NNNN] | [Rating] |
| [GLR-7-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
8. External dependencies
| ID | Dependency | B | Party | Needed by | Confirmation | Fallback | Rating |
|---|
| GLR-8-001 (Example) | Bank payment file channel switched to the new sender ID | | [Bank] | T+32h | Written confirmation YYYY-MM-DD | Manual payment upload for 2 days | [Rating] |
| GLR-8-002 (Example) | Logistics partner accepts new shipment message format | | [Partner] | T+32h | Partner test passed; production switch booked | Email shipment list | [Rating] |
| GLR-8-003 (Example) | Tax authority e-invoicing registration for the new system | B | [Authority] | T-5d | Registration reference | None | [Rating] |
| GLR-8-004 (Example) | Software vendor support available during window and hypercare | | [Vendor] | T-0 | Support order | Escalation via account manager | [Rating] |
| [GLR-8-NNN] | [Dependency] | [B] | [Party] | [When] | [Evidence] | [Fallback] | [Rating] |
9. Organisational and business readiness
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-9-001 (Example) | Role-based training completed by at least the agreed share of users per role | B | Training completion report by role | [Rating] |
| GLR-9-002 (Example) | Super-users named and available on site for the first two weeks | | Super-user roster | [Rating] |
| GLR-9-003 (Example) | Changed business procedures and work instructions published | | Procedure library | [Rating] |
| GLR-9-004 (Example) | Internal controls and approval limits configured and tested | B | Control test record | [Rating] |
| GLR-9-005 (Example) | Business continuity arrangements for the outage window agreed (manual orders, stock moves) | | Outage procedure | [Rating] |
| GLR-9-006 (Example) | Stakeholder and user communications issued on the T-minus schedule | | Communication log | [Rating] |
| GLR-9-007 (Example) | Change readiness survey shows no site below the agreed threshold, or actions are in place | | Survey results | [Rating] |
| [GLR-9-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
Training needs are best traced from a Training Needs Analysis
(education/training-needs-analysis).
10. Support readiness
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-10-001 (Example) | Hypercare plan approved with duration, rota, severity targets and exit criteria | B | Hypercare plan v1.0 | [Rating] |
| GLR-10-002 (Example) | Service desk trained, with categories, scripts and routing rules for the new service | B | Service desk briefing record | [Rating] |
| GLR-10-003 (Example) | Lines of support (first, second, third, vendor) defined with escalation paths and out-of-hours cover | B | Support model | [Rating] |
| GLR-10-004 (Example) | Support staff have the access and tools they need, tested | | Access test | [Rating] |
| GLR-10-005 (Example) | Operations handover plan agreed, with knowledge transfer started | | Handover plan, KT attendance | [Rating] |
| GLR-10-006 (Example) | Service level targets agreed for after hypercare | | Service level agreement draft | [Rating] |
| [GLR-10-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
See Hypercare Plan (ops/hypercare-plan), Operations Handover and
Knowledge Transfer (ops/operations-handover) and Service Level
Agreement (ops/service-level-agreement).
11. Security, privacy and compliance
| ID | Criterion | B | Evidence | Rating |
|---|
| GLR-11-001 (Example) | Production roles follow least privilege; segregation of duties conflicts resolved or accepted | B | Role review and conflict report | [Rating] |
| GLR-11-002 (Example) | Project and vendor accounts removed, disabled or time-limited for go-live | B | Access plan step in the cutover plan | [Rating] |
| GLR-11-003 (Example) | Security logging feeds the monitoring platform and alerts are tested | | Log source onboarding record | [Rating] |
| GLR-11-004 (Example) | Privacy assessment completed where personal data processing changed | B | DPIA reference | [Rating] |
| GLR-11-005 (Example) | Records retention and legal hold rules configured for migrated data | | Retention configuration | [Rating] |
| GLR-11-006 (Example) | Architecture conformance review passed or deviations accepted | | Architecture compliance assessment | [Rating] |
| [GLR-11-NNN] | [Criterion] | [B] | [Evidence] | [Rating] |
Where privacy assessment is required, use the DPIA (compliance/dpia).
For design conformance, use the Architecture Compliance Assessment
(architecture/architecture-compliance-assessment).
12. Open defects, risks and workarounds
12.1 Open defects at review date
| Severity | Open | Accepted with workaround | Fix planned before T-0 | Fix planned in hypercare |
|---|
| 1 Critical (Example) | 0 | 0 | 0 | 0 |
| 2 High (Example) | 4 | 1 | 2 | 1 |
| 3 Medium (Example) | 19 | 12 | 3 | 4 |
| 4 Low (Example) | 37 | 37 | 0 | 0 |
Check that each row adds up: defects accepted with a workaround plus
fixes planned before T-0 plus fixes planned in hypercare equal the open
count. Count each defect once: "Accepted with workaround" holds
defects with no fix planned before hypercare exit, so a defect with a
workaround and a hypercare fix date (DEF-0398 in the Example) counts
under hypercare. Any severity 1 defect open at T-1 is a blocker.
12.2 Defects and risks that matter for the decision
| ID | Type | Description | Business impact | Workaround | Owner | Due |
|---|
| DEF-0412 (Example) | Defect, severity 2 | Credit note print layout misses tax line | Credit notes cannot be sent to FR01 customers | Manual credit notes from template for up to 5 days | [@name] | T-3d |
| DEF-0398 (Example) | Defect, severity 2 | Report R-17 exceeds 10 minutes at peak | Daily sales review delayed | Run at 05:00 as a scheduled job | [@name] | Hypercare week 1 |
| RSK-031 (Example) | Risk | Peak season starts 3 weeks after go-live | Little time to stabilise before volume rises | Extend hypercare to cover first peak week | [@name] | Decision at review |
| [ID] | [Type] | [Description] | [Impact] | [Workaround] | [@owner] | [Date] |
Keep the full list in the RAID Log (project/raid-log).
13. Readiness scorecard
| Area | Criteria | Ready | With conditions | Not ready | Blockers not ready | Area rating |
|---|
| 3 Solution scope (Example) | 5 | 5 | 0 | 0 | 0 | Ready |
| 4 Test completion (Example) | 6 | 3 | 3 | 0 | 0 | Ready with conditions |
| 5 Operational acceptance (Example) | 8 | 7 | 1 | 0 | 0 | Ready with conditions |
| 6 Data migration (Example) | 6 | 6 | 0 | 0 | 0 | Ready |
| 7 Cutover (Example) | 6 | 6 | 0 | 0 | 0 | Ready |
| 8 External dependencies (Example) | 4 | 3 | 1 | 0 | 0 | Ready with conditions |
| 9 Organisational readiness (Example) | 7 | 6 | 1 | 0 | 0 | Ready with conditions |
| 10 Support readiness (Example) | 6 | 6 | 0 | 0 | 0 | Ready |
| 11 Security and compliance (Example) | 6 | 5 | 1 | 0 | 0 | Ready with conditions |
| [Area] | [N] | [N] | [N] | [N] | [N] | [Rating] |
Overall rule: the overall rating is the lowest area rating, and any
blocker rated Not ready makes the overall rating Not ready. In the
Example, 7 conditions across five areas give an overall rating of
Ready with conditions.
14. Decision, conditions and actions
14.1 Decision
| Field | Value |
|---|
| Decision | [Go / Conditional go / No-go] |
| Statement | Example: Conditional go for Saturday YYYY-MM-DD, subject to conditions GLC-01 to GLC-07 being closed or waived by the T-1 meeting |
| Decided by | [@business-owner] on YYYY-MM-DD |
| Recommendation of independent reviewer | Example: Agree, with concern over the peak season risk RSK-031 |
| Dissent recorded | [None / Name and reason] |
| If no-go: new review date | YYYY-MM-DD |
14.2 Conditions
| ID | Condition | Source criterion | Owner | Due | Proof of closure | Status |
|---|
| GLC-01 (Example) | Fix and re-test DEF-0412 | GLR-4-002 | [@name] | T-3d | Re-test record | [Open / Closed / Waived] |
| GLC-02 (Example) | Close the open high security finding | GLR-4-004 | [@name] | T-5d | Re-scan report | [Status] |
| GLC-03 (Example) | Schedule report R-17 as a 05:00 job and inform users | GLR-4-003 | [@name] | T-2d | Job in schedule, user notice | [Status] |
| GLC-04 (Example) | Complete the capacity sign-off for the reporting database | GLR-5-006 | [@name] | T-7d | Signed capacity plan | [Status] |
| GLC-05 (Example) | Obtain production switch date from logistics partner | GLR-8-002 | [@name] | T-7d | Written confirmation | [Status] |
| GLC-06 (Example) | Deliver refresher training for warehouse staff at site 3 | GLR-9-001 | [@name] | T-4d | Attendance list | [Status] |
| GLC-07 (Example) | Resolve two segregation of duties conflicts in finance roles | GLR-11-001 | [@name] | T-5d | Conflict report | [Status] |
| [GLC-NN] | [Condition] | [GLR ID] | [@owner] | [Date] | [Evidence] | [Status] |
14.3 Traceability
| Decision input | Criteria | Conditions | Carried to |
|---|
| Test completion (Example) | GLR-4-002, GLR-4-003, GLR-4-004 | GLC-01, GLC-02, GLC-03 | Cutover plan entry criteria CUT-EC-001 |
| Operations (Example) | GLR-5-006 | GLC-04 | Operations handover acceptance criteria |
| Dependencies (Example) | GLR-8-002 | GLC-05 | Cutover plan GNG-2 |
| Risk (Example) | RSK-031 | None | Hypercare plan duration and exit criteria |
| [Input] | [IDs] | [IDs] | [Document and ID] |
15. Glossary and references
15.1 Glossary
| Term | Meaning in this review |
|---|
| Go-live | The moment users and partners start using the solution for real business |
| Blocker | A criterion whose failure would stop a critical process, lose data, breach an obligation or leave the service unsupportable |
| Conditional go | Approval to proceed provided named conditions close by a stated date |
| Operational acceptance testing (OAT) | Testing by or with operations staff of operability: backup, restore, recovery, monitoring, maintainability and security operations |
| Waiver | Written acceptance of a residual risk by an accountable person, with an expiry date |
| Hypercare | Period of elevated support after go-live |
| T-0 | Start of the cutover window |
15.2 References
| Reference | Version or date checked | Use |
|---|
| Microsoft Dynamics 365 implementation guide, go-live checklist, learn.microsoft.com | Page updated 2026-07-15 | Area list for sections 3 to 10, paraphrased |
| Microsoft Dynamics 365 implementation guide, prepare your production environment to go live (go-live readiness review), learn.microsoft.com | Page updated 2026-10-15 | Review timing and purpose |
| NISTA, Gate Review 4: Readiness for Service, gov.uk | First published 2021-07-15; HTML version added 2026-08-20 | Readiness-for-service questions aligned with the Five Case Model; check gov.uk for the current version |
| AWS Prescriptive Guidance, Project governance playbook for AWS large migrations, docs.aws.amazon.com | Initial publication 2022-02-28 | T-14 checkpoint and T-1 go or no-go timing |
| ISTQB Glossary, operational acceptance testing, glossary.istqb.org | Check the current glossary version | Meaning of OAT |
| [Internal assurance framework] | [Version] | [Use] |
Standard and licence note
Structure aligned with the go-live checklist areas and the go-live
readiness review described in the Microsoft Dynamics 365
implementation guide, with the readiness-for-service gate published by
the UK National Infrastructure and Service Transformation Authority
(NISTA, Gate Review 4, which replaces the earlier Infrastructure and
Projects Authority guidance) and with the go or no-go timing in the AWS
Prescriptive Guidance large migration governance playbook. Area names
are used for mapping; all criteria are written in original wording and
no checklist item, workbook question or template is reproduced.
Microsoft, Dynamics 365, Amazon Web Services and AWS are trademarks of
their owners; this template is not affiliated with or endorsed by them.
UK government guidance is cited by title and date only. This template
is original text written for this collection. Check the current official
guidance before use. Template licence: MIT.