Hand-over, Closure and Reporting¶
The closure phase starts when the validation is complete. It shows the customer what was built, hands over what the customer needs to own, and closes the project formally. This page also has the template for the steering committee report that you use during the whole implementation.
Closure steps¶
| # | Step | Result |
|---|---|---|
| 1 | Check that all validation items are passed or accepted | A closed validation work item |
| 2 | Prepare the hand-over material | See What to hand over |
| 3 | Hold the technical hand-over meeting | Agreed next steps |
| 4 | Complete the hand-over actions | Open points assigned |
| 5 | Ask the customer to accept the delivery in writing | Acceptance. In a commercial engagement it triggers the invoice, which is handled outside the platform team. |
| 6 | Switch to operations | The platform team runs the platform (Operating responsibilities) |
Technical hand-over meeting¶
Invite the same people as for the kick-off (Plan), and the people who will operate the platform. Use a standard slide deck or a walkthrough of the live environment. A good agenda:
- What was built. The hub per platform environment and region: management groups, subscriptions, network, firewall, gateways, policies and monitoring. Show it in the Azure portal and refer to the design (Platform).
- How it is set up in the pipeline platform. Repositories, entry pipelines, agents, environments and approvals, service connections or federated credentials, and the PIM model. Show a plan and an apply run.
- How changes are made. The configuration repository, pull requests, canary before prod, and the standard changes (Making a change safely, Common requests).
- How a spoke is created. Walk through the test spoke and the New spoke standard change. For workload teams, point to the Consumers section.
- Service management. The operating model, incident handling, the maintenance calendar, the monthly health check, and the service levels (Operations).
- Definitions. Terms the customer will hear (Glossary).
- Known issues and open points from the validation (Known issues).
- Next steps. Usually moving workloads to the platform (Onboarding and Migrate a workload), and the first version update.
What to hand over¶
| Item | Detail |
|---|---|
| Design document and the answered discovery sheet | The customer owns the design from here on |
| Access | The list of groups and who is in them, the PIM assignments and their expiry (the default eligibility is one year), the approvers |
| Identities | The deployment service principals, where their secrets or federated credentials live, expiry dates and who rotates them (Maintenance) |
| Repositories and pipelines | Where they are, which version is pinned, which protections are on |
| Configuration values | Alert receivers, the security contact, regions, IP plan, naming |
| Operational documents | Escalation contacts, support hours and intake channel (placeholders from the contract or the team's own agreement), the maintenance calendar |
| Validation record | The completed checklists |
| Open points | Accepted deviations, gaps that were not built, known issues that apply |
In the self-managed model, the new owners take the day-one checklist the same day: set alert receivers and the security contact to your own, take ownership of the deployment identities, set up approvals and decide on the version to pin.
Steering committee report template¶
Use this report for the steering committee during the implementation: one page, with the status per phase. Use the status words Green (on track), Amber (at risk) and Red (off track or blocked). Replace the examples.
1. Executive summary¶
- Overall status: Green / Amber / Red
- Key highlights: a short summary of the main achievements and concerns
2. Phase status¶
| Phase | Status | Key activities | Risks and issues |
|---|---|---|---|
| Plan | Completed / In progress / Delayed | Scope agreed; workshop held; stakeholders aligned | None, or describe (for example "delayed stakeholder input") |
| Prepare | Completed / In progress / Delayed | Prerequisites checked; identity set up; deployment identities created; repositories ready; pipelines and agents ready | For example "agent set-up blocked by permissions" |
| Deploy | Not started / In progress / Blocked | Job runners deployed; hub deployed in canary; hub deployed in prod; test spoke deployed | For example "waiting for approval of the production deployment" |
| Validate | Not started / In progress / Blocked | Security baseline checked; hub checked; agents checked; spoke canvas checked; second-person verification done | For example "no second person available" |
| Closure | Not started / In progress / Blocked | Hand-over planned; acceptance criteria reviewed; project closed | For example "customer sign-off delayed" |
3. Risks and issues¶
| Risk or issue | Impact | Owner | Status |
|---|---|---|---|
| Example: agent set-up permissions | High | Customer IT lead | Open |
| Example: stakeholder availability | Medium | Engagement lead | Open |
4. Decisions needed¶
- List the items that need a decision of the steering committee.
5. Next steps and actions¶
- List the next actions and who is responsible.