In this note
The service has a runbook, a dashboard, and a folder of tests. Then the person who built it takes a week off. An alert arrives, the reviewer queue stops moving, and the team has to decide whether to pause intake or retry an uncertain action. The useful handoff evidence is what they can do next without calling that person.
I'd rehearse that situation before the builder leaves. Give the receiving team a safe test environment, a small change, and the records they would have during a failure. Keep the builder available to prevent harm, but record every intervention. Help during an exercise can be sensible; it also shows where the team is not ready to work alone.
The invoice example below is a hypothetical rehearsal plan, not a completed handoff. Its receiving team has not performed the exercises, and its working agreements and time requirements are still open. The download supplies the rehearsal sheet, not a runnable service. The transfer remains blocked.
Give each operating decision an owner
Start by agreeing what the service may do. Here, it collects invoice facts and prepares a correction for a reviewer. It cannot gain permission to post to a ledger because a new team inherits the code. A posting feature would need separate approval, current policy checks, protection against duplicate changes, and confirmation in the ledger.
| Role | Decision and limit |
|---|---|
| Accounts-payable workflow owner | Decides which cases belong and what counts as a correct result. May narrow the work, but cannot waive finance policy. |
| Receiving service owner | Owns incoming work, incidents, support, and service reviews. Can pause the service under the agreed response plan. |
| Receiving engineer and qualified backup | Run the tests, investigate a failure, prepare a compatible change, and restore the previous version using their own permitted access. |
| Finance controls approver | Checks expected answers and important policy decisions separately from the person making the change, where required. |
| Release authority | Decides whether the tested change may go live. Completing this rehearsal does not grant release permission. |
One person can fill several roles if policy permits and they have time. An approval that must be independent still needs someone else. If the building team will run the service permanently, do the rehearsal with its qualified backup. You don't need to invent a separate receiving organization to test whether anyone else can run it.
Make the exercise safe enough to run
Use an approved non-production environment with permitted test records. Check the actual destinations and credentials, disable unintended external actions, and name who can stop the exercise. A tool labeled sandbox can still be dangerous if it holds production credentials.
Give the engineer the current release, previous version, source and policy versions, test instructions, alert contacts, and recovery steps. Have the backup find the same material. Check both people's access without borrowing the builder's account. A runbook that opens only for its author will fail at the first step.
For this plan, reserve two hours for the engineer, one for the backup, thirty minutes for the controls approver, and thirty for the release authority. Those are planning allowances, not measured durations. If time runs out, stop or split the rehearsal rather than remove checks to fit the meeting.
Let the receiving team lead the change and failure
Start with the proposed test-case exercise. Ask the receiving engineer to choose a permitted invoice exception and add it to the tests. The controls approver checks the expected answer against the invoice records and applicable policy. Then the engineer supplies a deliberately wrong result to the grader, the software that checks outputs. It should reject that result. Include a request that must be refused for lack of permission too.
| Exercise | Evidence to retain before marking it demonstrated |
|---|---|
| Add an evaluation case | The saved exception and unauthorized-request cases, the separately checked expected answers, and the grader's rejection of a deliberately bad result. |
| Prepare one bounded change | The exact changed version, decisions it affects, relevant test results, compatibility checks, and the authorized decision to release it or keep it on hold. |
| Restore the baseline | The previous version and its settings restored in the test environment, with a checked result. Reverting one file may leave incompatible settings behind. |
| Respond to an alert | The right person receives the alert and can pause new work. Someone remains responsible for pending cases and knows when to review them. |
| Reconcile a lost receipt | The engineer uses the original operation ID and permitted records from the receiving system to work out what happened, without blindly repeating the change. |
| Support and retire | An operator knows who will help. The shutdown plan covers access, schedules, pending work, records to retain, and how work continues afterward. |
The engineer can prepare and test a change without permission to release it. Before a real release, the authorized owner still needs evidence from the actual system, compatible versions, rollout limits, monitoring, and a tested way to recover. A successful rehearsal may still leave the release blocked for another reason.
Restoring old code won't undo a correction already written to a ledger. Check the original operation in the authorized source system before deciding what to retry. Save the last confirmed state and assign someone to unresolved results. A restart or new software version must not treat them as brand-new requests.
Have an observer note what the engineer completed alone, where instructions were missing, and when the builder helped. Save those observations where the person accepting the handoff can inspect them. Repair the gaps and repeat the failed steps. Attending the meeting is not evidence that someone can run the service.
Rehearse shutdown with work still pending. Decide who finishes those cases, which records must remain available, and who takes the manual workload. Stop schedules and revoke access through the authorized process without losing required records. Ask the backup to show how the team will confirm that new work has stopped while uncertain past changes remain available to investigate.
Put later support in the budget
The receiving team's time can be missing from a pilot budget. For the next twenty-eight days, suppose we reserve six engineer hours, two backup hours, and four support hours. Price the first two roles at USD 75 an hour and support at USD 40. That assigns USD 760 of labor cost to the service; it doesn't mean payroll or cash spending increases by that amount.
Add USD 180 for infrastructure and tools, plus USD 160 for routine checking outside those reserved hours. The period's planned allocation is USD 1,100. Count each piece of work once. This is only part of the service's cost, and we have no benefit, accepted-volume, or business-loss figures, so it cannot establish a return on investment.
Four extra engineer hours add USD 300 and take the allocation to USD 1,400. This shows how an assumption changes the budget; it is not an incident forecast. Can the team supply that time within the service's cost limit? If not, the service owner needs to reduce incoming work, arrange qualified cover, repair the problem, or stop the service.
At the next review, compare the plan with time recorded on support, incidents, source changes, testing, and operator work. Look at accepted results and pending queues too. The builder may get fewer calls because users have gone back to a spreadsheet. Keep their workload visible alongside the receiving team's.
Book the first exercise
The worksheet contains the proposed people, time, exercises, budget, and unanswered questions. Every exercise is still marked not run, so this handoff remains blocked. The receiving service owner needs to agree dates and reserve time with the people involved.
If the builder will provide temporary help afterward, agree what it covers, the maximum hours, who requests it, and when it ends. The receiving or retained internal team still owns normal operation. A new data source or major policy change may justify bringing the builder back for a defined job, not leaving every future problem with them.
Choose one exercise the backup should lead this month. Confirm their access and time, run it safely, and attach what they actually did. Leave the other rows unproved until someone performs them.