Agency handover checklist: what you must hold before the build team walks away

1 Code

• Get every repository into a GitHub or GitLab organisation your company owns, with its full commit history.

  A zip of the latest files loses the history that explains why the code is the way it is, and a repository in the agency's account can disappear with the agency.

• Make sure each repository has a README that says how to run it locally and how to build a release.

  The knowledge of how to build is the first thing to leave with the old team.

• Have your incoming developer build a release from a clean machine before you sign the handover off.

  A build that only works on the agency's laptop is not handed over; cached bundles and unrecorded settings show up here.

• Ask for a list of forked or copied third-party code and its licences.

  Open-source licences travel with the code, and some require their notice to be kept.

2 Accounts and keys

• Move every account into your company's name: Apple Developer, Google Play Console, cloud hosting, the domain and DNS, email sending, payment gateways, error monitoring, and the maps and AI APIs.

  Whoever owns the account owns the product in practice, and the bills, alerts and store notices go to the account holder.

• For Android, take the upload key and its passwords and confirm the app uses Play App Signing; for iOS, confirm the app record and bundle identifier sit in your own Apple team.

  With Play App Signing, Google holds the app signing key and you sign updates with an upload key, so the upload key must be yours.

  Official source

• Get an environment template (such as .env.example) for each repository, receive the real secrets through a secure channel, and rotate them after handover.

  Secrets belong neither in the repository nor in an email thread, and the old team should not hold working keys afterwards.

• Remove the outgoing team's access to repositories, servers and dashboards once the transition period ends.

  Access nobody removes is access nobody is watching.

3 Running the system

• Get a deploy runbook and a rollback runbook for every service.

  The first bad release after a handover is when you find out whether anyone can undo it.

• Get a list of every scheduled job and what it does, and of every webhook and the service that consumes it.

  Jobs and webhooks run without anyone looking at them, so they are the parts a new developer breaks without knowing.

• Point error monitoring and uptime alerts at your own people.

  Alerts that still go to the old team mean nobody hears about the outage.

• Get a database backup and a full export of stored files, with a manifest of every file's key, size and checksum, and a restore guide.

  Storage keys are often nested by user and can contain literal percent sequences; a restore that flattens or re-encodes them breaks every file link.

4 Knowledge

• Get a written state of every system: what is in production, which versions, where it runs.

  Memory fades within weeks; a dated document does not.

• Get a list of open items, each with an owner: on your side, on the old team's side, or with a third party.

  Unowned items are the ones that turn up later as surprises.

• Get the known defects and any review findings, with the old team's verdict on each.

  A new developer should not spend a month rediscovering problems the old team already knew about.

• Book a walkthrough between the old and new developers, and agree a short period for follow-up questions.

  Some knowledge only comes out when someone asks the right question.

5 Contract and payment

• Check your contract says the code, designs and other work transfer to you on payment, and tie the final payment to a handover that meets this list.

  The final invoice is your strongest lever for getting a complete handover. Take legal advice on the wording.

What did these checks catch in our own builds?

Questions about this checklist