Software handover checklist

Direct answer

A handover is finished when someone who did not build the software can deploy it, fix a routine problem and restore it from a backup, using only what you were given. Receiving a zip file of code is not a handover. The test is practical: could a competent stranger run this next Monday without phoning the original team?

This page is about the operational side: repositories, environments, runbooks and documentation. Who legally owns what is a separate question, covered in who owns the code and accounts after a custom build. On our own builds, LATYNEX commits to handing over code, domain and accounts in the client's name; the rest of this checklist is how to confirm it actually works.

Code and repositories

Ask for the source in a repository that sits under an account you control, with the full history rather than a single snapshot commit. History explains why things are the way they are.

• The repository lives in an organisation or account in your name, and you hold an owner-level role
• All branches that matter are present, and the branch that is deployed to production is named
• A README states how to install dependencies, run the project locally and run the tests
• Dependencies are pinned in a lock file, and any private packages are accessible to you
• No secrets are committed anywhere in the code or its history; if any were, they have been rotated
• Any code that is not yours (open-source libraries, licensed components) is listed with where it came from

Environments

List every environment the software runs in: production, any staging or test environment, and any local setup. For each one, write down where it runs, what it is for, who can reach it and how it is deployed.

The key check is that you can deploy without the builder. Ask them to watch you do a deployment to a non-production environment from a clean start. If the process depends on a script that only exists on someone's laptop, you have found the gap while it is still cheap to fix. Confirm too that configuration differences between environments are written down, including which settings are environment variables and where each is set.

Credentials and accounts

Make an inventory of every account the software depends on: hosting, domain registrar, DNS, database, email sending, file storage, analytics, error tracking, and any third-party API. For each, record who owns the account, who has admin access and how access is recovered.

• Each account is registered to your business email or a role address you control, not to an individual builder
• Your own admin access is confirmed by logging in, not by being told it exists
• Two-factor authentication is on, and recovery methods belong to you
• Secrets are handed over through a password manager or a secure channel, never by email or chat message
• Builder access is either removed or explicitly kept for a stated reason, and the list is written down
• Credentials that passed through many hands are rotated after handover

Documentation

Good handover documentation is short and specific. Long documents nobody updates are worse than a page that is accurate. Look for four things: an architecture overview (what the parts are and how they talk to each other), a data description (main tables or collections and what they mean), a list of integrations with what each is used for, and a record of the important decisions and the reasons behind them.

Ask what is known to be unfinished or fragile. An honest 'known issues' list is a sign of a careful team, and it saves you from rediscovering each item the hard way.

Runbooks

A runbook is a step-by-step instruction for a routine or urgent task, written so someone unfamiliar can follow it. You want them for the situations that will actually happen.

• How to deploy a change, and how to roll one back
• How to restart the application and what to check afterwards
• How to add, disable or reset a user
• How to renew certificates, domains and any expiring credentials, and when each is due
• Where to look first when something breaks: logs, error tracking, status pages
• Who to contact at each third-party provider, and how

Data and backups

Confirm what is backed up, where the backups are stored, who can reach them, and how long they are kept. Then insist on the step most people skip: a restore test. A backup you have never restored is a hope, not a control. Ask for a restore into a separate environment while the original team is still available to help.

Also settle where uploaded files live, whether the database has scheduled jobs or triggers that are not in the code, and how data can be exported in a usable format if you ever move away.

Walkthrough and sign-off

Schedule a live walkthrough with the person who will operate the software, ideally recorded. Have them perform the runbook tasks while the builders watch and answer questions, rather than watching a demonstration.

Sign-off should reference the checklist: each item marked done, not applicable or deferred with a named owner. Keep the record. Acceptance of features is a different step, described in the user acceptance testing checklist, and it should be completed before the handover, not blended into it. If you want ongoing help afterwards, decide it now, not during an incident; see software maintenance after launch.

Where LATYNEX fits

LATYNEX builds custom web applications remotely, in English, agreeing one scope and one price in writing before work starts. Handover items such as documentation and runbooks are worth listing in that written scope so they are not assumed. If you are planning a build, start at web application development.