Software Handover Checklist: 25 Items to Receive Before You Pay

Before you make the final payment to a developer or agency, get 25 things: the accounts, repositories, infrastructure, secrets, documentation, tests, data and licences that let someone else run the product without them. Check each one yourself, ideally by having a new developer rebuild and deploy from what you received. Hold back the last payment until every item on the list below is ticked.

This checklist is for the moment of acceptance: a contract is ending and you are about to sign off. If you still need to ask for the code and move the repository, start with how to get your source code back from a developer, which covers the request and the transfers. If the developer has stopped answering, use the 48-hour recovery plan instead. The payment points below are general information, not legal advice; confirm with your adviser.

Why should the handover come before the final payment?

Because the final payment is the only leverage you have left, and a handover is hard to complete once nobody is being paid to finish it. Before that point, a missing environment variable list is a ten-minute job for the developer. After it, the same gap can cost a new team days of guesswork.

A handover is complete when someone who has never seen the project can rebuild it, deploy it, restore its data and change it safely. Everything on the list serves one of those four goals. "The code is on GitHub" meets none of them on its own.

What is on the 25-item software handover checklist?

Twenty-five items across eight areas. The last column is the check you or a new developer can run, so each tick is based on evidence rather than a promise.

#	Area	Item to receive	How to verify it
1	Accounts	Domain registrar and DNS in the company's name	Log in as the company; the registrant contact is yours
2	Accounts	Hosting and cloud accounts with the company as owner	Your login shows the Owner role, not Member
3	Accounts	Every third-party service on a company account: payments, email, SMS, storage, maps, analytics, error tracking	Invoices and API keys come from accounts you control
4	Accounts	An admin login to the application itself for your team	Sign in and perform one admin action
5	Accounts	A list of every person, machine and API key with access	Compare with each platform's members and keys page
6	Repositories	The repository in your organisation, with every branch and tag	A mirror clone; branch count matches the developer's list
7	Repositories	The exact commit running in production	The SHA from the hosting dashboard exists in your copy
8	Repositories	An explanation of every open branch and pull request	Each is marked "merge", "abandon" or "unfinished, notes attached"
9	Infrastructure	Infrastructure and server configuration in the repository: Dockerfiles, infrastructure-as-code, web server config, scheduled jobs	Nothing needed for deploy lives only on a server or laptop
10	Infrastructure	The CI/CD pipeline running from your account	Trigger a run yourself and watch it finish
11	Infrastructure	A clean build using the host's exact commands	Fresh checkout, lockfile install, build, all without help
12	Secrets	An inventory of environment variables per environment: name, purpose, where it is set	The app starts with only the variables on the list
13	Secrets	Rotation of every secret the developer knew	New keys issued by you; old keys revoked
14	Secrets	A scan of the full history for committed secrets	A secret scanner reports nothing, or each finding is rotated
15	Documentation	A README for setup and running locally	A new developer follows it without asking a question
16	Documentation	A deploy and rollback runbook	Someone other than the author deploys and rolls back once
17	Documentation	An architecture overview: services, data flow, integrations, scheduled jobs	Every external service in item 3 appears on it
18	Documentation	A known-issues and technical-debt list, in the developer's words	It exists and is specific; "none" is a warning sign
19	Tests	A test suite that passes from a clean checkout	Run it; record the count and the time it takes
20	Tests	Tests running in CI on every change	Open a pull request and see the checks run
21	Tests	Test accounts and seed data scripts, with no real customer data	A fresh database can be seeded with one command
22	Data	Database schema and migrations that rebuild from empty	Replay all migrations on an empty database
23	Data	A production backup that has been restored, plus written confirmation that the developer's copies are deleted	Restore it into a scratch database and count rows in key tables
24	Licences	A dependency and licence inventory for open-source packages	Export a software bill of materials and review the licences
25	Licences	A signed IP assignment, and paid assets licensed to the company: themes, fonts, plugins, stock images, paid SDKs	Licence keys and receipts are in the company's name

Print it, share it with the developer a week before the end date, and agree which items are already done. Most of the list is quick for the person who built the system and slow for anyone else.

How do you verify a handover if you are not technical?

Ask a developer who has never seen the project to run the checks, and treat anything they cannot do alone as missing. A few hours of an independent developer's time is small compared with discovering a gap after the relationship has ended. The core checks are short:

# Items 6 and 7: a full copy, and proof production runs code you hold
git clone --mirror https://github.com/your-org/your-app.git
git -C your-app.git cat-file -t <sha-from-hosting-dashboard>   # prints "commit"

# Item 11: a clean build with the lockfile, as CI and most hosts do it
git clone https://github.com/your-org/your-app.git fresh && cd fresh
npm ci && npm run build

# Item 14: scan every commit for secrets
gitleaks git -v .

# Item 23: prove the backup restores
pg_dump -Fc "$PROD_DATABASE_URL" > handover.dump
pg_restore --no-owner -d "$SCRATCH_DATABASE_URL" handover.dump

Why these tools: npm ci fails if the lockfile and package.json disagree, and never rewrites either, so it tests the install you will really get (npm ci documentation). Gitleaks scans the full Git history, not just the current files, which matters because a key deleted last year is still readable in old commits. PostgreSQL's pg_dump makes a consistent backup while the database is in use, and its custom format restores selectively with pg_restore (PostgreSQL pg_dump documentation). Use the equivalents if your stack is different; the principle is the same.

