# 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*.

<!--
Guidance: How to use this template
- Hold the review early enough to fix what it finds. A common pattern
  is a dry-run review about six weeks before go-live, the formal review
  at the T-14 checkpoint, and a short confirmation at the T-1 go or
  no-go meeting in the Cutover Plan (`project/cutover-plan`).
- Every criterion needs evidence (a report, a signed record, a test
  result), not an opinion. Section 2 defines the rating rules; apply
  them the same way to every area.
- The reviewer panel should include at least one person who is not on
  the delivery team. Independence is what makes the rating credible.
- The scorecard in section 13 and the decision in section 14 are the
  pages executives read. Write them last and keep them on one screen.
- Related documents: Production Readiness Review
  (`dev/service-readiness`) for the technical service checks,
  User Acceptance Test Plan (`quality/uat-plan`), Test Completion
  Report (`quality/test-completion-report`), Performance Test Plan
  (`quality/performance-test-plan`), Data Migration Reconciliation
  (`project/data-migration-reconciliation`), Hypercare Plan
  (`ops/hypercare-plan`), Operations Handover and Knowledge Transfer
  (`ops/operations-handover`), RAID Log (`project/raid-log`).
-->

## Document control

<!-- Guidance: Identify the go-live being assessed, the decision date and the panel. Re-issue the document as a new version for the T-1 confirmation rather than editing the formal review record. -->

| 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

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Review scope and timing](#1-review-scope-and-timing)
2. [Criteria and rating method](#2-criteria-and-rating-method)
3. [Solution scope confirmation](#3-solution-scope-confirmation)
4. [Test completion](#4-test-completion)
5. [Operational acceptance](#5-operational-acceptance)
6. [Data migration readiness](#6-data-migration-readiness)
7. [Cutover readiness](#7-cutover-readiness)
8. [External dependencies](#8-external-dependencies)
9. [Organisational and business readiness](#9-organisational-and-business-readiness)
10. [Support readiness](#10-support-readiness)
11. [Security, privacy and compliance](#11-security-privacy-and-compliance)
12. [Open defects, risks and workarounds](#12-open-defects-risks-and-workarounds)
13. [Readiness scorecard](#13-readiness-scorecard)
14. [Decision, conditions and actions](#14-decision-conditions-and-actions)
15. [Glossary and references](#15-glossary-and-references)

## 1. Review scope and timing

<!-- Guidance: State what is going live, what is being decided and by when. Questions: is this a full go-live or one rollout of several? What is the last date on which a no-go still avoids sunk external costs? Pitfall: a review scheduled two days before go-live, when nothing it finds can be fixed. -->

### 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

<!-- Guidance: Define the rating scale, what counts as a blocker and what evidence is acceptable before rating anything. Pitfall: an area rated green because the team is confident, with no artefact behind it. -->

### 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

1. Each criterion cites at least one artefact with a location and date.
2. Test evidence comes from the latest complete cycle, not from a
   selected earlier run.
3. Sign-offs name a person, not a team.
4. 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

<!-- Guidance: Confirm that what is going live matches what the business agreed to receive, including anything descoped. Questions: has every descoped item an agreed workaround and a later release? Pitfall: users discovering on day one that a process they relied on was quietly moved to a later release. -->

| 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

<!-- Guidance: Show that every planned test level finished with its exit criteria met and signed. Questions: were tests run with migrated data and production roles? Were integrations tested at peak volumes and with partner systems unavailable? Pitfall: UAT signed with test data that never resembled the migrated data. -->

| 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

<!-- Guidance: Operational acceptance testing proves that operations staff can run, monitor, back up, restore and recover the service, not only that it works. Questions: has someone outside the project team restored a backup? Do alerts reach the people on call? Pitfall: treating a successful deployment as proof of operability. -->

| 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

<!-- Guidance: Show that the migration was rehearsed several times, that it fits the window and that the business signed the reconciliations. Pitfall: a final mock load run on a subset because full volume "takes too long", which is exactly what the cutover window must absorb. -->

| 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

<!-- Guidance: Confirm that the cutover plan is complete, rehearsed and staffed. Questions: did the dress rehearsal run on the real clock? Was rollback measured? Is the point of no return agreed? Pitfall: a rollback plan that exists only as a heading. -->

| 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

<!-- Guidance: List every party outside the team whose action or system the go-live needs, and confirm each one in writing. Pitfall: a partner who tested in a test environment but has not scheduled the switch of their production endpoint. -->

| 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

<!-- Guidance: Confirm that people, processes and policies are ready, not only the system. Questions: can each user do their job on day one? Are new procedures, approvals and controls in force? Pitfall: training completed months earlier with no refresher and no sandbox for practice. -->

| 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

<!-- Guidance: Confirm that users know where to get help and that the people helping them are trained, staffed and equipped. Pitfall: a service desk that has never seen the new system and routes every ticket to the project team's mailbox. -->

| 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

<!-- Guidance: Confirm that the controls required for production are in place and that any regulatory obligations attached to go-live are met. Pitfall: privileged project accounts carried into production because removing them was nobody's step. -->

| 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

<!-- Guidance: Show every open defect and risk that will be live at go-live, with its business impact, workaround and fix date. Questions: does any combination of individually acceptable defects make a process unworkable? Pitfall: counting defects without reading them. -->

### 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

<!-- Guidance: One row per area, rated with the scale in section 2. Do not average ratings: one Not ready blocker outweighs any number of Ready rows. Pitfall: a scorecard that hides a red blocker behind an overall amber. -->

| 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.

```mermaid
flowchart TD
  S[Area ratings complete] --> B{Any blocker Not ready?}
  B -- yes --> W{Business owner accepts risk in writing?}
  W -- no --> NG[No-go: set new date]
  W -- yes --> D[Conditional go with dissent recorded]
  B -- no --> C{Any area Ready with conditions?}
  C -- yes --> CG[Conditional go: conditions tracked to T-1]
  C -- no --> G[Go]
  CG --> T1{All conditions closed or waived at T-1?}
  T1 -- yes --> G
  T1 -- no --> NG
```

## 14. Decision, conditions and actions

<!-- Guidance: Record the decision in one sentence, then each condition with an owner, a due date and how closure will be proved. Questions: which conditions must close before T-0 and which may move into hypercare? Pitfall: conditions with no owner, which are later found open at the T-1 meeting. -->

### 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

<!-- Guidance: Keep definitions short and specific to this review. -->

### 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.