What a maintainable handoff should include

What a handoff is for

A handoff transfers the ability to look after something, not just the files. GOV.UK lists a smoother transition of knowledge and capability once a contract or programme ends among the benefits of having a clear purchasing strategy. For a small business the same idea applies when a freelancer, supplier or colleague finishes work. The test is simple: could someone else cope if the builder disappeared tomorrow?

Accounts, ownership and costs

Make sure the business, not the builder, owns the important accounts, such as the domain, hosting, email service and any code repository. List each service, who holds the login, which email receives its notices, what it costs and when it renews. Share access through the service's own invitation features, and never send passwords in plain messages.

Where things live and how to get them back

Write a short map of the parts: where the website runs, where the data is stored, where backups go and how long they are kept. The GOV.UK Service Manual advice on choosing technology recommends making and maintaining a map of components and always keeping full control of any data you store. A map does not need to be fancy. A one-page list with a simple drawing is enough, provided it is kept current.

Also record how to restore from a backup and who has done it before. An untested backup is a hope rather than a plan.

A small restore checklist

The UK National Cyber Security Centre advises backing up anything you would be inconvenienced to lose, keeping the copy in a separate location, disconnecting removable backup media when it is not in use, and checking that a backup contains your important data. Its page is written for individuals and families, so treat it as a starting point for a small project, not a full recovery plan. Before handover, agree this list with the new owner:

• List what must be recoverable: content, customer records, settings and files
• Note where the backup is kept, who can open it, and that it is separate from the live system
• Agree how much recent work you could accept losing and how long a restore may take, as planning targets, not guarantees
• Name the owner and a date for the next check
• Restore into an isolated test copy using made-up sample records, not real personal data
• Check that the sample records and key actions, such as a form submission, work
• Write down what was and was not tested, and any limits

Record decisions and their reasons

An architectural decision record, in the ADR approach, captures a single decision and its rationale, and helps later readers understand the reasons, trade-offs and consequences. A collection of them forms a decision log. For a small project this can be a list of a few lines each: what was chosen, what else was considered, why, and what would make you revisit it. It saves a successor from undoing a good decision because the reason was lost.

The handoff checklist

Use a list like this and tick items off with the person receiving the work.

• Accounts and who owns each, with renewal dates and costs
• Where the site, app or automation runs and where its data lives
• How to update content or settings, with one worked example
• How to deploy a change and how to undo it
• Backups: what, where, how often and how to restore
• Known problems and unfinished work, in plain words
• Short decision log with reasons
• Who to ask for what, and the named owner after handover
• Test records or steps to check that everything still works

A hypothetical example

Imagine a florist whose online ordering form was built by a freelancer. At handover the freelancer provides a one page document: the domain is registered in the florist's name, the form sends to a shared mailbox, orders are also saved in a spreadsheet that is exported weekly, and a note explains that delivery days were limited to Tuesday to Saturday because the van is unavailable on Monday. The florist's assistant is named as owner and tries the update steps once while the freelancer watches. This example is hypothetical.

Practise the handover

Ask the person receiving the work to perform two or three real tasks using only the documents: change a price, restore a copy, reset a user. Whatever they could not do from the notes is what to add. Then revisit the document when something changes, so it stays true.