A source code handover is the point where a software project changes hands. Done well, it means your team can run, change and hire for the system without depending on the company that built it. Done badly, you receive a folder of files, no access to the live server and no one who knows how to deploy a fix. This checklist shows what to request and verify before you make the final payment.
What a source code handover actually includes
Many business owners assume the handover is the code. The code is only one part. A complete handover gives you the ability to build, deploy, operate and change the system after the vendor leaves. That usually means five groups of items: the code repository, access and credentials, documentation, environments and deployment, and legal rights to use the work.
If any one of these is missing, you may still own the software on paper but be unable to use it in practice. This is why we recommend treating handover as a deliverable with its own acceptance steps, not a casual file transfer at the end of the project.
Checklist before the final payment
- Full version history. The repository should contain the complete Git history, not a single exported snapshot. History lets your developers see why decisions were made and roll back a bad release.
- Repository admin rights in your name. The repository should be owned by your company account, with your team as administrators. The vendor's team should be removed as owner once handover is confirmed.
- Working build from a clean machine. Ask a developer who was not on the project to clone the repository and run the system by following the README. If it fails, the handover is not finished.
- Environment configuration templates. Include example environment files with every variable listed and described, but never real secrets inside the repository.
- Database schema and migrations. Every schema change should be a migration in the repository, so the database can be rebuilt from scratch.
- Third-party accounts transferred. Hosting, domain, email service, payment gateway, SMS provider and error-tracking accounts should be registered to your company, not the agency.
- Test suite that passes. Automated tests should run and pass on the handover branch. If there are no tests, record that gap in writing so you can plan for it.
- Signed acceptance. Confirm the handover in writing, listing the repository, environments and accounts you received.
Access and credentials: who should hold what
Access is where most handovers fail. Passwords are shared over chat, an admin account is left under a former developer's personal email, or a server key only exists on one laptop. Use the table below to track each credential and its owner before the project closes.
| Item | What you should receive | Who should own it |
|---|---|---|
| Source code repository | Full history, admin rights, branch protection rules | Your company account |
| Production server | SSH access for named engineers, deployment process documented | Your company, with named users |
| Domain and DNS | Registrar login and DNS records list | Your company |
| Payment gateway | Merchant account and API keys, rotated after handover | Your company |
| Email and SMS services | Sending domain setup and provider accounts | Your company |
| Backups | Backup schedule, storage location and a tested restore procedure | Your company, with a documented owner |
After handover, rotate all shared secrets, including database passwords, API keys and admin logins. The vendor should no longer be able to reach production unless you explicitly grant access for a support contract. For more on operating access safely, see our guide to securing a web application.
Documentation you should not accept without
Code without documentation is expensive to change. At minimum, ask for the following in writing:
- A README that explains how to install, run and test the system locally.
- An architecture overview showing the main modules, external services and how data flows between them.
- A list of user roles and permissions, and where they are defined in the code.
- Deployment steps, including rollback steps and who approves a release.
- A short list of known issues and technical debt, so your team does not discover them during an outage.
Documentation does not need to be a long manual. A clear set of notes that a new developer can follow in a day is far more useful than a hundred-page document nobody reads.
Warning signs during handover
- The vendor says the repository is "on our side" and will be shared later.
- Production is hosted on the vendor's personal or shared account.
- The build fails on a clean machine and the fix is described as "just ask us".
- Secrets are sent by chat or email in plain text.
- The contract says you own the code, but the license for paid components or frameworks is not mentioned.
Any of these should be resolved before you pay the final milestone. Once the last invoice is settled, the vendor has little reason to rush.
How we run handover at Narmar
We treat handover as a scheduled phase with its own checklist, usually in the final weeks of a project. We transfer the repository and third-party accounts to your company, walk your technical lead through the deployment process, and provide a written record of every access item. If you are planning a larger build, our software services include this handover step by default, and you can review our delivered projects to see the kinds of systems we hand over.
If you already have a system built elsewhere and are unsure what you actually control, contact us and we can review the access list with you before any changes are made. For ERP and operations platforms, see also our ERP system service.
Frequently asked questions
Does owning the source code mean I own everything in the system?
Usually you own the custom code written for your project, but not always the third-party libraries, frameworks or paid components it uses. Those are covered by their own licenses. Ask the vendor to list any restricted components in the handover documents.
What should I do if the vendor has already left the project?
Start by listing every account and server you need, then request transfer in writing. If the vendor cannot respond, check your domain, hosting and repository records to see which accounts you can already access. A specialist can then audit the codebase and recover control.
How long does a source code handover take?
For a typical project, a handover takes a few days to two weeks, depending on how many third-party services and environments are involved. Starting the checklist early in the final phase avoids delays at the end.
Should my own developer review the code before final payment?
Yes, if you have one. A short independent review confirms that the code builds, the tests run and the documentation is accurate. It is far cheaper to fix gaps before the final payment than after the vendor's team has moved on.
