# Operations Handover and Knowledge Transfer Plan: [Service name]

> Plan for moving ownership of a new or changed service from the
> project or delivery team to the teams that will run and support it.
> It covers the services and components transferred, the transition
> timeline, the target support model, acceptance into service criteria,
> the documentation pack, knowledge transfer sessions, shadow and
> reverse shadow, access and tooling, integration with service
> management processes, monitoring and runbooks, open items, warranty
> and early life support, suppliers and costs, and sign-off. Structure
> aligned with ISO/IEC 20000-1:2018 clause 8.5 (service design, build
> and transition) and clause 7.6 (knowledge), with ITIL 4 practice names,
> and with the transition-to-support guidance in the Microsoft Dynamics
> 365 implementation guide. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Start this plan when the design is stable, not after go-live.
  Knowledge transfer that begins during hypercare is too late for the
  receiving team to challenge the design or the documentation.
- Name a receiving owner for every service, component, document and
  open item. An item without a receiving owner has not been handed
  over.
- Acceptance into service (section 4) is the gate. Hypercare exit in
  the Hypercare Plan (`ops/hypercare-plan`) and this acceptance should
  be decided together, from the same evidence.
- The worked example uses one timeline: knowledge transfer starts 8
  weeks before go-live, shadowing runs in hypercare weeks 1 and 2,
  reverse shadow in weeks 3 and 4, acceptance at hypercare exit on
  business day 20, then a 60-day warranty.
- Related documents: Software Transition Plan
  (`dev/software-transition-plan`) for contract-style transition to a
  separate support agency, Runbook (`dev/runbook`), Standard Operating
  Procedure (`ops/sop`), On-call Handbook (`ops/on-call-handbook`),
  Service Level Agreement (`ops/service-level-agreement`), ISO/IEC 20000
  Service Catalogue (`compliance/iso-20000-service-catalog`), Software
  Maintenance Plan (`dev/software-maintenance-plan`), RACI Matrix
  (`business/raci`).
-->

## Document control

<!-- Guidance: Identify the service being handed over, the giving and receiving organisations and the key dates. A change to the receiving organisation or the acceptance date is a new minor version. -->

| Field | Value |
|---|---|
| Document ID | [OHO-001] |
| Service name | [Service name] |
| Giving team | [Project or delivery team, supplier name if external] |
| Receiving teams | [Service desk], [Application support], [Platform operations], [Vendor] |
| Go-live date | YYYY-MM-DD |
| Planned acceptance into service | YYYY-MM-DD |
| Warranty or early life support end | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / Approved / In transition / Accepted / Closed] |
| Owner | [@transition-manager] |
| Approvers/reviewers | [@receiving-service-owner], [@project-manager], [@application-support-lead], [@platform-operations-lead], [@security-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Hypercare plan], [Service level agreement], [Runbooks], [CMDB records] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Receiving service owner | [@name] | [Accept / Accept with conditions / Reject] | YYYY-MM-DD |
| Project manager (giving side) | [@name] | [Decision] | YYYY-MM-DD |
| Application support lead | [@name] | [Decision] | YYYY-MM-DD |
| Platform operations lead | [@name] | [Decision] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft at design sign-off |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; knowledge transfer sessions scheduled |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Reverse shadow extended by 5 days for the integration team |

## Contents

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

