Cost & Process

Software Vendor Handover: Verify Ownership and Recovery

Prepare a software vendor handover that verifies account ownership, repeatable deployment, data recovery and the documentation your team needs.

Software vendor handover checklist illustration

A folder of source files is only one part of a software handover. The receiving team also needs the rights, accounts, configuration and operating knowledge required to maintain the application. A useful handover proves that someone outside the original development team can deploy, recover and safely change the system.

Start early enough to fix gaps while the outgoing vendor is available. The business should name a receiving owner and identify which responsibilities will remain external. An application can depend on services that cannot simply be transferred, including licensing arrangements, app-store registrations or a provider's shared infrastructure.

Inventory the assets and accounts

List source repositories, domains, hosting accounts, databases, storage, analytics, email delivery and payment integrations. For each, record the legal or business owner, billing owner, administrators and recovery method. Identify recurring charges and renewal dates without placing passwords in the inventory document.

GitHub's repository-transfer documentation describes the mechanics and limits of moving a repository. The broader handover still requires review of connected automation, account access and contractual rights. A successful technical transfer does not by itself establish ownership of every asset or dependency.

Prove a clean deployment

Ask the receiving team to start from a fresh environment using the written instructions. They should install the specified runtime, supply approved environment variables, run checks and deploy to a nonproduction target. A demonstration on the vendor's already-configured laptop leaves hidden dependencies undiscovered.

Record the build command, runtime versions, migration order, scheduled jobs and rollback procedure. Explain which settings are public and which are private. The documentation should identify where secrets are managed without embedding secret values or including a production database in a source archive.

Worked example: a supplier portal transfer

Imagine a portal with a website, background importer and document storage. The outgoing vendor supplies the main repository, but the importer runs from a separate private account. During the handover rehearsal, the new team discovers that the website deploys successfully while supplier documents stop appearing.

The corrected inventory adds the importer repository, its schedule, service account permissions and failure alerts. A controlled test imports an anonymized document, confirms its storage reference and exercises a retry. This reveals a missing operational component before the production relationship changes.

Next, the team restores a backup into an isolated environment and confirms that database records still point to the correct document objects. A database backup without the associated files would be incomplete for this portal.

Replace shared access with accountable access

Create individual administrator accounts and an approved emergency-access route. Remove outgoing vendor permissions only after the new team verifies its own access. Rotate credentials that were shared, and review automation tokens for unnecessary privileges.

OWASP's secrets-management guidance covers secret lifecycle, least privilege and auditing. Apply those principles to the transition: new ownership should include the ability to rotate and revoke credentials, not merely a copy of old passwords.

Record remaining risks and acceptance evidence

Collect open defects, unsupported libraries, known security findings and limitations in the recovery process. Name an owner and next action for each. Avoid signing a vague "everything delivered" statement while unresolved dependencies remain unlisted.

The acceptance package can include a successful clean deployment, a recovery rehearsal, access checks and a current architecture diagram. Keep the evidence proportionate to the application's importance. The final decision should rest on demonstrated operability, with outstanding work explicitly agreed, rather than on the number of documents exchanged.

Primary references

Our IT consulting team can help review a handover package and rehearse the transition.

Let’s connect the dots

What would this look like for your business?

Let's turn the right ideas into a clear next step.

Discuss your project