A software project usually ends with a last meeting, a last invoice and a message that says “everything is on the server”. For a while that is enough. The system works, the developer is reachable, and nobody needs anything more.
Then, months or years later, something has to change. The developer has moved on, or is busy, or the relationship has ended badly. And the business discovers what it actually received: a working system it cannot change, cannot move and sometimes cannot even log into.
A handover is the moment a system stops depending on the person who built it. It is cheap to do properly at the end of a project and expensive to reconstruct later. I know the second part well, because a lot of the software that reaches me arrives without one.
This article is the list I would want every client to have: what you should receive when a project is handed over, why each item matters, and how to check you got it without being technical yourself.
A language school has a booking and invoicing system built a few years ago. It works. Then the rules for one course type change and the invoices need a small fix. The developer who built it has taken a full-time job and replies two weeks later: the code is “somewhere on an old laptop”, the server account is in their name, and the password for the e-mail service is in a message they cannot find. The fix itself is an afternoon’s work. Getting to the point where anyone can safely make it takes far longer.
Why handovers go wrong
Nobody plans a bad handover. It happens because at the end of a project everyone is tired, the system works, and the remaining items look like paperwork. The developer knows where everything is, so writing it down feels unnecessary. The business owner does not know what to ask for, so they do not ask.
The result is knowledge that lives in one person’s head and accounts that live in one person’s name. Both are fine until that person is unavailable.
The answer is not trusting or distrusting a particular developer. It is a list, agreed early and checked at the end. Here is mine, in the order I would check it.
1. Every account in the business’s name
Start with the accounts, because everything else depends on them. A typical business system relies on:
- the domain name, at the registrar where it is registered
- DNS, if it is managed somewhere else
- the hosting or cloud account where the system runs
- the code repository
- the e-mail sending service that delivers confirmations and password resets
- payment, accounting, SMS or map services connected to the system
- the Apple and Google developer accounts, if there is a mobile app
- analytics and search console accounts
For each one you should know whose name it is in, who can log in, and where the bills and the warning e-mails go. The ideal is simple: the account belongs to the business, the developer has their own login with the access they need, and that login can be removed on the day the work ends.
The domain deserves special attention. A domain registered in a supplier’s account, with renewal reminders going to their inbox, can lapse without anyone in the business being told. When it lapses, the website and the e-mail on that domain stop together.
2. All the code, and the right version of it
You should receive the source code in a repository the business controls, not as a zip file. A repository keeps the history: who changed what and when. That matters the first time someone asks why the system behaves the way it does.
More important than having the code is knowing it is the right code. Systems drift. A quick fix made directly on the server, a file uploaded by hand, a version that was released and never saved back: each one means the repository and the running system no longer match. Ask the developer to confirm in writing that what is in the repository is exactly what is running, and which version is live.
Also ask for what the system needs that is not in the code: design files, the originals of images and icons, fonts with their licences, and any notes or scripts used to set up the server.
3. A way to build and release it without the original developer
Code is only useful if someone else can turn it into the running system. The handover should include written steps for:
- setting the project up on a new computer
- building it
- releasing a change to the live system
- undoing a change if it goes wrong
If releases are automated, the documentation should say what starts them and where to see whether one worked. If they are done by hand, the steps should be precise enough that a competent developer who has never seen the project can follow them.
The common trap is the build that only works on one machine. The developer’s laptop has a particular version of a tool installed, or a setting nobody remembers changing. Nobody finds out until that laptop is gone.
4. Mobile apps: the developer accounts and the signing keys
Mobile apps add their own items, and they are the ones most often missing.
The app should be published from developer accounts that belong to the business. If it was published from the developer’s own account, it can be moved, but both platforms need the current owner to start the move. Apple’s documentation says the transfer is started by the Account Holder of the account the app is in and accepted by the Account Holder of the receiving one (Apple: overview of app transfer). Google Play works the same way: the original account owner submits the request and the receiving account approves it (Google Play Console Help). If the original developer cannot be reached, that first step becomes very hard.
Apple’s page also notes that code and build assets are not transferred by Apple: the previous owner has to provide them directly. Moving the listing does not move the means to update it.
On Android, the key that signs the app matters more every year. Google’s developer verification ties a verified developer identity to each app’s package name and signing key. It started on 30 September 2026 for users in Brazil, Indonesia, Singapore and Thailand, and Google says it will extend to all apps on certified Android devices in 2027 (Android developer verification). If you cannot say which key signs your app and who holds it, find out now, while the person who knows is still easy to reach.
5. A list of secrets, and then new secrets
A system runs on secrets: database passwords, keys for connected services, the keys that protect logins and payments. The handover should include a list of every one, what it is for and where it is kept. Not the values pasted into an e-mail, but a list, with the values passed on through a password manager or another safe channel.
Then, once the handover is complete, the secrets the previous developer could see should be changed. This is not an accusation. It is the same reason you change the locks when a tenant moves out, however good a tenant they were.
Changing a secret can break things if it is done carelessly, which is one more reason to have the list: it tells you everything that has to be updated at the same time.
6. Your data, in a form you can read
The data is usually the most valuable part of the system: years of customer records, bookings, invoices and files people uploaded. The handover should tell you where all of it lives (the database, the uploaded files, any outside service that holds part of it) and how to get a complete copy.
Ask for an export you can open yourself, not only a database backup that needs the system to read it. A plain export of the main records into spreadsheet files is enough to show that the data exists, is complete and is yours.
The law has moved the same way for rented cloud services. The EU Data Act has applied since 12 September 2025 (European Commission: Data Act). Among other things, it requires providers of cloud platforms and software services to let customers export their data in a commonly used, machine-readable format, and the Commission says charges for switching provider, including charges for moving data out, are removed entirely from 12 January 2027 (Data Act explained). That helps when your system runs on a rented service. It does nothing for a custom system whose only copy of the data sits on a server in someone else’s account, which is why the handover still has to cover it.
Finally, the backups: where they are, how often they run, and when one was last restored to check that it works.
7. Everything that runs on its own
Some of the most important behaviour in a system appears on no screen. A nightly job that sends appointment reminders. A monthly run that creates invoices. An import from the accounting software every morning. A certificate that renews itself, until the day it does not.
The handover should list every scheduled job and every connection to another system: what it does, when it runs, and what happens if it fails.
Add a list of everything that expires or renews: the domain, certificates, paid services, developer memberships, licences. Each one with its date and the account it is charged to. Expiry dates are the most predictable failures there are, and still among the most common.
8. Documentation that answers real questions
Documentation does not need to be long. It needs to answer the questions the next person will actually have:
- What does the system do, in plain words, and who uses which part?
- What are its main pieces, and how do they talk to each other?
- How do I run it on my computer, and how do I release a change?
- Which rules are not obvious from the screens, such as how a cancellation is handled or why a certain field cannot be changed?
- Who do I contact about each connected service?
Twenty pages that answer those questions are worth more than two hundred that describe every file. A good test is to give the documentation to someone who has never seen the system and ask what they still do not understand.
9. The list of known problems
Every system has things that do not work quite right, workarounds people use without noticing, and parts the developer would build differently with more time. A good handover writes these down: known bugs, fragile areas, outdated parts that need updating, and anything that was postponed.
Clients are sometimes surprised to receive this list, as if it were an admission. It is the opposite. A developer who hands you a list of known weaknesses is telling you the truth about your system. One who hands you nothing has simply left the next person to find them, usually at a worse moment.
How to check a handover without being technical
You do not need to read code to check most of this:
- Log in to every account on the list yourself, with your own login.
- At your registrar, check who the domain is registered to and when it expires.
- Open the data export and check that last month’s records are in it.
- Ask the developer to remove their own access to one account, and see whether anything stops working.
For the technical items, the best test is a second developer. Ask someone who has never seen the project to set it up from the documentation, build it and release a harmless change to a test copy. If they manage without calling the original developer, the handover worked. A short paid check like this costs little next to finding the gaps on the day something is urgent.
Agree it before the project starts
The best time to ask for a handover is before any work begins. Put the list in the agreement: the accounts are in the business’s name from day one, the code lives in the business’s repository, documentation and a data export are part of delivery, and the final payment follows the handover rather than the last feature.
None of this is hostile. A developer who already works this way will agree in a minute. One who resists is telling you something useful early, while it is still cheap to act on.
What I hand over at the end of a project
I build software for business owners who have to keep it running long after I have finished, so I treat the handover as part of the work, not a favour at the end.
The accounts are in the client’s name from the start, with my access added to them rather than the other way round. The code lives in the client’s repository from the first day. The documentation and the list of known issues are written while the project is fresh, not pieced together later.
The aim is simple: if I were unavailable tomorrow, another competent developer could pick up the system and carry on. A client who could leave at any time and chooses to stay is the only kind of client relationship I want.
The handover checklist
Before you sign off a project, you should have:
- every account (domain, DNS, hosting, repository, e-mail sending, connected services, developer accounts) in the business’s name, with your own login
- the full code in a repository you control, confirmed to match what is running
- written steps to set up, build, release and undo a change
- for apps: the developer accounts and the signing keys, and who holds them
- a list of every secret and where it is kept, and a date to change them
- a complete data export you can open, and a backup that has been restored
- a list of scheduled jobs, connections and everything that expires or renews
- short documentation that answers real questions
- an honest list of known problems
If any line is missing, ask for it now. It will never be easier than today.
Could someone else take over your system tomorrow?
Discuss your projectTell me what you have, and I will tell you what is missing.