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.
Top comments (1)
Day one is the right framing. For smaller clients we'd add a second named admin on the client side at the registrar and host, not just the repo, plus a one-page note of where everything lives and when it renews.