When someone leaves, make sure their software work can stay
Transfer software ownership, preserve the right data and check recurring jobs when a colleague leaves. Includes a practical four-system handover example.
An Alembic resource · Version 1.1
Software handover checklist: keep the work when someone leaves
Transfer accounts, files, active work and automated jobs when a colleague leaves. Use an editable plan, access checks and a fictional handover example.
Test the next task before calling the handover complete
When a colleague leaves, a list of app names is only the start. The next person needs to use the files, manage the appointments and keep the recurring work running through their own authorized access.
For each dependency, record:
| What to capture | A useful answer |
|---|---|
| Business task | The job that must continue, such as editing the booking register. |
| Receiving owner | A person who has accepted responsibility for it. |
| Transfer needed | The ownership, permission, connection or context that must change. |
| Proof it works | The successor performs a safe example and records the result. |
| Unfinished check | An owner, next action and check date. |
Opening a file does not prove that someone can edit it. A report that ran yesterday may still depend on the departing colleague's account connection. Keep those checks visible.
Agree and record the access cutoff separately. Unfinished handover work needs an authorized owner; it should not silently extend the departing person's access. Keep passwords and recovery codes out of the worksheet.
The complete resource includes a copyable handover plan, an inventory, a fictional coordinator handover and a final review table. It also covers the narrow case where the handover reveals a redundant tool that may need its own cancellation plan.