What should you receive when software is handed over?
A practical handover for a small business tool or connected workflow: ownership, records, pause and retry behavior, recovery, upkeep and an exit plan.
A useful handover lets the responsible person operate the tool, recognise a failure and get help without reconstructing the project from messages. Ask them to follow the instructions while the builder is still available.
Know which part holds the real record
A small tool may depend on several accounts: hosting, a database, a form, a calendar and an email service. Record what each one does, who controls it and which records it owns. A screen that displays a booking is not necessarily the place where that booking is maintained.
| Record | What to write down | Acceptance evidence |
|---|---|---|
| Purpose and owner | What it does, the business owner and the person maintaining it. | The responsible person can find the account through their authorised access route. |
| Data and connections | Which records live here, what moves elsewhere and which version is authoritative. | A fictional record can be followed through the agreed route. |
| Running costs and limits | Recurring services, renewals, capacity limits and the owner of alerts. | The owner can find current plan details and knows what happens at a limit. |
| Maintenance and exit | What needs updating, who supports it, what exports and what depends on a licence. | Source or agreed deliverables, a readable export and current operating instructions are accessible. |
Keep secrets in the chosen credential system, not in this table. Record how authorised access is granted and removed. Agree separately what source, designs and other deliverables transfer; do not infer ownership from an admin login.
Write down pause, correction and retry
The normal route is only part of the handover. For each automated action, record these decisions:
- Trigger: what starts it, and what must already be true?
- Effect: what record changes, or what message leaves the system?
- Stop: how does the responsible person pause new work without losing pending items?
- Exception: where does a failed or uncertain result appear, and who investigates?
- Retry: how do you know repeating the action will not create a second booking, message or charge?
- Correction: which record is changed first, and how do connected copies catch up?
“Ask the person who built it” is a contact, not a procedure.
For a private office, include cover when the usual coordinator is away. For an owner-run business, include the route a trusted replacement would use. Give that person the access required for their task, not every account by default. OWASP's authorization guidance recommends checking permissions and applying least privilege; have the builder demonstrate the agreed roles.
A request arrives while the calendar is unavailable
Illustrative example: an independent consultant has an intake tool that sends appointment requests to an existing calendar. In a separate test setup, the calendar connection is made unavailable. Use fictional details and prevent real notifications or bookings during the exercise.
- Submit one labelled request. Record its identifier and the state shown to the requester.
- Confirm that the tool does not describe an unconfirmed appointment as booked.
- Ask the maintenance owner to find the pending item using the handover notes.
- Restore the test connection and follow the documented recovery path.
- Check that the same request produces the intended single result, with a visible record of what happened.
- Record an unresolved ambiguity as an open issue. Do not keep pressing Retry to discover what it does.
This is an acceptance exercise to agree with the builder, not an instruction to interrupt a live service. If a provider has no safe test mode, choose another controlled demonstration and document what remains untested.
Ask someone to use the backup
A backup file is useful only with an understood recovery path. Identify what is included, what may be missing, who can restore it and where a restore can be tested without overwriting current work. The Canadian Centre for Cyber Security recommends testing recovery and recording roles and procedures.
Ask the maintenance owner to recover fictional records in a separate environment. Compare the result with the expected records and note the recovery point. Keep later real activity out of any rollback exercise.
Also test leaving. Open an export, identify the fields and attachments, and explain what will not transfer. Record cancellation steps, retained records and removal of temporary access according to the business's agreed requirements. A professional practice should approve its own handling rules.
Leave with a handover you can use
Tick only after recording the result and any open issue. This page does not save or send these ticks; keep the evidence with your project files.
Mark the items you have checked.