A Jordanian company called us eighteen months after their platform launched. The original developer had stopped answering. They had the running website and nothing else — no source code, no server credentials, no idea which hosting account the domain pointed at. Recovering it cost more than the original build.

Software handover is the moment ownership transfers, and it is entirely determined by what you demanded before releasing the final payment.

Source code, in your own repository

Not a zip file emailed at the end. A repository under an account you control, with the full commit history, to which the developer was granted access rather than owning.

Set this up at the start of the project, not the end. If the code has lived in the supplier's repository for a year, the history often comes across incomplete, and history is what lets a future developer understand why something is the way it is.

Every credential, written down

List these explicitly in the contract, because "we handed over access" means different things to different people:

  • Domain registrar login — and the domain registered to your company, not the agency's.
  • DNS management.
  • Hosting or cloud account, with billing in your name.
  • Database credentials and the connection details for every environment.
  • Third-party services: payment gateway, SMS provider, email delivery, maps, analytics.
  • SSL certificate, and how it renews.
  • App store accounts, if there is a mobile application.

The domain is the one that causes the most damage when it goes wrong. Check whose name is on it today, not at handover.

Documentation that answers three questions

Do not ask for "documentation" — you will receive a folder nobody reads. Ask for answers to three specific questions, and test them.

How does a new developer run this locally?

A written procedure. Test it by having someone unconnected to the project follow it on a clean machine. If they cannot get the system running in a day, the document is not finished.

How does a change reach production?

The deployment steps, whatever they are. Even "copy these files and restart the service" is acceptable if it is accurate. Undocumented deployment is how companies become unable to fix their own software.

What breaks, and what do we do?

A short list of known failure modes and their remedies. Every system has three or four. The developer knows them; nobody else does unless they are written down.

Prove the data is yours

Ask for a full export of your data in an open format — CSV, SQL dump, JSON — and actually open it. Confirm it contains everything, not just the tables that were easy to export.

Do this before the final payment. A data export requested after a relationship sours is a negotiation; requested during handover it is a deliverable.

Settle the licence questions in writing

These are frequently ambiguous and expensive to discover late.

  • Who owns custom code written for you? The default in many contracts is the supplier. If you want ownership, it must say so.
  • What third-party components are included, under what licence? Ask for the list. A commercial component licensed to the agency rather than to you stops working when the relationship ends.
  • Can you modify the code without permission? Obvious to you, not always to the contract.
  • Can the supplier reuse it for another client? Sometimes reasonable, sometimes not. Decide deliberately.

The transition period

Handover is not a day. Negotiate a period — typically thirty to sixty days — during which the original developer answers questions from whoever takes over. Price it into the contract at the start; asking for it afterwards costs far more.

The test that settles it

Before releasing the final payment, ask a developer with no involvement in the project to do three things using only what was handed over: run the system locally, make a trivial change, and deploy it.

If they can, the software handover is complete. If they cannot, you have discovered it while you still hold the money — which is the only good time to discover it.