Technical Succession Planning
Technical succession planning encompasses the systematic identification, documentation, and transfer of IT knowledge and capabilities to prevent operational disruption when staff depart. Unlike general HR succession planning, which addresses role coverage and career development, technical succession focuses specifically on the tacit knowledge, system access, vendor relationships, and operational expertise that reside with individual IT staff members. Organisations with small IT teams face acute succession risk because a single departure can eliminate the only person who understands a critical system, holds administrative credentials, or maintains a key vendor relationship.
- Tacit knowledge
- Expertise that exists only in someone’s experience and judgement, never formally documented. Examples include knowing which server requires manual intervention after power restoration, understanding why a particular configuration exists, or recognising the early warning signs of a specific system failure.
- Bus factor
- The minimum number of people who would need to be incapacitated (the canonical example being struck by a bus) before an organisation loses the ability to perform a function. A bus factor of one indicates critical single-person dependency.
- Knowledge decay
- The progressive loss of operational knowledge as staff depart without adequate transfer, documentation becomes outdated, or institutional memory fragments across personnel changes.
- Handover period
- The interval between announcing departure and final working day during which knowledge transfer occurs. Standard notice periods provide 2-4 weeks; complex roles require 4-8 weeks for adequate transfer.
- Shadow access
- Secondary credentials or access paths that enable continuity when primary account holders depart. Includes break-glass accounts, shared administrative credentials with documented custody, and delegated access arrangements.
Knowledge Criticality Assessment
Not all knowledge carries equal succession risk. A structured criticality assessment identifies where to concentrate succession planning effort by evaluating knowledge against two dimensions: impact if lost and current redundancy. Knowledge with high impact and low redundancy demands immediate attention, while widely shared, low-impact knowledge requires minimal intervention.
Impact measures the operational consequence of knowledge loss. System administrative knowledge for the finance platform affects payroll, procurement, and financial reporting, producing high impact. Knowledge of an archived project’s file naming conventions affects only occasional reference lookups, producing low impact. Impact assessment considers both the systems involved and the frequency and criticality of activities requiring that knowledge.
Redundancy measures how many people currently hold the knowledge. If three staff members can configure the email system, redundancy is high. If only one person understands the integration between the case management system and the payment provider, redundancy is one (the minimum) and succession risk is acute.
+------------------------------------------------------------------------+| KNOWLEDGE CRITICALITY MATRIX |+------------------------------------------------------------------------+| || HIGH | Moderate Priority | Critical Priority || IMPACT | (Document within | (Immediate action: || | 3 months) | cross-train + document) || | | || | - Email system | - Finance system admin || | administration | - Network infrastructure || | - User provisioning | - Security tooling || | - Backup operations | - Cloud platform access || | | - Vendor relationships || | | |+----------+-----------------------+-------------------------------------+| | | || LOW | Low Priority | Moderate Priority || IMPACT | (Document when | (Reduce single-person || | convenient) | dependency) || | | || | - Legacy archive | - Specialist reporting || | locations | - Custom script maintenance || | - Historical config | - Niche troubleshooting || | rationale | || | | |+----------+-----------------------+-------------------------------------+ | HIGH REDUNDANCY | LOW REDUNDANCY | | (2+ people) | (1 person) | +-------------------------------------------------------------+Figure 1: Knowledge criticality matrix mapping impact against redundancy
The assessment produces a prioritised inventory. For a five-person IT team supporting a humanitarian organisation, a typical assessment might identify:
| Knowledge area | Current holder(s) | Redundancy | Impact | Priority |
|---|---|---|---|---|
| Azure AD administration | James | 1 | High | Critical |
| Network firewall configuration | James | 1 | High | Critical |
| Primero case management | Sarah | 1 | High | Critical |
| Finance system (Sage) | Sarah, Michael | 2 | High | Moderate |
| Backup restoration | Michael | 1 | High | Critical |
| Website CMS | Three staff | 3 | Medium | Low |
| Legacy donor database | James | 1 | Low | Moderate |
This assessment reveals four critical succession risks requiring immediate action and two moderate risks requiring documentation within a defined timeframe. The website CMS, with three knowledgeable staff and medium impact, requires no immediate succession intervention.
Single Points of Failure
A single point of failure in IT staffing exists when exactly one person holds knowledge, credentials, or relationships necessary for a function. Identifying these points requires systematic examination across several categories.
System administrative access represents the most common single point of failure. If one person holds the only global administrator credentials for Microsoft 365, their sudden departure blocks all administrative functions until credential recovery procedures complete. Recovery from cloud providers takes 5-15 business days and requires identity verification that departing staff cannot provide.
Undocumented system knowledge creates failures that manifest slowly. The person who configured the integration between the HR system and Active Directory departs without documenting the connection. The integration continues functioning until the HR system upgrades, breaking the integration. No remaining staff understand the original design, and reconstruction requires expensive consultant engagement.
Vendor relationships concentrate in individuals more than organisations recognise. The IT manager who negotiated the Microsoft nonprofit grant, established the relationship with the internet service provider, and maintains contact with the managed security provider holds relationship capital that does not automatically transfer to successors.
+------------------------------------------------------------------------+| SINGLE POINT OF FAILURE IDENTIFICATION |+------------------------------------------------------------------------+| || SYSTEM ACCESS KNOWLEDGE RELATIONSHIPS || +----------------+ +----------------+ +----------------+ || | | | | | | || | Cloud admin | | Integration | | Vendor | || | credentials | | architecture | | contacts | || | ^ | | ^ | | ^ | || | | | | | | | | | || +-----+----------+ +-----+----------+ +-----+----------+ || | | | || +-----v----------+ +-----v----------+ +-----v----------+ || | | | | | | || | Security tool | | Custom scripts | | Support | || | administration | | and automation | | contracts | || | ^ | | ^ | | ^ | || | | | | | | | | | || +-----+----------+ +-----+----------+ +-----+----------+ || | | | || +-----v----------+ +-----v----------+ +-----v----------+ || | | | | | | || | Network | | Historical | | Nonprofit | || | infrastructure | | decisions | | programme | || | | | | | eligibility | || +----------------+ +----------------+ +----------------+ || || MITIGATION: MITIGATION: MITIGATION: || - Break-glass accts - Documentation - Relationship map || - Credential escrow - Architecture - Named backups || - Secondary admins decision records - Vendor notification || - Code comments |+------------------------------------------------------------------------+Figure 2: Categories of single points of failure with mitigation approaches
Quantifying single point of failure exposure provides management visibility. Calculate exposure as:
SPOF Exposure Score = Sum of (Impact Score × 1/Redundancy) for each knowledge area
Where:- Impact Score: 3 (High), 2 (Medium), 1 (Low)- Redundancy: Number of people holding the knowledge
Example calculation for five-person IT team:- Azure AD admin: 3 × 1/1 = 3.0- Network firewall: 3 × 1/1 = 3.0- Finance system: 3 × 1/2 = 1.5- Backup restoration: 3 × 1/1 = 3.0- Website CMS: 2 × 1/3 = 0.67- Legacy database: 1 × 1/1 = 1.0
Total SPOF Exposure Score: 12.17
Benchmark: Score above 10 indicates elevated succession risk Score above 15 indicates critical succession riskKnowledge Transfer Mechanisms
Knowledge transfer from departing staff to remaining team members or successors operates through four primary mechanisms, each suited to different knowledge types and timeline constraints.
Documentation converts tacit knowledge into explicit, persistent form. This mechanism works well for procedural knowledge (how to perform backup restoration), architectural knowledge (why systems connect in particular ways), and reference knowledge (credential locations, vendor contacts, licence keys). Documentation fails for judgement-based knowledge (recognising anomalous system behaviour) and relationship knowledge (vendor negotiation approaches). Creating documentation during normal operations costs approximately 2 hours per significant system; creating documentation during a compressed handover period costs 4-6 hours due to time pressure and the need to simultaneously explain to successors.
Shadowing pairs the departing staff member with a successor who observes and gradually assumes responsibilities. The departing person performs tasks while explaining their reasoning, then observes while the successor performs tasks and provides feedback. Shadowing transfers judgement-based and procedural knowledge effectively but requires sufficient handover period. A meaningful shadowing arrangement for a complex role requires minimum 3 weeks with at least 50% time allocation from both parties.
Cross-training distributes knowledge across multiple team members before any departure occurs. Rather than creating documentation for emergency reference, cross-training builds active competency in secondary staff. Cross-training requires ongoing time investment: rotating responsibility for systems across team members, pairing on complex tasks, and ensuring multiple people perform each critical function at least quarterly. The investment prevents crisis-mode knowledge transfer when departures occur.
Reverse engineering reconstructs knowledge after the knowledgeable person has departed. This mechanism is expensive and unreliable, requiring examination of systems, configurations, and documentation to infer original intent. Reverse engineering a complex integration that was built over months can require weeks of investigation. This mechanism represents failure of succession planning, not a planned transfer approach.
+-------------------------------------------------------------------------+| KNOWLEDGE TRANSFER APPROACHES |+-------------------------------------------------------------------------+| || PROACTIVE REACTIVE || (Before departure known) (After departure known) || || +--------------------------+ +--------------------------+ || | | | | || | CROSS-TRAINING | | SHADOWING | || | | | | || | Ongoing investment | | Time-bounded transfer | || | Multiple staff learn | | Departing teaches | || | Rotation of duties | | successor | || | | | | || | Cost: 4-8 hrs/month | | Cost: 40-80 hrs total | || | per system | | over handover period | || | | | | || +--------------------------+ +--------------------------+ || | | || v v || +--------------------------+ +--------------------------+ || | | | | || | DOCUMENTATION | | REVERSE ENGINEERING | || | | | | || | Persistent reference | | Post-departure | || | Procedures, configs, | | reconstruction | || | architecture records | | Expensive, unreliable | || | | | | || | Cost: 2 hrs/system | | Cost: 20-100 hrs | || | initial + maintenance | | per complex system | || | | | | || +--------------------------+ +--------------------------+ || || EFFECTIVENESS BY KNOWLEDGE TYPE: || || Procedural --> Documentation, Shadowing (High transfer) || Architectural --> Documentation (Medium transfer) || Judgement --> Shadowing, Cross-training (Medium transfer) || Relationship --> Shadowing, Introductions (Low transfer) || Tacit/Intuitive -> Cross-training only (Difficult transfer) |+-------------------------------------------------------------------------+Figure 3: Knowledge transfer approaches with cost estimates and effectiveness
The selection of transfer mechanism depends on available time and knowledge type. With 4 weeks notice and a complex technical role, effective transfer combines shadowing (2 weeks of paired work) with documentation (capturing what shadowing cannot transfer) and introductions (connecting successor to vendor and partner contacts). With 2 weeks notice, documentation takes priority over shadowing because persistent artifacts provide ongoing reference after the departing person leaves. With no notice (sudden departure), remaining staff face reverse engineering combined with emergency vendor support engagement.
Handover Structure and Timeline
A structured handover converts the departing person’s knowledge into transferable form within the available notice period. The handover produces documentation, trained successors, transferred relationships, and updated access arrangements.
+--------------------------------------------------------------------------------+| HANDOVER TIMELINE (4-WEEK EXAMPLE) |+--------------------------------------------------------------------------------+| || WEEK 1 WEEK 2 WEEK 3 WEEK 4 || Inventory + Knowledge Supervised Final || Planning Transfer Handover Wrap-up || || +----------------+ +----------------+ +----------------+ +---------------+ || | | | | | | | | || | Knowledge | | Documentation | | Successor | | Access | || | inventory | | creation | | performs | | transfer | || | | | | | tasks | | | || | Priority | | Shadowing | | | | Final | || | assessment | | sessions | | Departing | | document | || | | | | | observes | | review | || | Successor | | Vendor | | | | | || | identification | | introductions | | Issue | | Handover | || | | | | | resolution | | sign-off | || | Handover | | Credential | | | | | || | plan creation | | documentation | | Gap | | Exit | || | | | | | identification | | interview | || +----------------+ +----------------+ +----------------+ +---------------+ || || DELIVERABLES: DELIVERABLES: DELIVERABLES: OUTPUT: || - Knowledge map - System docs - Validated - Complete || - Priority list - Runbooks competency handover || - Handover plan - Contact list - Issue log document || - Successor - Credential - Remaining - Signed || assignment inventory gaps list access || |+--------------------------------------------------------------------------------+Figure 4: Four-week handover timeline with weekly activities and deliverables
Week one establishes scope and priorities. The departing person creates a knowledge inventory listing all systems, relationships, credentials, and responsibilities they hold. The IT manager (or next senior person if the IT manager is departing) assesses priorities using the criticality matrix and identifies successors for each knowledge area. Some knowledge transfers to a single successor; other knowledge distributes across multiple team members to prevent recreating single points of failure.
Week two focuses on knowledge transfer. The departing person creates or updates documentation for critical systems, conducts shadowing sessions with successors, introduces successors to key vendor and partner contacts, and documents credential information in the organisation’s secure credential store. Documentation should follow organisational standards; if no standards exist, the handover creates documentation that can serve as a template for future use.
Week three reverses the teaching relationship. Successors perform tasks while the departing person observes, providing correction and additional context. This supervised practice validates that transfer has occurred and surfaces gaps that require additional attention. Issues that arise go into a gap log for resolution before departure.
Week four completes access transitions, conducts final document review, and formalises the handover through sign-off. The departing person completes an exit interview covering any remaining undocumented knowledge, outstanding issues, and recommendations for their successor.
Compressed timelines require prioritisation. With only 2 weeks available, focus entirely on critical-priority knowledge areas, create documentation rather than conducting extensive shadowing, and accept that some knowledge gaps will require post-departure resolution. With 1 week or less, document credentials and vendor contacts, identify the highest-risk systems, and create enough documentation that remaining staff can engage vendors or consultants for assistance.
Access and Credential Continuity
Departing staff typically hold credentials that must transfer to successors without creating security vulnerabilities. The credential categories requiring succession planning include administrative accounts for systems and platforms, service accounts used by integrations and automations, vendor portal access, and certificate or key material.
Administrative account succession varies by platform. Cloud platforms (Microsoft 365, Google Workspace, AWS, Azure) support multiple global administrators. Organisations should maintain minimum two global administrators at all times, with one serving as the primary and another as backup. When the primary administrator departs, the backup becomes primary, and a new backup administrator receives elevation before the departing person’s access terminates.
Break-glass accounts provide emergency access independent of individual staff. These accounts use strong, unique credentials stored in secure, documented locations (hardware security keys in a safe, passwords in sealed envelopes with custody signatures, or encrypted credential vaults with multiple key holders). Break-glass accounts remain dormant during normal operations and activate only when normal administrative access fails. Testing break-glass access quarterly verifies continued functionality.
Service account credentials require inventory and rotation planning. Integrations between systems often authenticate using credentials configured by whoever built the integration. Departing staff should document all service accounts they created or manage, including the systems involved, credential locations, and rotation procedures. Successor staff rotate these credentials after departure to prevent continued access through remembered credentials.
Vendor portal access often ties to individual email addresses. The departing person should transfer administrative ownership of vendor accounts to a successor or shared administrative account before departure. Key vendor portals include licensing portals (Microsoft Volume Licensing, nonprofit programme accounts), support portals (for systems under maintenance), and infrastructure provider consoles (cloud providers, ISPs, telephony providers).
ACCESS TRANSITION CHECKLIST
Cloud Platforms:[ ] Verify minimum 2 global administrators exist for Microsoft 365[ ] Verify minimum 2 global administrators exist for Google Workspace[ ] Verify minimum 2 administrators exist for each cloud provider (AWS, Azure, GCP)[ ] Successor elevated before departing admin removed
On-Premises Infrastructure:[ ] Domain admin credentials documented[ ] Network equipment admin access documented[ ] Security appliance access documented[ ] Break-glass procedure tested within last 90 days
Service Accounts:[ ] Inventory of service accounts created by departing person[ ] Credential rotation scheduled for post-departure[ ] Integration documentation updated with credential locations
Vendor Portals:[ ] Microsoft Volume Licensing portal ownership transferred[ ] Nonprofit programme accounts ownership transferred[ ] Support portal access transferred or shared account documented[ ] ISP and telephony provider portal access transferred[ ] Domain registrar access documented with minimum 2 authorised contacts
Certificates and Keys:[ ] SSL/TLS certificate inventory current[ ] Certificate renewal responsibilities assigned[ ] SSH keys inventoried and ownership transferred[ ] API keys inventoried with rotation scheduleVendor and Partner Relationship Continuity
IT staff accumulate relationship capital with vendors, partners, and service providers that provides value beyond mere contact information. The IT manager who has worked with the Microsoft account team for three years understands their nonprofit’s history with Microsoft, knows which escalation paths produce results, and has established credibility that accelerates issue resolution. This relationship value does not automatically transfer to successors.
Preserving vendor relationships requires active introduction before departure. The departing person should schedule introduction calls or meetings with key vendor contacts, explicitly transferring the relationship to the successor. During these introductions, the departing person briefs the vendor contact on the successor’s role and provides context the successor needs to continue the relationship effectively.
The vendor relationship inventory captures contacts that require introduction:
| Vendor | Relationship holder | Contact name | Introduction needed |
|---|---|---|---|
| Microsoft | James (departing) | Sarah Chen, Account Manager | Yes, schedule call |
| ISP | James (departing) | Support queue only | No introduction needed |
| Managed security | James (departing) | Tom Wilson, Service Manager | Yes, schedule call |
| ITSM vendor | Sarah | Support queue only | No introduction needed |
| Data platform | Michael | Jennifer Adams, Customer Success | Document contact only |
Partner relationships with implementing organisations, consortium members, or technology partners require similar transfer. If the departing IT person has been the primary contact for IT coordination with partner organisations, successors need introduction to their counterparts.
Vendor contract knowledge extends beyond contacts. The departing person should document contract terms relevant to IT operations: service level commitments, renewal dates, pricing structures, negotiation history, and nonprofit programme terms. This documentation enables successors to manage vendor relationships and negotiate renewals without disadvantage.
Emergency Succession
Some departures occur without notice: sudden illness, resignation without notice period, termination for cause, or death. Emergency succession procedures activate when normal handover is impossible, focusing on restoring operational capability rather than comprehensive knowledge transfer.
The emergency succession response addresses immediate operational needs within the first 72 hours. Remaining staff must identify critical functions the departed person performed, establish who will cover each function, and determine what access the departed person held that others need.
EMERGENCY SUCCESSION RESPONSE (72-HOUR PRIORITIES)
Hour 0-4: Access Assessment+-------------------------------------------------------------------+| || 1. Identify all systems where departed person held admin access || 2. Verify alternative admin access exists for each system || 3. For systems with no alternative admin, invoke break-glass || 4. Disable departed person's accounts (User Offboarding process) || |+-------------------------------------------------------------------+
Hour 4-24: Critical Function Coverage+-------------------------------------------------------------------+| || 1. List critical IT functions (from service catalogue) || 2. Identify which functions departed person performed || 3. Assign interim coverage for each function || 4. Identify immediate knowledge gaps blocking function || 5. Engage vendor support for critical gaps || |+-------------------------------------------------------------------+
Hour 24-72: Stabilisation+-------------------------------------------------------------------+| || 1. Document departed person's system state where accessible || 2. Review departed person's files, emails for documentation || 3. Contact vendors to update authorised contacts || 4. Create prioritised list of knowledge reconstruction needs || 5. Engage consultants if critical expertise missing || |+-------------------------------------------------------------------+Emergency succession exposes gaps that planned succession would prevent. The first emergency succession event in an organisation typically reveals inadequate credential documentation, missing break-glass procedures, and undocumented vendor relationships. Use the post-emergency review to strengthen succession planning for future departures.
Organisations can reduce emergency succession impact through standing practices that maintain knowledge redundancy. The section on Implementation Considerations addresses these practices scaled to different organisational contexts.
Organisational Memory Preservation
Individual departures accumulate into organisational memory loss when historical context leaves faster than documentation captures it. The person who built the network five years ago leaves, then the person who maintained it for three years leaves, and remaining staff face infrastructure they do not understand and cannot find documentation for.
Architecture decision records preserve the reasoning behind significant choices. When the organisation chose Keycloak over Okta for identity management, someone understood the requirements, evaluated options, and made a decision. Recording that decision, including options considered, criteria applied, and rationale for the choice, enables future staff to understand why systems exist in their current form. Without this record, future staff may waste effort re-evaluating settled decisions or may change configurations without understanding why they were originally made.
System lineage documentation tracks how systems evolved. The current finance system integration exists because of a sequence of changes over several years, each responding to requirements at the time. Documenting this lineage helps future staff understand which components are load-bearing (cannot change without breaking something) versus incidental (could be simplified or removed).
Incident and problem records preserve operational knowledge. The database slowdown three years ago, which took two weeks to diagnose as a storage configuration issue, contains diagnostic knowledge that applies to future similar problems. If incident records exist only in the memory of staff who have since departed, future staff will repeat the diagnostic process from scratch.
The documentation decay rate measures how quickly organisational documentation becomes unreliable after the documenting person departs. Without maintenance, technical documentation becomes inaccurate within 12-18 months as systems change but documentation does not. Succession planning must include documentation ownership transfer, not just creation.
Implementation Considerations
For organisations with minimal IT function
Organisations where one person handles IT alongside other responsibilities face acute succession risk because all IT knowledge concentrates in a single individual. The departure of that person eliminates all IT expertise simultaneously.
Mitigation focuses on documentation and external relationships rather than internal cross-training (which is impossible with one IT person). Critical documentation includes system credentials, vendor contacts, support contract details, and basic operational procedures. This documentation should be accessible to non-IT staff (such as the finance director or executive director) who would coordinate IT coverage during a vacancy.
Establishing relationships with external support providers before a crisis provides succession backup. A managed service provider or IT consultant engaged for occasional support can provide emergency coverage if the IT person departs suddenly. This relationship costs money to maintain but provides insurance against complete IT capability loss.
Document the IT function’s scope clearly enough that the organisation can hire an appropriate replacement. The departing IT person should create a role description based on actual responsibilities, not the potentially outdated job description. Include systems managed, services provided, vendor relationships held, and typical time allocation across activities.
For organisations with small IT teams
Teams of 2-5 IT staff can implement meaningful cross-training but must do so intentionally. Without deliberate effort, specialisation develops and single points of failure emerge. The network specialist handles all networking; the applications person handles all application support; each develops knowledge the other lacks.
Structured rotation addresses specialisation drift. Each team member should perform unfamiliar functions at least quarterly, supervised by the primary knowledge holder. This maintains baseline competency across the team and prevents knowledge from concentrating entirely in individuals.
Pair work for significant changes builds shared knowledge during normal operations. When implementing a new integration or making significant configuration changes, two team members work together rather than one working alone. The second person learns the system while contributing to implementation quality through review.
Documentation review during team meetings surfaces outdated materials. Allocating 15 minutes per team meeting to review one piece of documentation identifies decay before it becomes problematic. The reviewer checks that procedures still match actual system behaviour and that contact information remains current.
For organisations with established IT functions
Larger IT departments face different succession challenges: specialisation is necessary and valuable, so the goal becomes managing rather than eliminating single points of failure. Knowledge management systems, formal documentation standards, and structured handover processes provide institutional capability that persists across individual departures.
Secondary expertise assignments formalise redundancy. Each system or function has a primary owner and an assigned secondary. The secondary maintains enough competency to assume primary responsibility during absences or departures, typically through quarterly engagement with the system and documentation review.
Departure triggers structured assessment. When any IT staff member announces departure, the manager initiates knowledge assessment using the criticality matrix, creates a handover plan proportionate to the role complexity, and schedules handover activities into the notice period. This routine process ensures consistency regardless of the individual departing.
Succession planning integrates with performance management. Annual reviews include assessment of documentation currency and cross-training participation. Staff who consistently maintain documentation and share knowledge receive recognition; knowledge hoarding receives management attention.
For federated organisations
Organisations with autonomous offices or units face succession challenges both within IT and for IT coordination between units. The regional IT coordinator who understands how three country offices share infrastructure creates a succession risk that affects multiple offices simultaneously.
Cross-unit documentation standards enable knowledge to transfer between offices. When all offices document their systems using consistent formats, staff transitioning between offices can understand unfamiliar systems more quickly. Shared documentation repositories provide visibility into how other offices have solved similar problems.
Regional or global backup for specialist knowledge reduces local succession risk. If only one person in the East Africa region understands the SIEM implementation, a global security specialist can provide backup coverage while local replacement recruiting occurs. This distributed backup model requires coordination and capacity at the regional or global level.
Handover Document Template
The handover document consolidates succession-relevant information for a departing IT staff member. Successors receive this document alongside any transferred credentials, documentation, and relationship introductions. The departing person creates this document during the first week of the handover period and updates it throughout.
Handover Document
Departing staff member: [Name] Role: [Job title] Last working day: [Date] Primary successor: [Name] Handover document version: [Date of last update]
Systems and Responsibilities
For each system or function this person owns or significantly supports, document:
System/Function name:
Role: [Primary owner / Secondary support / Integration maintainer]
Knowledge level: [Sole expert / Primary expert with backup / Shared expertise]
Successor assigned: [Name]
Documentation location: [Link to system documentation]
Credential location: [Reference to credential store entry]
Key contacts: [Vendor support, internal stakeholders]
Outstanding issues: [Any unresolved problems or pending changes]
Handover activities completed:
- Documentation reviewed/updated
- Shadowing session completed
- Successor performed supervised task
- Successor can perform independently
Vendor and Partner Relationships
| Vendor/Partner | Contact name | Contact details | Relationship introduced | Notes |
|---|---|---|---|---|
| [ ] Yes [ ] N/A |
Credentials and Access
| System | Account type | Credential location | Successor access confirmed |
|---|---|---|---|
| [ ] Yes |
Pending Items
| Item | Priority | Assigned to | Target date | Notes |
|---|---|---|---|---|
Knowledge Not Transferred
Document any knowledge or expertise that could not be transferred during the handover period, including reason and recommended mitigation:
| Knowledge area | Reason not transferred | Recommended mitigation |
|---|---|---|
Departing Staff Recommendations
[Free-form section for the departing person to provide advice, identify risks, suggest improvements, or highlight issues the successor should address]
Sign-off
Departing staff member: _________________________ Date: _____________
Primary successor: _________________________ Date: _____________
Manager: _________________________ Date: _____________