Software Handover Checklist: What You Must Receive From Your Developer Before the Project Ends

A solid software handover checklist is what separates a finished project from one you can actually run. A software project is not done when the last feature works; it is done when you can keep the system running, change it and, if necessary, hand it to someone else without calling the person who built it. That moment is the handover, and it is where many small and mid-sized businesses discover they paid for a product they do not fully control.

This guide covers what you should receive from a developer, freelancer or agency before you close a project, why each item matters, and how to ask for it without turning the conversation into a dispute. It pairs well with our guides on structuring a software development contract and choosing who builds your software.

Why handover problems are so common

Handover is rarely written into the original scope, so it is treated as a favour at the end of the project, when the budget is spent and everyone is ready to move on. The result is usually one of three situations:

• The code lives in the developer’s personal repository, and you hold only a ZIP file that is already out of date.
• Hosting, domains and third-party services were registered under the developer’s own accounts.
• Nothing is written down, so only one person knows how to deploy a change or restore a backup.

None of this requires bad intent. It is simply what happens when delivery is defined as “it works” rather than “you can operate it”. Agreeing on a handover standard at the start costs almost nothing; reconstructing one later can cost weeks.

The software handover checklist

1. Source code and repository access

• The complete repository, with full commit history, in an organisation account that you own (GitHub, GitLab or Bitbucket), not a personal account of the developer.
• All branches and tags, including the one that matches what is running in production.
• A clear licence statement: who owns the custom code, and which open-source components are used and under which licences.

Ask for repository transfer or admin access, not a one-time export. Platforms such as GitHub support this directly; see GitHub’s documentation on transferring a repository. History matters: it explains why decisions were made and makes future debugging far cheaper.

2. Accounts, credentials and environments

• Hosting, cloud, DNS, domain registrar, email-sending and payment accounts registered to your company.
• A list of every third-party service the system depends on (maps, SMS, analytics, AI APIs), with the account owner for each.
• Production, staging and development environments, each with its own credentials stored in a password manager, never in chat messages or the code itself.
• API keys rotated at handover so the developer no longer holds working access to production unless a maintenance agreement says otherwise.

3. Documentation that a stranger could follow

Good documentation is short and practical. You do not need a 200-page manual; you need enough for a competent developer who has never seen the project to be productive within days.

• A README with the architecture in one page: main components, data flow, and where each one runs.
• Step-by-step instructions for setting up the project locally.
• The deployment process, written as a runbook that someone else can execute.
• Environment variables and configuration, listed by name and purpose (not the secret values).
• The database schema and a short description of the key tables and relationships.
• Any scheduled jobs, queues, webhooks and integrations, and what happens when they fail.

4. Data, backups and recovery

• Confirmation of where production data is stored and who can access it.
• Automated backups with a documented retention period.
• A tested restore. A backup that has never been restored is an assumption, not a safeguard.
• A way to export your data in a standard format (CSV, SQL dump) at any time.

5. Quality and test assets

• Automated tests, if any exist, and instructions for running them.
• A list of known issues, shortcuts and technical debt, written honestly. This is a sign of a professional, not a weakness.
• User acceptance test results or a signed acceptance note matching the agreed scope.

6. Design and content assets

• Source design files (Figma or equivalent), fonts, icons and brand assets with their licences.
• Original images, copy and media in their uploaded form, not only compressed web versions.

7. Knowledge transfer and ongoing support

• At least one recorded or live walkthrough covering architecture, deployment and the most likely failure points.
• A defined warranty period for bugs found after launch, and what it covers.
• An optional support or maintenance retainer with response times, so that handover does not mean abandonment.

Quick reference table

How to ask for it (without friction)

The best time to define handover is before the work starts. Add a short delivery clause to the contract listing the items above, and tie the final payment to their completion. If the project is already underway, the same list works as a friendly request: “Before we close, please confirm each of these items so we can operate the system independently.”

Two practical tips:

• Request a mid-project handover rehearsal. Ask a second developer, or a technically minded colleague, to set up the project from your documentation alone. Every question they ask is a gap to fix while the original developer is still engaged.
• Keep ownership of accounts from day one. It is far easier to invite a developer into your accounts than to transfer them out later.

Note that intellectual property rules vary between jurisdictions and contracts. This checklist is a practical guide, not legal advice; have important agreements reviewed by a qualified lawyer.

Frequently asked questions

Who owns the code when a developer builds custom software for me?

It depends on your contract and applicable law. Ownership should be stated explicitly in writing, including whether the transfer happens on delivery or on final payment, and how open-source components are treated. Do not rely on assumptions.

Is a ZIP file of the code enough?

Rarely. A ZIP file loses commit history, is quickly outdated and says nothing about deployment or credentials. A repository in your own account, plus documentation, is the practical minimum.

When should I plan the handover?

At the start. Put the delivery requirements in the scope, review them at the midpoint and verify them before the final payment.

What if my current developer is unresponsive?

Start by inventorying what you can access today: repositories, hosting, domains and backups. Even partial access is enough for an independent developer to audit the system and plan a safe takeover.

Take back control of your software

If you have a system built by someone else and you are not sure what you really own, or you are planning a new project and want delivery done properly from day one, our team can help. We offer handover audits, documentation, takeovers of existing codebases and ongoing maintenance. Contact Shkulaku to request a consultation and discuss your project.