Software Handover: The Complete Checklist

“In the end it all belongs to you”, plenty of people promise that. Whether it is true shows up at the handover. This checklist defines what “all” actually means. Use it twice: as a standard to hold us to, and as a checklist if you build somewhere else.

1. The source code, complete and accessible

• The entire source code sits in a code archive (technical term: repository) that you have full access to, not just the provider.
• The development history is included (who changed what and when), which matters for any team that takes over later.
• The usage rights are settled in writing: the code passes fully to you. Verbal assurances do not count in a dispute.
• Any third-party building blocks (open libraries) are listed with their licences, so you know what is inside.

2. The data, yours, in open formats

• All data can be exported in full, in common formats, without having to ask the provider.
• You know where the data sits (country, provider), which is relevant for data protection and contracts.

3. The access, every single one

• Server or hosting, domain management, database, email delivery, all connected services: for each one you have your own login with full rights.
• Nothing runs through the provider’s accounts. That is the most common hidden catch, check it first (more on that in the ownership check).

4. The documentation, understandable, not just present

• An overview of what the software does and how it is built, written so that an outside development team can get on board.
• An operating manual: how is the software run, updated, backed up? What to do when something breaks?
• For your team: an introduction to using it, ideally as training, not just a PDF.

5. The acid test

Ask the provider this one question: “Could another development team take over your work tomorrow, using only what you are handing me?” A confident yes with a nod to the points above is the right answer. Dodging (“it’s complicated”, “only our system understands that”) means you are buying a dependency, not software. How such dependencies come about, the article on vendor lock-in shows.

Why we publish this list

Because it is our standard: these are exactly the points we hand over on every project, described in detail here. And because an informed customer is the best customer, even if they end up building elsewhere. If you do want to build with us: the price calculator is the first step, two minutes, an honest initial estimate, a fixed price.