Client ownership and capability transfer
The institution should understand what will remain, who can operate it and which rights need to be agreed before work starts.
Define the handover in the scope
Before an engagement, specify the deliverables: operating procedures, decision records, training, system documentation, configurations or software. State acceptance criteria and name an institutional owner. A proposal is not a transfer of ownership.
Separate rights and dependencies
Client data, bespoke deliverables, Roadyom methods and third-party components may have different rights. Record those rights, license conditions, export formats and operating dependencies in the agreement. This page makes no blanket intellectual-property assignment.
Demonstrate the retained capability
At handover, ask the institutional team to perform the agreed task, explain the evidence and handle an exception using the documentation. Record what it can now do independently and where support remains necessary. Training attendance alone is not proof of capability.
Plan continuity and exit
Agree access changes, exports, support responsibilities and retention or deletion at the end of the engagement. Verify the handover against those commitments rather than assuming that deployment means institutional ownership.