What should a source-code handover actually define?

A clause saying "the client receives the source code" is close to meaningless on its own. Source code without the database schema is unusable, without deployment configuration it is unrunnable, and without documentation and tests it is unmaintainable by anyone except the team that wrote it. A handover is not a file transfer. It is the set of things another competent team would need in order to keep the system running and change it.

It also has to state its own limits. Any vendor with a real practice reuses components across clients, and those components are usually not yours to own — but the boundary between the client-specific implementation and the vendor's reusable material must be written down before delivery rather than discovered during it. A handover that does not name that boundary has not defined the thing being handed over.

A team received "the full source code" on the day the contract ended: a repository with no history, no environment configuration, no migration scripts and a README written for someone who already knew the system. It took eleven weeks to get it running. Every one of those gaps was a line the contract could have contained.

The code, with its history

Not a snapshot. A repository with commit history, branches and tags. History is how a new team learns why something is the way it is; a squashed single commit deletes that and cannot be recovered.

The database schema and the data

Schema, migrations, seed or reference data, and a restorable export of production data in a documented format. Data you cannot restore is data you do not have.

Configuration and infrastructure definition

Environment variables and what each one does, infrastructure definitions, build and deploy pipelines, DNS and certificate arrangements. Secrets are rotated rather than transferred, and the handover should say so.

Integrations and third-party accounts

Every external service the system depends on, whose account it is under, whose card is on it, and what has to happen for it to be moved to yours.

Documentation aimed at a stranger

How to run it locally, how to deploy it, how the main flows work, and where the non-obvious decisions are. The test of documentation is whether somebody who has never met the authors can use it.

Tests, and what they cover

The test suite and an honest statement of what it does not cover. A new team's first question is "what can I change safely?", and the test suite is the only answer that is not an opinion.

The rights boundary, stated explicitly

Which parts you receive rights to, which parts remain the vendor's reusable material, and which parts are third-party components under their own licences. Three categories, named, before delivery.

The trigger and the acceptance test

What causes the handover — final payment, end of term, termination — and how both sides agree it happened. Best defined as an outcome: a nominated engineer builds, deploys and runs the system from what was delivered.

• Receiving a handover is not the same as being able to operate the system. That depends on your team, and it is worth testing rather than assuming.
• A rights boundary is a contract question. This describes what such a clause needs to cover, not what any particular contract says or what your jurisdiction will enforce.
• Vendors retaining background IP and reusable components is normal and not a warning sign. Not saying so until delivery day is.
• FinMV publishes its own ownership routes and handover scope on the ownership page. The client can receive agreed rights to the client-specific implementation and its source code; FinMV background IP, reusable specifications, generic components, architecture patterns and know-how remain separate unless a specific agreement states otherwise.