For item 24, GitHub can export a software bill of materials (SBOM) in the SPDX format from the dependency graph, listing each dependency's version and licence (GitHub: exporting an SBOM). You are looking for licences whose conditions your business model cannot meet, and any package with no licence at all.

Which handover items do founders most often miss?

The ones that live outside the repository. The code is usually the easiest thing to hand over; this list is based on engineering experience with takeovers, not on a survey.

• Third-party accounts under a personal email. The transactional email service or the error tracker was signed up with the developer's own address, so password resets go to them.
• Scheduled jobs on a server. A nightly cron job that sends invoices or cleans up data exists only in a server's crontab, not in the repository, and disappears with the next server rebuild.
• Secrets the developer still knows. Transferring an account does not change the keys inside it. OWASP's guidance for an exposed secret is to revoke it, rotate it, remove it from code history and logs, and record who had access (OWASP Secrets Management Cheat Sheet). Treat every secret a departing person held as exposed.
• Paid assets licensed to the developer. A premium theme, a font or a commercial SDK bought on the developer's licence may not transfer with the code.
• Production data on laptops. Copies taken for debugging are easy to forget. Ask for written confirmation that they are deleted.
• The known-issues list. The developer knows which parts are fragile. Once they leave, that knowledge goes with them unless it is written down.

How should you tie the final payment to the handover?

Split the list into what must be done before the final payment and what can follow within an agreed window, and write both into the sign-off. This is general information, not legal advice; confirm the approach, and your contract's terms, with your adviser.

Before the final payment	Can follow within an agreed period
Items 1 to 7: ownership of every account and a verified copy of the code	Item 17: a fuller architecture overview
Items 11 and 12: a clean build and the environment variable inventory	Item 18: the technical-debt list, refined after questions
Items 22, 23 and 25: data you can rebuild and restore, and a signed IP assignment	A second handover call once the new team has worked in the code
Item 13: secrets rotated, done by you once access has moved	Answers to questions for a short, paid support window

Paying for a few hours of handover support after the end date is often cheaper than arguing about what the original price included. A developer paid to answer questions for two weeks will answer them.

What if the developer will not hand over some items?

Separate what you need to operate from what is merely convenient, and secure the first group before anything else. Account ownership, the repository and the data are essential; a polished architecture diagram is not.

1. Put the missing items in writing, as a numbered list with a date, referring to your contract's handover clause if it has one.
2. Offer to pay for the time if the handover work was never scoped. It removes the most common objection.
3. Recover what you can directly. Registrars, hosts and payment providers have account recovery routes for the legal owner of the business.
4. Reconstruct the rest. An environment variable list can be rebuilt from the code; a runbook can be written by the next team. It costs time, not the product.
5. Get advice on ownership disputes. If the IP assignment is missing or contested, speak to a lawyer before paying anyone to build on the code.

Why RAITHub for this, and when you don't need us

RAITHub's Code Rescue engagement often starts the day after a handover: the code has arrived and nobody on your side knows it yet. The first step is this checklist, run as an access inventory, then a 2-week diagnostic of the codebase and infrastructure with a risk register, so you know what you received before you decide what to change. RAITHub's own handovers follow the same list: the repository sits in your organisation from the first commit, tests run in CI, runbooks are delivered at handover and IP in all work is assigned to you.

You don't need RAITHub if:

• Every item on the list is ticked and a developer you trust has already built and deployed from it.
• Ownership of the code is in dispute. That is a job for a lawyer first; RAITHub gives no legal advice.
• You only need one problem fixed in the code you received. Start from the fix one issue page instead.
• You need a certified vendor or delivery in a language other than English. RAITHub is not SOC 2 or ISO 27001 certified and works in English.

If you have received a handover and want it checked, pick Code Rescue on the contact form and book the free 15-minute technical audit. Bring this checklist, ticked as far as you can.

Tool documentation checked on 29 September 2026.

Frequently asked questions

What should a software handover include?

Ownership of every account, the repository with full history, infrastructure configuration, an environment variable inventory, rotated secrets, setup and deploy documentation, a passing test suite, migrations and a restorable backup, a licence inventory and a signed IP assignment. The 25-item table above lists each one with a check.

Should I pay the developer before the handover is complete?

It is common to hold back the final payment until the essential items are verified: account ownership, a verified copy of the code, a clean build, data you can restore and a signed IP assignment. This is general information; confirm with your adviser.

How do I check a handover if I am not technical?

Ask an independent developer to rebuild, deploy and restore the product using only what you received. Anything they cannot do alone is missing from the handover.

Do I need to change passwords and API keys after a handover?

Yes. Treat every secret the departing developer knew as exposed: issue new keys from your own accounts, revoke the old ones and check the code history for keys that were committed.

What is a software bill of materials and why do I need one?

An SBOM lists every dependency in your product with its version and licence. At handover it shows whether any open-source licence imposes conditions your business cannot meet.

How long should a software handover take?

For a small product built by one developer, the checklist usually fits into a few working days if both sides start a week before the end date. A handover call with the next developer is the part most worth paying for.