What is a code handover?
Whether you are receiving an app or leaving a supplier, a handover is only as good as its list. Here is the list.
In short
A code handover is the transfer of software from one team to another, including the code and its history, the accounts it runs on, the secrets, the documentation and the knowledge of how it is released. A complete code handover lets the new team ship a change without calling the old one.
Also called: Software handover, Project handoff
What gets lost each time an app's code changes hands?
Most AI-built apps change hands at least once: from the builder to the founder, from a freelancer to an agency, from an agency to an in-house team. Each time, whatever was not written down stays behind with the people who leave: the reasons for odd decisions, the one manual release step, the key only one person knew.
What should a complete code handover include?
A complete handover covers five things: the code with its history, admin access to every account, every secret, the steps to run and release the app, and the known problems. If any one is missing, the new team either has to ask the old one or rebuild it.
- The repository with its full history, owned by your organization's account.
- Admin access to hosting, database, domain, email and payment accounts, in your name.
- Every secret, listed and rotated after the handover.
- How to run it locally, run the tests and release a change.
- Known issues and the reasons behind unusual decisions.
Our plans are built so that the handover is already done: the repositories, infrastructure and documentation are yours from the start, and if you stop, you keep all of it. Details are on our plans and pricing page.
How do you transfer a GitHub repository in a handover?
GitHub has a built-in transfer that moves a repository to another account or organization. Issues, pull requests, the wiki and the full commit history go with it, and links and git commands pointing at the old address redirect to the new one, so nobody loses work.
- Who can do it: an admin of a personal repository, or an organization owner or repository admin.
- The receiving organization must allow you to create repositories, and must not already have one with the same name.
- Webhooks, secrets and deploy keys stay attached after the transfer, so review and replace them rather than assume they are clean.
- Creating a new repository at the old address later breaks the redirects for good.
For a Lovable app, check how the sync is set up. Lovable creates its own repository when you connect a project, and transferring that repository keeps sync running only if your workspace has a GitHub connection for the new owner. Our guide to handing an AI-built app to developers goes further.
Why rotate secrets after a code handover?
Anyone who could read a secret before the handover can still use it after, unless it is changed. OWASP's secrets guidance says to revoke a departing person's access and rotate shared secrets they could read. That covers database keys, payment keys, email provider keys and admin passwords.
- Make an inventory first: what each secret is for, who uses it and how it is rotated, as OWASP recommends.
- For a Supabase secret key: create a new one, replace it everywhere, confirm everything works, then delete the old key.
- Check the code for secrets that were hardcoded, and move them into the environment.
Our secrets management entry explains the wider practice.
Common questions
How do I test that a handover is complete?
Ask the new team to make a small change and release it to production with no help from the old one. Anything they have to ask for was missing. Then check the repository and admin accounts are in your name, and every secret was rotated after the old team left.
Who should own the GitHub repository after a handover?
Your company, through its own GitHub organization. GitHub's transfer feature moves the repository with its issues, pull requests and history, and redirects the old links. Individual developers and suppliers can then be added as collaborators and removed later without the code ever leaving your control.
What documentation should a code handover include?
At minimum: how to run the app locally, how to run the tests, how to release a change and roll it back, where every account and secret lives, and the known issues. Add the reasons behind unusual decisions, which a new team rarely works out alone.
Do I need to change passwords and keys after a handover?
Yes. OWASP's secrets management guidance says to revoke a departing person's access and rotate any shared secrets they could read. Rotate database, payment and email keys, and admin passwords. Do it after the new team has access, and confirm each part of the app still works before deleting old keys.
Go deeper
How to hand over an AI-built app to developersHow to hand over a Lovable or AI-built app to developers: accounts to move, the handover pack, how GitHub sync works, and how to test it is complete.
Related terms
Read next
Sources
- GitHub Docs: Transferring a repository
- OWASP Secrets Management Cheat Sheet
- Lovable documentation: GitHub integration
- Supabase documentation: API keys
Sources checked October 24, 2026
More on this: Product strategy & scoping · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
