Skip to main content
Orion Five Engineering

10 Jalan Kilang #04-05, Singapore 159410
+65 6100 5505

Book a scoping call
← All insights

Systems integration

Handover is the last deliverable, and the one most contracts leave undefined

'You own the system' is easy to write into a contract. What it means on the thirteenth month — when the integrator has gone and something needs changing — is a short list of specific things that were either handed over or were not.

Terence Kok · 2026-09-02 · 4 min read

A brushed steel key on a red anodised ring lying beside a closed white binder with a steel spine and a thick block of white pages.

Executive summary

6

things that have to exist for 'you own it' to be true

13

the month the handover is actually tested — the first one with nobody on the project team

Core conclusions

  • Ownership on paper and ownership in practice come apart at the first change request after the project team has moved on.
  • Source, configuration, credentials, documentation, technical specifications and trained staff are the six things a handover has to deliver, and each is checkable before final payment.
  • The test is a sentence, not a clause: can your own qualified staff make a change to this system without calling us?

Most integration contracts say the client owns the delivered system. Most of them mean it. The problem is that ownership is defined by a clause and tested by an event, and the event — a change that has to be made after the project team has moved on — arrives a year later, when nobody is checking the contract.

We put a date on it internally: month thirteen. The first twelve months are usually covered by a support arrangement and the people who built the thing are still around. Month thirteen is the first one where the client's own staff have to open the system and do something to it. Whether they can is the only test of the handover that counts.

What the clause says, and what has to exist for it to be true

The contract saysWhat has to have been handed over
You own the source codeThe source, in a repository you control, at the version that is running
You own the configurationEvery setting that makes this installation this installation, exported and explained
You own your credentialsEvery account, key and certificate in your name, with the integrator's own access revoked on a date
Full documentation is providedWhat the system does, how it is deployed, and how it fails — written for the person who was not on the project
Technical specifications are providedInterfaces, data models, protocols and the limits they were tested to
Training is providedYour named staff have made a change to the system with the integrator watching, before sign-off

Why the sixth one is the one that matters

Five of the six are artefacts. They can be delivered in a folder and ticked off. The sixth is a capability, and it is the one that turns the other five from a folder into ownership. Documentation nobody has used is documentation nobody knows how to use.

The practical version is simple: before final sign-off, a member of the client's own staff makes a real, small change to the live system — a threshold, a schedule, an account — using the documentation and nothing else, with the integrator present but silent. If it takes a phone call, the handover is not finished.

What a completed handover looks like six years on

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, on a workload that had by then been migrated to the cloud. A system can only be refreshed twice if the people doing the second refresh can read what the first one did — which is what the documentation and specifications delivered at the original handover were for.

That is the actual value of a handover: not the folder on delivery day, but the fact that the system is still maintainable, by someone, when the people who built it are not the only ones who understand it.

What to ask for before signing

  1. A named list of the handover artefacts, as a deliverable with its own acceptance criteria, not a line in the payment schedule.
  2. The date the integrator's own access is revoked, and who confirms it.
  3. The form the source and configuration are delivered in — a repository you own, not an archive on a drive.
  4. The change your staff will make, unassisted, before final payment.
  5. What the integrator still holds afterwards, and why: ideally nothing but a copy of the documentation.

A system you can only change by calling the people who built it is a subscription with a longer invoice cycle. The contract should say so if that is what is being bought, and the handover should make it untrue if it is not.

Read next


All insights