Custom software handover: code, access and operations

A technical handover transfers the resources and knowledge needed to run, modify and recover a system within the agreed scope. It goes beyond demonstrating features. Operations confirms that the business process works; IT confirms that the receiving team can maintain it.

When evaluating custom software development, include handover in the initial proposal. Identify who administers the accounts, pays external services and receives the documentation. Leaving this until the end can introduce transfers nobody planned for.

Separate the agreed rights and licenses, your company’s technical access and responsibility for operations. The contract addresses the first; an access inventory and a handover exercise help verify the other two. Repository administration alone does not establish an assignment of intellectual property rights.

Create a row for each resource with its location, receiving owner, required permission, evidence and outstanding dependency. Do not put passwords in the matrix; record where credentials are managed. This is a suggested technical review adapted to your system, not a certification.

Request the repository history, setup instructions, runtime version and the commit or release identifier being delivered. That identifier should map to the deployed application. Include database migrations and relevant tests. An isolated ZIP does not explain which version you received or how to reproduce it.

GitHub repository transfers require permissions and have destination-account conditions. Its documentation explains that collaborators, webhooks and secrets can remain associated after transfer. Receiving the repository and reviewing retained access are therefore separate tasks.

Even if code starts in your company’s organization, check that automation does not rely on the vendor’s personal accounts. Request an inventory of libraries, services and licenses: access to your custom code does not remove the conditions attached to third-party components.

List hosting, databases, domain and DNS, storage, email and external APIs. For each, verify who administers it, pays the bill, receives alerts and can recover access. Shared vendor resources may need to be separated; identify these before agreeing on the handover.

Transfer mechanisms depend on the product. Vercel documents what moves with a project and what needs separate handling. For example, monitoring data is not transferred and Vercel Blob has a separate transfer mechanism. Copying a repository does not replace this review.

Supabase project transfers between organizations have role and integration prerequisites. Transferring a project’s organization also does not change its region. Check current service and plan conditions before scheduling a change window; do not assume all resources move in the same way.

Choose someone from the receiving team and a test environment with data authorized for that use. They should start from the delivered version, follow setup instructions and run the agreed tests. The vendor can observe and clarify; any step requiring an oral explanation becomes part of the documentation.

Then make a small reversible change, deploy it in that environment and return to the previous version. If recovery is in scope, test the agreed restore procedure in isolation. Record the version, result, owner and outstanding items. Do not improvise this exercise in production.

For an internal portal, the receiving team might change a label, run tests, publish the test version and roll it back. If only the vendor can publish because a personal account holds the necessary access, a dependency remains unresolved. This is an illustrative exercise; yours must reflect the actual architecture and restrictions.

Being able to change vendors and needing ongoing support are compatible. Document who monitors incidents, updates dependencies, manages backups and pays renewals. Separate defects in the delivered scope from new features and agree how each type of work is requested.

Ongoing support needs its own scope and conditions. Do not assume on-call coverage, an immediate response or a future migration is included. If your IT team operates the system, its responsibilities must be clear. If the vendor operates it, company access and documentation still matter.

Before removing access, verify that integrations and scheduled jobs use appropriate identities. Plan credential review or rotation with the technical owner to avoid interrupting services that still rely on them.

Describe the system you need, the receiving team, the accounts your company already has and its infrastructure restrictions. Request the relevant handover matrix, documentation and practical exercise in the scope. Where dependencies remain unknown, discovery and its scope are agreed as paid work.

Duotach builds custom software for businesses. You can discuss a custom build and describe the operational outcome and handover requirements. The proposal should specify the commissioned work and support conditions; this guide does not offer a free review of your existing system.