Software handover: the eleven things you must receive

Handover is where businesses come up short without noticing, because the software keeps running and nothing raises an alarm. The problem appears a year later, when something needs changing and the builder has moved on.

Below are the eleven things that make a handover complete. Copy them into the contract, under the final payment conditions.

Code and infrastructure

1. The complete source code, readable. Not minified, not obfuscated, with the commit history if Git was used. That history matters more than you would think — it tells whoever changes the code later why it was written that way.

2. The list of environment variables, with each one explained. The most commonly missing item. Source code will not run without an API key only the builder knew existed.

3. The database schema and migration files. Not just a dump. Migration files are what let somebody rebuild the data structure from nothing.

4. Deployment documentation. Step by step, from a blank machine to a running site. The test: can a developer who has never seen the project follow it and get it running?

Access

5. The domain, in your name. Verify with whois; do not take somebody's word. If it is in the builder's name, that blocks final payment.

6. Hosting or the VPS, your account. Paid with your card, recovery email yours.

7. Every third-party account. Email delivery, image storage, payment gateway, Google Analytics, Search Console. List each one with who currently holds it.

We go deeper on the four things that must be in your name in the source ownership article.

Operations

8. User documentation. Not technical docs — documentation for staff: how to create an order, change a price, export a report. With screenshots.

9. A recorded training session. Screen recording, 45–90 minutes, saved as a file you keep. A new hire six months later can watch it. The cheapest item on this list and the highest value.

10. A backup and restore procedure that has been tested. Not "there are automatic daily backups" — but: where the backups are, who can download them, and has a restore actually been performed once. A backup never restored is not a backup.

The one nobody asks for

11. The list of things deliberately not built, with reasons.

The highest-value item and almost never delivered.

Every project contains decisions to leave something out: not handling customers with two addresses, not calculating tax on export orders, not supporting simultaneous logins on multiple devices. Those decisions are usually correct at the time.

The problem is a year later, when somebody hits exactly that case, nobody knows it was considered and deliberately skipped. They file a bug, a new developer goes hunting in the code, and three days later discovers it was never a bug.

One page with ten lines of "we did not do X because Y" saves many days of future work.

The test that proves the handover is real

Put this in the contract, under final payment:

The supplier delivers the documentation and source package. The client appoints an independent developer who rebuilds the system on a fresh server using only that package, without asking the supplier. If the system runs, the final instalment is paid.

This clause changes the behaviour of both parties, and it is the only item on this list with enforcement behind it. A decent supplier agrees immediately; one who objects has told you something useful.

If you are about to sign

Put all eleven into the handover section, and hold 15–20% of the contract value until handover is complete. This is ordinary practice and no honest supplier objects.

With our service these eleven are the default, including the eleventh. If you would like to see a sample handover document before deciding, message us on Zalo — we will send one from a past project with the client details removed.