Before you start
A service you currently run alone and a colleague who does not.
Agree the scope and recovery plan with the service owner. Adapt the exercise to your environment.
Define what the receiving team is taking on
Name the service, its users, the business owner and the receiving support team. Agree support hours and the tasks that are actually transferring. Record work that remains with a supplier or project team. Ask the recipient which routine and failure scenarios they need to handle. A handover cannot be accepted meaningfully if the two teams are describing different responsibilities.
Write a one-page service map
Describe what the service does and list its principal dependencies, monitoring location, support contacts and renewal or certificate dates. Add a small diagram where it explains a relationship more clearly than text. Distinguish tested recovery capability from a requested target. Keep the map focused on what an operator needs to locate the service and assess impact; link to deeper design information where it exists.
Document a routine task and a failure response
Choose a common task and explain its prerequisite, exact target, actions, expected result and stop condition. Then document one common failure: how to recognise it, what evidence to collect and when to escalate. For a scheduled import, explain how to establish whether retrying can create duplicates. Use an approved test environment for the practical exercise where an action can alter data or interrupt service.
Verify the access route
Reference the credential vault, access request and approver rather than embedding secrets. Ask the receiving operator to obtain the required access through that process before the exercise. Confirm permissions are sufficient for the agreed task and no broader than necessary. If approval is unavailable outside office hours, record the consequence for the support arrangement. A working administrator session on the author’s laptop does not prove the receiving team has access.
Run an observed exercise
Give a colleague the pack and ask them to complete the selected task without routine coaching. Agree the boundaries and a stop signal first. Observe where they hesitate, make an incorrect assumption or need missing information. Interrupt if they approach an unsafe action; record why the instructions did not prevent it. The purpose is to test the pack, not the colleague’s ability to guess what its author intended.
Repair and retest the gaps
Turn each stopping point into a concrete change: identify the correct console, define the success signal, add an approval route or explain an error. Repeat the affected steps with the receiving operator. Mark anything not exercised as untested rather than treating a document review as an execution test. If a gap cannot be fixed before transfer, give it an owner, an escalation route and an agreed temporary support arrangement.
Record acceptance and maintenance
Have the receiving team and service owner confirm the scope, checks completed and open actions. Name who updates the pack after changes and when it will next be reviewed. Store it in the normal service documentation location and remove obsolete competing copies or point them at the current version. Repeat a practical check after significant changes to access, dependencies or operating procedures.
What you should leave with
A service pack the receiving operator has used, an acceptance record with explicit scope, and an action list for any remaining gaps. Another person should be able to find the current instructions and the person who maintains them.