1. [Scope and services transferred](#1-scope-and-services-transferred)
2. [Transition approach and timeline](#2-transition-approach-and-timeline)
3. [Target support model](#3-target-support-model)
4. [Acceptance into service criteria](#4-acceptance-into-service-criteria)
5. [Documentation pack](#5-documentation-pack)
6. [Knowledge transfer plan](#6-knowledge-transfer-plan)
7. [Shadow and reverse shadow](#7-shadow-and-reverse-shadow)
8. [Access, tooling and accounts](#8-access-tooling-and-accounts)
9. [Service management process integration](#9-service-management-process-integration)
10. [Monitoring, alerts and runbooks](#10-monitoring-alerts-and-runbooks)
11. [Open items transfer](#11-open-items-transfer)
12. [Warranty and early life support](#12-warranty-and-early-life-support)
13. [Suppliers, contracts and costs](#13-suppliers-contracts-and-costs)
14. [Sign-off](#14-sign-off)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope and services transferred

<!-- Guidance: List exactly what changes hands: services, components, environments, data stores, interfaces, scheduled jobs and responsibilities. Questions: who owns each item today, and who will own it after acceptance? Pitfall: forgetting non-production environments, certificates and scheduled jobs, which then have no owner. -->

### 1.1 Services and components

| ID | Item | Type | Current owner | Receiving owner | Notes |
|---|---|---|---|---|---|
| TRN-001 *(Example)* | Order management service | Business service | Project team | Application support | Listed in the service catalogue |
| TRN-002 *(Example)* | Integration platform flows (23 interfaces) | Application component | Integration project lead | Integration support | Partner contacts transfer too |
| TRN-003 *(Example)* | Production and pre-production environments | Infrastructure | Project platform engineers | Platform operations | Non-production refresh duty included |
| TRN-004 *(Example)* | Batch schedule (41 jobs) | Operational process | Project technical lead | Platform operations | Rerun rules in runbook |
| TRN-005 *(Example)* | Reporting data mart | Data store | Data team (project) | Data platform team | Data owner stays in finance |
| TRN-006 *(Example)* | TLS certificates and service credentials | Security assets | Project security engineer | Platform operations | Expiry alerts required |
| [TRN-NNN] | [Item] | [Type] | [Owner] | [Owner] | [Notes] |

### 1.2 Out of scope

| Item | Reason | Owner |
|---|---|---|
| *Example:* Legacy system read-only access | Decommissioned separately | Legacy support team |
| *Example:* Roadmap features for release 2 | Remain with the product team | Product owner |
| [Item] | [Reason] | [@owner] |

## 2. Transition approach and timeline

<!-- Guidance: Show the phases and the entry and exit condition for each. The receiving team should do more of the work in each phase. Pitfall: a single "handover meeting" at the end, which transfers documents but not capability. -->

| Phase | Timing *(Example)* | Who does the work | Exit condition |
|---|---|---|---|
| 1. Prepare | Design sign-off to T-8 weeks | Giving team | Plan approved; receiving owners named; documentation pack outline agreed |
| 2. Knowledge transfer | T-8 weeks to go-live | Giving team teaches; receiving team attends and reviews documents | All sessions in section 6 delivered; competence checks passed |
| 3. Shadow | Hypercare weeks 1 and 2 | Giving team does the work; receiving team observes and asks | Receiving team has observed each ticket class and each runbook task at least once |
| 4. Reverse shadow | Hypercare weeks 3 and 4 | Receiving team does the work; giving team observes and coaches | At least 5 business days with tickets handled unaided within targets |
| 5. Acceptance into service | Hypercare exit, business day 20 | Joint review | Criteria in section 4 met or waived; sign-off in section 14 |
| 6. Warranty and early life support | 60 days after acceptance | Receiving team runs; giving team fixes warranty defects | Warranty closed; final report |

```mermaid
flowchart LR
  P[1 Prepare] --> K[2 Knowledge transfer]
  K --> GL((Go-live))
  GL --> S[3 Shadow, hypercare weeks 1-2]
  S --> R[4 Reverse shadow, weeks 3-4]
  R --> A{5 Acceptance into service}
  A -- criteria met --> W[6 Warranty, 60 days]
  A -- not met --> R
  W --> C[Closed]
```

## 3. Target support model

<!-- Guidance: Describe the support model that will run after acceptance, with tiers, hours, targets and escalation. Questions: who answers the phone at 02:00 on a Sunday? Which issues go to the vendor directly? Pitfall: a support model that names teams who have never agreed to it. -->

### 3.1 Tiers

| Tier | Team | Responsibilities | Hours | Tooling |
|---|---|---|---|---|
| Self-service | Users | Knowledge articles, password reset, request catalogue | 24x7 | Service portal |
| First line | Service desk | Intake, categorisation, known-error matching, access requests, simple fixes | [Hours] | ITSM tool |
| Second line | Application support | Functional issues, configuration, data fixes, workarounds | [Hours] plus on call for severity 1 and 2 | ITSM tool, application admin console |
| Third line | Development or product team | Code defects, enhancements, root-cause fixes | Business hours plus on call for severity 1 | Code repository, CI/CD |
| Platform | Platform operations | Environments, infrastructure, backups, certificates, batch | 24x7 | Monitoring, scheduler |
| Vendor | [Vendor names] | Product defects, platform incidents | Per contract | Vendor portal |

### 3.2 RACI after acceptance

| Activity | Service desk | Application support | Development | Platform operations | Service owner | Vendor |
|---|---|---|---|---|---|---|
| Incident intake and logging | R | I | I | I | A | I |
| Functional incident resolution | C | R | C | I | A | C |
| Code fix and release | I | C | R | C | A | C |
| Infrastructure incident resolution | I | C | I | R | A | C |
| Backup and restore | I | I | I | R | A | I |
| Change approval | I | C | C | C | A | I |
| Service reporting | I | R | I | C | A | I |
| Vendor escalation | I | R | I | R | A | R |

### 3.3 Service levels

Record the targets in the Service Level Agreement
(`ops/service-level-agreement`) and the internal targets between teams
as operational level agreements. Hypercare targets end at acceptance.

| Measure | Target *(Example)* | Agreement |
|---|---|---|
| Availability, business hours | [99.5 %] per month | SLA |
| Severity 1 response | 15 minutes, 24x7 | SLA |
| Severity 2 response | 1 hour, business hours | SLA |
| Second line acknowledgement of escalated tickets | 30 minutes | OLA service desk to application support |
| Vendor response for severity 1 | Per vendor contract | Underpinning contract |

## 4. Acceptance into service criteria

<!-- Guidance: Agree the criteria with the receiving owner at the start of the transition, then evidence each one. Questions: could the receiving team run this service tomorrow if the giving team disappeared? Pitfall: criteria that check documents exist but not that anyone can use them. -->

| ID | Criterion | Evidence | Confirmed by | Status |
|---|---|---|---|---|
| OHO-AC-001 *(Example)* | Documentation pack in section 5 complete, reviewed and stored in the operations knowledge base | Review record per document | Application support lead | [Met / Not met] |
| OHO-AC-002 *(Example)* | Every receiving engineer attended the sessions for their role and passed the competence check | KT attendance and check results | Receiving team leads | [Status] |
| OHO-AC-003 *(Example)* | Reverse shadow completed for at least 5 business days within targets | Ticket report for the period | Service owner | [Status] |
| OHO-AC-004 *(Example)* | Receiving team performed each critical runbook task unaided (restore, failover, batch rerun, certificate renewal) | Task log with dates | Platform operations lead | [Status] |
| OHO-AC-005 *(Example)* | Monitoring and alerts route to the receiving rota and were tested | Alert test record | Platform operations lead | [Status] |
| OHO-AC-006 *(Example)* | Configuration items and relationships recorded in the CMDB | CMDB extract | Configuration manager | [Status] |
| OHO-AC-007 *(Example)* | Open items in section 11 transferred with owners and dates | Open items register | Service owner | [Status] |
| OHO-AC-008 *(Example)* | Access in section 8 granted to receiving teams; project access removed or reduced | Access review record | Security lead | [Status] |
| OHO-AC-009 *(Example)* | Service level agreement and operational level agreements signed | Signed agreements | Service owner | [Status] |
| OHO-AC-010 *(Example)* | Support contracts with vendors in the name of the receiving organisation | Contract references | Supplier manager | [Status] |
| [OHO-AC-NNN] | [Criterion] | [Evidence] | [@name] | [Status] |

## 5. Documentation pack

<!-- Guidance: List every document the receiving teams need, its owner after acceptance, and its review status. Write documents for the reader who was not in the project. Pitfall: architecture diagrams that show the design as planned, not as built. -->

| ID | Document | Purpose | Author | Reviewer (receiving) | Location | Status |
|---|---|---|---|---|---|---|
| DOC-01 *(Example)* | Solution architecture, as built | Components, integrations, data flows, deployment view | Solution architect | Application support lead | [Link] | [Draft / Reviewed / Accepted] |
| DOC-02 *(Example)* | Runbooks per component | Start, stop, health checks, common faults, rollback | Technical lead | Platform operations | [Link] | [Status] |
| DOC-03 *(Example)* | Standard operating procedures | Routine tasks: user admin, period-end jobs, data refresh | Functional leads | Application support | [Link] | [Status] |
| DOC-04 *(Example)* | Interface catalogue | Endpoints, formats, schedules, partner contacts, error handling | Integration lead | Integration support | [Link] | [Status] |
| DOC-05 *(Example)* | Batch schedule and rerun rules | Dependencies, timings, restart points | Technical lead | Platform operations | [Link] | [Status] |
| DOC-06 *(Example)* | Backup, restore and disaster recovery procedures | Recovery steps, objectives, test results | Platform engineer | Platform operations | [Link] | [Status] |
| DOC-07 *(Example)* | Security model | Roles, segregation of duties rules, privileged access procedure | Security engineer | Security operations | [Link] | [Status] |
| DOC-08 *(Example)* | Known errors and workarounds | Every known defect with symptom, cause and workaround | Test lead | Application support | [Link] | [Status] |
| DOC-09 *(Example)* | Configuration and environment register | Environments, versions, settings, licences | Platform engineer | Configuration manager | [Link] | [Status] |
| DOC-10 *(Example)* | Monitoring and alert catalogue | Every alert with meaning, threshold and runbook link | Technical lead | Platform operations | [Link] | [Status] |
| DOC-11 *(Example)* | Architecture decision records | Why the solution is built as it is | Solution architect | Development team | [Link] | [Status] |
| [DOC-NN] | [Document] | [Purpose] | [@author] | [@reviewer] | [Link] | [Status] |

Use the Runbook (`dev/runbook`) and Standard Operating Procedure
(`ops/sop`) templates for DOC-02 and DOC-03.

## 6. Knowledge transfer plan

<!-- Guidance: Plan sessions by audience and topic, with a method and a way to check that knowledge landed. Prefer hands-on sessions in a non-production environment over slide walkthroughs. Pitfall: recording sessions and calling the recordings "knowledge transfer". -->

### 6.1 Sessions

| ID | Topic | Audience | Method | Presenter | Duration | Planned date | Competence check |
|---|---|---|---|---|---|---|---|
| KT-01 *(Example)* | Solution overview and business processes | All receiving teams | Walkthrough with demo | Solution architect | 3 h | T-8 weeks | Quiz on process flows |
| KT-02 *(Example)* | Functional configuration by module | Application support | Hands-on in pre-production | Functional leads | 4 x 3 h | T-7 to T-6 weeks | Configure a change and explain its effect |
| KT-03 *(Example)* | Integration flows and error handling | Integration support | Hands-on, replay failed messages | Integration lead | 2 x 3 h | T-6 weeks | Diagnose and resolve 3 seeded failures |
| KT-04 *(Example)* | Batch schedule, reruns and period-end jobs | Platform operations | Hands-on | Technical lead | 3 h | T-5 weeks | Rerun a failed job chain from its restart point |
| KT-05 *(Example)* | Backup, restore and failover | Platform operations | Hands-on drill | Platform engineer | 4 h | T-4 weeks | Restore to a point in time, timed |
| KT-06 *(Example)* | Security model and access administration | Service desk, security operations | Walkthrough and practice | Security engineer | 2 h | T-4 weeks | Grant and revoke a role correctly |
| KT-07 *(Example)* | Ticket categories, known errors and scripts | Service desk | Role-play | Test lead and service desk lead | 2 h | T-2 weeks | Categorise 20 sample tickets |
| KT-08 *(Example)* | Code base, build and release pipeline | Development team | Pairing | Lead developer | 3 x 3 h | T-3 weeks | Build, test and deploy a small change to a test environment |
| [KT-NN] | [Topic] | [Audience] | [Method] | [@presenter] | [Duration] | [Date] | [Check] |

### 6.2 Attendance and competence record

| Engineer | Team | Sessions required | Sessions attended | Checks passed | Ready for reverse shadow? |
|---|---|---|---|---|---|
| [@name] *(Example)* | Application support | KT-01, KT-02, KT-07 | 3 of 3 | 3 of 3 | Yes |
| [@name] *(Example)* | Platform operations | KT-01, KT-04, KT-05 | 3 of 3 | 2 of 3 | No: repeat KT-05 drill |
| [@name] | [Team] | [IDs] | [N of N] | [N of N] | [Yes / No] |

## 7. Shadow and reverse shadow

<!-- Guidance: Shadowing shows the receiving team the real work; reverse shadowing proves they can do it. Define what must be observed and what must be done unaided. Pitfall: ending reverse shadow on a calendar date even though the receiving team has handled only a handful of tickets. -->

| Measure | Shadow (giving team works) | Reverse shadow (receiving team works) |
|---|---|---|
| Timing *(Example)* | Hypercare weeks 1 and 2 | Hypercare weeks 3 and 4 |
| Ticket handling | Receiving engineer observes each ticket class at least once | Receiving engineer resolves tickets; giving team reviews before closure |
| Runbook tasks | Receiving engineer observes each critical task | Receiving engineer performs each critical task unaided |
| On call | Giving team primary, receiving team secondary | Receiving team primary, giving team secondary |
| Exit measure *(Example)* | All ticket classes and tasks observed | At least 5 business days within targets; fewer than [number] tickets handed back to the giving team |

| Ticket class | Observed in shadow | Handled in reverse shadow | Handed back | Within target |
|---|---|---|---|---|
| Functional incident *(Example)* | Yes | 34 | 2 | 32 of 34 |
| Interface failure *(Example)* | Yes | 9 | 1 | 8 of 9 |
| Data fix request *(Example)* | Yes | 12 | 0 | 12 of 12 |
| Access request *(Example)* | Yes | 41 | 0 | 41 of 41 |
| [Class] | [Yes / No] | [N] | [N] | [N of N] |

## 8. Access, tooling and accounts

<!-- Guidance: List every access, tool and account the receiving teams need, and every project access that must be removed. Pitfall: the only administrator of a vendor portal or a cloud account being a contractor whose engagement ends at go-live. -->

| ID | Access or tool | Receiving team | Granted | Tested | Project access action | Done |
|---|---|---|---|---|---|---|
| ACC-01 *(Example)* | Application administration roles | Application support | YYYY-MM-DD | Yes | Project super-users removed | [ ] |
| ACC-02 *(Example)* | Cloud subscription operator role | Platform operations | YYYY-MM-DD | Yes | Project owner roles reduced to read | [ ] |
| ACC-03 *(Example)* | Monitoring and alerting tool | Platform operations | YYYY-MM-DD | Yes | Project alert routes removed | [ ] |
| ACC-04 *(Example)* | ITSM assignment groups and queues | Service desk, application support | YYYY-MM-DD | Yes | Project queue closed | [ ] |
| ACC-05 *(Example)* | Code repository and pipeline | Development team | YYYY-MM-DD | Yes | Contractor accounts removed at warranty end | [ ] |
| ACC-06 *(Example)* | Vendor support portal and licence administration | Supplier manager | YYYY-MM-DD | Yes | Ownership moved to the receiving organisation | [ ] |
| ACC-07 *(Example)* | Break-glass accounts and secret vault entries | Platform operations | YYYY-MM-DD | Yes | Credentials rotated after transfer | [ ] |
| [ACC-NN] | [Access] | [Team] | [Date] | [Yes / No] | [Action] | [ ] |

Confirm the result with an Access Review (`ops/access-review`) at
acceptance and again at warranty end.

## 9. Service management process integration

<!-- Guidance: Show how the new service plugs into each service management process the organisation runs, and who owns the link. Use your organisation's process names; the mapping columns help auditors and process owners. Pitfall: a service that is live but missing from the service catalogue, the CMDB or the continuity plan. -->

| Process or practice | ISO/IEC 20000-1:2018 clause | What is needed for this service | Process owner | Ready |
|---|---|---|---|---|
| Service catalogue management | 8.2.4 | Catalogue entry with description, users, hours and support route | [@name] | [ ] |
| Configuration management | 8.2.6 | CIs and relationships for every component in section 1 | [@name] | [ ] |
| Service level management | 8.3.3 | SLA, OLAs and reporting in place | [@name] | [ ] |
| Supplier management | 8.3.4 | Vendor contracts and contacts transferred | [@name] | [ ] |
| Capacity management | 8.4.3 | Capacity baseline and forecast handed over | [@name] | [ ] |
| Change management | 8.5.1 | Standard changes defined for routine tasks; change models for releases | [@name] | [ ] |
| Service design and transition | 8.5.2 | This plan and the acceptance criteria in section 4 | [@name] | [ ] |
| Release and deployment management | 8.5.3 | Release calendar and deployment procedure transferred | [@name] | [ ] |
| Incident management | 8.6.1 | Categories, priorities and assignment groups configured | [@name] | [ ] |
| Service request management | 8.6.2 | Request catalogue items and fulfilment workflows | [@name] | [ ] |
| Problem management | 8.6.3 | Known errors imported; open problems transferred | [@name] | [ ] |
| Service availability and continuity | 8.7.1, 8.7.2 | Availability targets, continuity and recovery plans updated | [@name] | [ ] |
| Information security management | 8.7.3 | Security controls, logging and access reviews in place | [@name] | [ ] |
| Knowledge | 7.6 | Knowledge articles published and owned | [@name] | [ ] |

ITIL 4 practice names such as release management, deployment
management, service validation and testing, knowledge management and
change enablement map to the same rows. ITIL (Version 5) has been
released in phases by PeopleCert during 2026; check how its current
publications name these practices before quoting them.

## 10. Monitoring, alerts and runbooks

<!-- Guidance: Every alert the receiving team will get must have a meaning, an owner and a runbook step. Pitfall: alerts that fired harmlessly during the project and were ignored, which the receiving team then learns to ignore too. -->

| ID | Alert | Meaning | Severity | Runbook step | Receiving owner | Tested |
|---|---|---|---|---|---|---|
| ALR-01 *(Example)* | Interface error queue above zero for 60 minutes | Messages are failing and not retried | 2 | DOC-02, integration runbook section 4 | Integration support | YYYY-MM-DD |
| ALR-02 *(Example)* | Batch job chain not complete by 05:30 | Morning reports and stock levels will be stale | 2 | DOC-05, rerun procedure | Platform operations | YYYY-MM-DD |
| ALR-03 *(Example)* | Certificate expires in 21 days | Renewal required | 3 | DOC-02, certificate renewal | Platform operations | YYYY-MM-DD |
| ALR-04 *(Example)* | Login failures above normal for a role | Possible access or credential issue | 3 | DOC-07, access troubleshooting | Security operations | YYYY-MM-DD |
| [ALR-NN] | [Alert] | [Meaning] | [Severity] | [Link] | [@owner] | [Date] |

Remove or tune any alert that has no action. Keep the Observability
Specification (`ops/observability-spec`) aligned with this table.

## 11. Open items transfer

<!-- Guidance: List every open defect, problem, change request, risk and piece of technical debt that the receiving teams inherit, with an owner and a date. Questions: which items are warranty defects that the giving team must still fix? Pitfall: a long list transferred without priorities, which the receiving team cannot plan. -->

| ID | Type | Description | Priority | Warranty item? | Receiving owner | Target date |
|---|---|---|---|---|---|---|
| OPEN-001 *(Example)* | Defect | Credit note archive export omits the PDF attachment for FR01 | 3 | Yes | Development team | YYYY-MM-DD |
| OPEN-002 *(Example)* | Problem | Intermittent timeout on partner interface 7 | 2 | Yes | Integration support | YYYY-MM-DD |
| OPEN-003 *(Example)* | Change request | Additional approval step for credit notes | 4 | No | Product owner | Release 2 |
| OPEN-004 *(Example)* | Technical debt | Manual certificate renewal for two endpoints | 3 | No | Platform operations | YYYY-MM-DD |
| OPEN-005 *(Example)* | Risk | Single engineer with batch expertise in the receiving team | 2 | No | Platform operations lead | YYYY-MM-DD |
| [OPEN-NNN] | [Type] | [Description] | [1 to 4] | [Yes / No] | [@owner] | [Date] |

## 12. Warranty and early life support

<!-- Guidance: Define what the giving team still owes after acceptance, for how long and at what response level. Pitfall: a warranty that covers "defects" without a definition, so every disagreement becomes a commercial dispute. -->

| Field | Value |
|---|---|
| Warranty period | *Example:* 60 calendar days from acceptance into service |
| What is covered | *Example:* Defects where the delivered solution does not meet the accepted specification, including defects found after acceptance |
| What is not covered | *Example:* Changes in requirements, defects caused by later changes made by the receiving teams, infrastructure outside the delivered scope |
| Giving team response | *Example:* Severity 1 within 2 hours, severity 2 within 1 business day, fixes through the normal change process |
| Early life support | *Example:* Named giving-team expert available 4 hours per week for questions |
| Contacts | [@name], [@name] |
| Commercial reference | [Contract or work order ID] |
| Warranty exit | All warranty defects fixed or accepted; final report issued |

## 13. Suppliers, contracts and costs

<!-- Guidance: Make sure contracts, licences and running costs move with the service, and that the receiving budget holder knows the run cost. Pitfall: cloud and licence costs still charged to a closed project code. -->

| Item | Current holder | Receiving holder | Renewal or end date | Annual cost *(Example)* | Done |
|---|---|---|---|---|---|
| Application licences | Project | IT asset management | YYYY-MM-DD | [Amount] | [ ] |
| Cloud subscription and cost centre | Project | Platform operations | Monthly | [Amount] | [ ] |
| Vendor support contract | Project | Supplier manager | YYYY-MM-DD | [Amount] | [ ] |
| Integration partner agreement | Project | Integration support | YYYY-MM-DD | [Amount] | [ ] |
| [Item] | [Holder] | [Holder] | [Date] | [Amount] | [ ] |

Add the service run cost to the receiving budget and review it in the
next FinOps Cost Review (`ops/finops-cost-review`) where cloud services
are involved.

## 14. Sign-off

<!-- Guidance: Sign acceptance into service once the criteria in section 4 are met or waived. Then sign warranty closure separately. Pitfall: the receiving owner signing under schedule pressure without the evidence, then inheriting a service they cannot run. -->

### 14.1 Acceptance into service

| Field | Value |
|---|---|
| Criteria met | [N of N] |
| Criteria waived | [IDs, reason, person accepting, expiry date] |
| Decision | [Accepted / Accepted with conditions / Not accepted] |
| Effective date and time | YYYY-MM-DD HH:MM |

| Role | Name | Signature statement | Date |
|---|---|---|---|
| Receiving service owner | [@name] | The service is accepted into operation | YYYY-MM-DD |
| Project manager | [@name] | The giving team has transferred all items in this plan | YYYY-MM-DD |
| Application support lead | [@name] | The team can support the service | YYYY-MM-DD |
| Platform operations lead | [@name] | The team can operate the platform | YYYY-MM-DD |

### 14.2 Warranty closure

| Role | Name | Statement | Date |
|---|---|---|---|
| Receiving service owner | [@name] | Warranty obligations met | YYYY-MM-DD |
| Giving team lead | [@name] | Warranty defects closed or accepted | YYYY-MM-DD |

### 14.3 Traceability

| Transferred item | Documentation | Knowledge transfer | Access | Acceptance criterion |
|---|---|---|---|---|
| TRN-002 Integration flows *(Example)* | DOC-04, DOC-10 | KT-03 | ACC-03, ACC-04 | OHO-AC-001, OHO-AC-004, OHO-AC-005 |
| TRN-003 Environments *(Example)* | DOC-06, DOC-09 | KT-05 | ACC-02, ACC-07 | OHO-AC-004, OHO-AC-006, OHO-AC-008 |
| TRN-004 Batch schedule *(Example)* | DOC-05 | KT-04 | ACC-03 | OHO-AC-004 |
| [TRN-NNN] | [DOC IDs] | [KT IDs] | [ACC IDs] | [AC IDs] |

## 15. Glossary and references

<!-- Guidance: Use the vocabulary of the receiving organisation's service management system. -->

### 15.1 Glossary

| Term | Meaning in this plan |
|---|---|
| Acceptance into service | Formal decision by the receiving owner to take operational responsibility |
| Giving team | Project or supplier team that built the service |
| Receiving team | Team that will run and support the service after acceptance |
| Knowledge transfer (KT) | Planned sessions and practice that build the receiving team's capability |
| Shadow | Receiving team observes the giving team doing the work |
| Reverse shadow | Receiving team does the work while the giving team observes |
| Early life support | Extra support from the giving team for a short period after acceptance |
| Warranty | Period in which the giving team fixes defects in what it delivered |
| OLA | Operational level agreement between internal teams |
| CMDB | Configuration management database |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC 20000-1:2018, Information technology, Service management, Part 1: Service management system requirements, iso.org | Third edition 2018, last reviewed and confirmed 2023; Amd 1:2024 (climate action changes) | Clause numbers in section 9 and the transition structure |
| ITIL (Version 5), PeopleCert, peoplecert.org | Phased release during 2026; ITIL 4 remains available; checked 2026-10-23 | Practice names for mapping only |
| Microsoft Dynamics 365 implementation guide, create a support strategy (transition to support), learn.microsoft.com | Page updated 2026-07-15 | Support scope, team and operations themes |
| Microsoft Dynamics 365 implementation guide, prepare your production environment to go live (support readiness), learn.microsoft.com | Page updated 2026-10-15 | Knowledge transfer and lines of support |
| AWS Prescriptive Guidance, Introduction to governance for large migrations, preparing the organization, docs.aws.amazon.com | Web edition checked 2026-10-23 | Runbooks, knowledge transfer and handoff to cloud operations |
| [Internal service management manual] | [Version] | [Process names and owners] |

## Standard and licence note

Structure aligned with ISO/IEC 20000-1:2018 clause 8.5 (service design,
build and transition) and the related clause structure for knowledge,
service portfolio, relationship, supply and demand, resolution and
assurance processes, with ITIL 4 practice names, and with the transition
to support guidance in the Microsoft Dynamics 365 implementation guide
and AWS Prescriptive Guidance for large migrations. ISO/IEC 20000-1 and
ITIL are copyrighted; this template cites clause numbers and short
process or practice names only and reproduces no requirement text,
definition or table. ITIL is a registered trademark of the PeopleCert group.
Microsoft, Dynamics 365, Amazon Web Services and AWS are trademarks of
their owners; this template is not affiliated with or endorsed by them.
This template is original text written for this collection. Check the
current official standard and guidance versions before use. Template
licence: MIT.