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.
Document control
| 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
1. Scope and services transferred
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
| 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 |
3. Target support model
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
| 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
| 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
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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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
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.