The site goes live, the invoice is settled, and it feels finished. But handover is a separate procedure. A site that was never properly handed over looks perfectly fine; the problem appears months later when somebody else has to touch it. If the answer at that point is “nobody knows where the code is”, you are effectively starting again.
There are three bundles to receive: files, accounts and documents. Make a list for each, tick them off, and the whole thing takes half an hour.
Bundle 1 — files
The full backup is the critical one. Files and database must come from the same point in time, and once received you should restore it somewhere at least once. A backup you have never restored is not a backup; treat the restore test as part of handover.
Check the custom code separately. Unless a purchased theme was used entirely as-is, something was written during the build. Ask which files it lives in and whether it is in a repository. Repository ownership works exactly as described in the previous part.
Source assets always become necessary later. When the logo has to go on a business card or a printed sign, a web-sized image is not enough and it has to be redrawn. Ask for the vector originals and editable files.
Bundle 2 — accounts
The point of the account bundle is becoming the owner, not being given passwords. At handover, put every account into your own name and then change all the passwords, since several people are likely to have shared them during the build.
Afterwards, remove or downgrade the supplier’s accounts. If maintenance continues, leave exactly the access that work requires; if it does not, close them. This is housekeeping rather than distrust — an unused administrator account is a risk in its own right.
Bundle 3 — documents
The most commonly skipped bundle, and the one most missed later. It does not have to be thick. Two or three pages that let the next person pick the work up is enough.
Cover this much: which theme and plugins were used and why, what was customised and where, how the server environment is arranged, and anything that has to be done on a schedule. Then the caveats — “updating this plugin breaks that page”. Information of that kind lives only in one person’s head, and if you do not ask at handover it disappears for good.
What we put in a handover
We hold to the same rule on our own jobs: before-and-after measurements, a record of what changed and why, and the operational caveats that follow. The value of upgrade work is not “it is fast today” but “it does not break again next time”, and documentation is what produces the second one.
The order we work in and what we leave behind as records is published on our process page. If you would rather look at your current state first, the diagnostic plugin on the free tools page will tell you where things stand.
Next part
Handover ends and operations begin. The next part is the maintenance agreement — how to write response times and scope so that they actually work.