Executive summary
6
things that have to exist for 'you own it' to be true
13
the month the handover is really tested: the first month with no project team in place
Key conclusions
- Ownership on paper and ownership in practice diverge at the first change request after the project team has left.
- A handover has to deliver six things: source code, configuration, credentials, documentation, technical specifications and trained staff. You can check each one before final payment.
- The test is one question: can your own qualified staff change this system without calling us?
Most integration contracts say the client owns the delivered system, and most of them mean it. The problem is that a clause defines ownership but an event tests it. That event is a change that must be made after the project team has moved on. It usually comes a year later, when nobody is checking the contract.
Internally, we set a date for it: month thirteen. A support arrangement usually covers the first twelve months, and the people who built the system are still available. Month thirteen is the first month in which the client's own staff have to open the system and change something. Whether they can do so is the only real test of the handover.
What the clause says, and what has to exist for it to be true
| The contract says | What has to have been handed over |
|---|---|
| You own the source code | The source, in a repository you control, at the version that is running |
| You own the configuration | Every setting that makes this installation this installation, exported and explained |
| You own your credentials | Every account, key and certificate in your name, with the integrator's own access revoked on a date |
| Full documentation is provided | What the system does, how it is deployed, and how it fails, written for the person who was not on the project |
| Technical specifications are provided | Interfaces, data models, protocols and the limits they were tested to |
| Training is provided | Your named staff have made a change to the system with the integrator watching, before sign-off |
Trained staff are the item that makes the other five useful
Five of the six items are artefacts. They can be delivered in a folder and ticked off. The sixth is a capability, and it is what turns the folder into real ownership. Until someone has used the documentation, nobody knows whether it is usable.
In practice, this works as follows. Before final sign-off, a member of the client's own staff makes a real, small change to the live system, such as a threshold, a schedule or an account. They use only the documentation, and the integrator is present but does not help. If the change requires a phone call, the handover is not finished.
A complete handover keeps a system maintainable six years later
The biometric fuel management system at PSA Marine's Brani and West Coast bases has run continuously since 2019. Its second refresh was completed in 2025, after the workload had been migrated to the cloud. A system can be refreshed twice only if the people doing the second refresh can understand what the first one did. The documentation and specifications delivered at the original handover made that possible.
A good handover means that people other than the original builders understand the system and can still maintain it.
Five things to ask for before you sign
- A named list of the handover artefacts, treated as a deliverable with its own acceptance criteria.
- The date the integrator's own access is revoked, and who confirms it.
- The form in which the source and configuration are delivered: a repository you own.
- The change your staff will make without help before final payment.
- What the integrator still holds afterwards, and why. Ideally, this is only a copy of the documentation.
If only the original builders can change a system, the client has in effect bought a subscription with a longer invoice cycle. If that is the intended arrangement, the contract should say so. If it is not, the handover is where the client's ownership has to be proved.
