What a Proper Software Agency Handover Should Include

The agency sends a repository link and a folder of design files. The invoice is settled. A month later, a deployment fails—and the only person who knows how to fix it is no longer on the project.

A software handover is complete when the receiving team can operate and change the product. Possessing the source code is necessary, but not sufficient.

The simplest acceptance test is practical: can someone outside the original delivery team deploy a known version, diagnose a failure, and restore the data using the handover materials?

Ownership is a list of accounts, not one repository

Create an inventory of the services the product depends on. It commonly includes source control, domain registration, DNS, hosting, databases, object storage, email, payments, analytics, error monitoring, and app-store accounts where relevant.

For each, record the organization that owns it, authorized administrators, billing contact, recovery process, and subscription terms. Distinguish administrative access from contractual ownership. An agency may be a collaborator while the client owns the account; a shared password does not establish either point reliably.

Agree IP rights, third-party licenses, and transfer obligations in the contract with suitable legal advice. The engineering handover should identify what is being transferred and what remains licensed or supplied by someone else.

Make the build reproducible

The receiving team needs the runtime versions, dependency lockfiles, installation steps, build commands, test commands, and release process. Document required environment-variable names and where values are securely managed—never put live secrets in the README.

Identify the production release by a commit or immutable artifact reference. Include database migration instructions and explain which migrations can be rolled back safely. Restoring an old application version after an incompatible schema change may not work.

Ask a receiving engineer to run the setup from a clean environment. Each undocumented assumption they encounter is unfinished handover work.

Show the system at the level needed to operate it

A useful architecture document explains the main components, data stores, integrations, queues, scheduled jobs, and trust boundaries. It should answer where a request goes, which service owns a record, and what happens when a dependency is unavailable.

Avoid a beautiful diagram that omits the manually configured webhook or the scheduled reconciliation job. Operationally small components often have large consequences when they stop working.

Include important design decisions and known limitations. Explain why an unusual approach was selected and what evidence would justify changing it. New engineers should not have to reverse-engineer the business constraint from the code.

Transfer access without preserving accidental access

Inventory service accounts, deploy keys, OAuth applications, webhooks, CI secrets, and personal access tokens. Move ownership where possible, replace personal credentials, and rotate relevant secrets through a planned sequence.

GitHub's repository-transfer documentation notes that webhooks, secrets, and deploy keys can remain associated after a transfer. Moving the repository therefore does not automatically remove the former team's operational access or update every integration.

Verify the new credentials before revoking old ones, unless an active security incident requires a different sequence. Keep temporary overlap bounded and recorded. Confirm that the product still builds, deploys, sends expected events, and accesses its dependencies afterward.

Prove recovery instead of listing backups

Document where backups live, who can restore them, how long they are retained, and the expected recovery objectives. Then perform a restore in an appropriate isolated environment.

Check the restored data, application compatibility, and required encryption keys. A backup that depends on an inaccessible account or missing key is not a usable recovery plan.

Provide short runbooks for likely incidents: failed deployment, database outage, webhook backlog, expired credential, and unexpected traffic. Each should identify symptoms, safe checks, escalation, and recovery steps. Separate diagnostic commands from actions that change or delete data.

Include the work that is not finished

Hand over the issue backlog, known defects, security findings, deferred decisions, dependency risks, and maintenance tasks. Describe severity and ownership without disguising unfinished work as future enhancement.

The NIST Secure Software Development Framework provides a useful reference for release protection and vulnerability-response practices. A handover should preserve the evidence and responsibilities needed to continue those practices, not just the compiled application.

For AI features, also include prompt and model configuration versions, evaluation cases, source-data permissions, provider settings, usage limits, and fallback behavior. A model switch can change the product even when the application code stays the same.

Agree a clear acceptance checklist

The handover meeting should verify outcomes:

• the client controls the agreed accounts and recovery paths;
• a receiving engineer can build and deploy the identified release;
• monitoring alerts reach the right people;
• the team has completed a restore rehearsal;
• credentials and third-party access have been reviewed;
• documentation and known issues are accessible;
• ongoing support, response expectations, and exclusions are written down.

A short period of supported operation can reveal gaps that a presentation misses. Agree its duration and scope instead of assuming the agency will remain indefinitely available.

How Trifaar can help

Trifaar's SaaS engineering service can help prepare a product for transfer or assess an incoming codebase. That includes reproducible builds, deployment documentation, access inventories, architecture notes, and recovery rehearsals within an agreed scope.

If the product needs continued specialist support, Trifaar's credit model offers a way to discuss that capacity separately from ownership and handover obligations.

Ask Trifaar for a handover-readiness review. The goal is not a thicker document. It is a product your team can confidently operate without depending on one person's memory.