The Client Project Handover Checklist: 9 Things to Set Up on Day One

Siddhant Singh — Mon, 26 Oct 2026 13:49:35 +0000

If you build software for clients, sooner or later a project changes hands. The client hires an in-house team, switches agencies, or simply wants to be able to walk away if they need to.

How that handover goes says a lot about the team that built the product. My company has delivered 580+ projects for clients across 18+ countries, many of them in the US and Canada, and one lesson keeps repeating: the best time to prepare for handover is day one, not the last week.

Here's the checklist we recommend, whether you're the agency, the freelancer, or the client checking that you actually own what you paid for.

1. Source code lives in the client's account

The repository should be created in the client's GitHub, GitLab or Bitbucket organization from the start, with the delivery team added as members.

If a repo already lives in your org, transfer it rather than re-uploading, so history, issues and PRs come along:

# GitHub CLI: transfer a repo to the client's organization
gh api repos/OUR-ORG/client-app/transfer \
  -f new_owner=CLIENT-ORG

Then confirm:

Default branch protection rules are set in the client's org
The client has at least one owner-level account that isn't tied to your team
CI/CD secrets are stored in the client's org, not in a personal account

2. Cloud accounts belong to the client

Production should run in a cloud account (AWS, Azure, GCP) that the client owns and pays for. Your team gets access through roles, not root credentials.

A few things to verify:

Billing and root/owner access sit with the client
Team access uses IAM roles or groups that can be revoked in one step
Infrastructure is described in code (Terraform, CloudFormation, Bicep, Pulumi) so another team can understand and reproduce it

# Quick sanity check: who has access in an AWS account?
aws iam list-users --query "Users[].UserName"
aws iam list-roles --query "Roles[].RoleName"

3. Domains, DNS and email are registered to the client

This one causes real pain when it's wrong. Domains registered under an agency or a former employee's personal account can take weeks to recover.

Domain registrar account: owned by the client
DNS: managed in the client's provider account
Transactional email (SendGrid, SES, Postmark): client-owned, with verified sending domains

4. App store accounts are in the client's name

For mobile apps, the Apple Developer and Google Play Console accounts should belong to the client's legal entity. Publishing under a vendor's account and "transferring later" is possible, but slow, and some app data does not transfer cleanly.

Also check:

Signing keys and certificates are stored where the client can access them
Push notification credentials (APNs keys, FCM projects) are in client-owned accounts

5. Secrets are documented and rotatable

Every secret the app depends on should be:

Listed in one place (names and purpose, not the values)
Stored in a proper secrets manager or CI/CD secret store
Rotatable without a developer from the original team

A simple, version-controlled template helps a lot:

# .env.example (committed): names only, never real values
DATABASE_URL=
PAYMENT_GATEWAY_KEY=
PUSH_NOTIFICATION_KEY=
STORAGE_BUCKET=

6. Documentation a new team can actually use

Not a 60-page document nobody reads. Aim for:

README: how to run the project locally in under 30 minutes
Architecture overview: one diagram plus a page explaining the main services and data flow
Deployment guide: how code gets from a merged PR to production
Runbook: what to do when common things break

If a competent developer can't get the app running locally from the README, the handover isn't done.

7. Third-party services are listed with owners

Most products depend on a dozen services: analytics, error tracking, maps, payments, AI APIs. Keep a simple table:

Service	Purpose	Account owner	Billing
Error tracking	Crash and error reports	Client	Client card
Payments	Checkout	Client	Client
AI API	Summarisation features	Client	Client

Anything where "account owner" is a person on the delivery team is a risk to fix now.

8. IP ownership is clear in the contract

This is a legal question, not a technical one, but developers should know the answer. Ideally, IP transfers to the client as work is paid for, not only at the end. If you use open-source libraries (you do), keep their licenses listed so nothing surprising shows up in a due-diligence review later.

9. Do a dry run before you need it

The real test: could someone outside the original team deploy a small change to production using only the documentation and client-owned accounts?

Try it once with a trivial change, like updating a text string. You'll find the missing pieces quickly, while the original team is still around to fix them.

Why this matters for the people building, too

It can feel counterintuitive for a vendor to make leaving easy. In practice, the opposite is true. Clients who know they can leave tend to stay longer, because they trust the team. Clean ownership is a feature, not a risk.

If you've been on the receiving end of a messy handover, what was the one thing you wish had been in place? I'd love to hear it in the comments.

I'm Siddhant, Founder & CEO of Webshark Web Services, an ISO 27001 and CMMI Level 3 certified software development company working with businesses in the US, Canada, the Middle East and India. This post was written with AI and published by the author.

DEV Community: Siddhant Singh