A software product handover checklist that proves readiness

Define the receiving owner and acceptance evidence

Start by naming the organisation and people who will operate the product after handover. Record who can approve releases, manage production access, respond to incidents, change billing, review security findings and decide whether a risky change should stop. Describe the product journeys that must remain available, the environments in scope and any services that are intentionally excluded. A handover without a named receiving owner can transfer files while leaving every important decision unresolved.

Turn completion into observable evidence. Require an asset register, access register, architecture map, environment inventory, deployment procedure, recovery procedure, known-risk list and maintenance backlog. Record whether each item was supplied, inspected and exercised by the receiving team. Contracts may separately determine ownership, licences, warranties and continuing obligations. This checklist records operational facts and missing controls, but it does not decide legal ownership or replace advice from qualified professionals in the relevant jurisdictions.

Move code and provider control into accountable organisations

Place source repositories under the organisation that is expected to retain the product, subject to the applicable agreement. Preserve commit history, branches, tags, releases, issues, pull requests, packages, submodules, large-file storage and automation definitions. Review repository roles instead of granting every participant administrator access. Confirm that at least two authorised organisation owners can recover access and that no critical build depends on a personal fork, unreviewed deploy key or account that the receiving organisation cannot administer.

Inventory the registrar, DNS, cloud, database, authentication, storage, email, analytics, payment, mobile-store, CI, monitoring, support and billing accounts used by the product. For each provider, record the organisation owner, billing owner, recovery contact, MFA method, environments, data handled and current administrators. Invite named users through provider roles rather than sharing passwords. Confirm that the receiving organisation controls recovery channels before removing the previous team, because an apparent transfer can fail later if password reset or billing authority still points elsewhere.

Prove that build and deployment are reproducible

Ask a maintainer who did not prepare the handover to clone the repository onto a clean workstation and follow the documented setup. Pin runtime and toolchain versions, preserve dependency lockfiles and list any required native SDKs, signing tools or external command-line utilities. Document local checks, test commands, build commands and the path from an approved commit to each deployable artifact. Use safe sample data or fixtures, never copied production secrets, so the exercise can be repeated without exposing customer or operational data.

Document every environment variable and secret by name, purpose, environment, storage location, owning team and rotation procedure without placing secret values in the handover document. Verify CI identities, deploy keys, webhooks, signing certificates, API tokens and machine accounts. After the receiving team has working access, rotate credentials that were available to people leaving the engagement and remove obsolete access. Run one controlled non-production deployment and rollback from the documented procedure so acceptance rests on execution rather than screenshots.

Transfer data, monitoring and recovery responsibilities

Map the product data from collection to deletion. Identify primary databases, object storage, queues, search indexes, analytics destinations, exports and third-party processors. Document schemas, migrations, retention controls, deletion paths and any manual reconciliation task. Record backup frequency and ownership, but do not treat a successful backup job as recovery evidence. Restore representative data into a controlled environment, verify integrity and note the time, dependencies and permissions required to make the restore usable.

List dashboards, logs, external probes, alert routes, incident channels and provider status pages. Every urgent alert needs a receiving owner and an actionable response. Provide runbooks for the failures most likely to affect a critical user journey, including unavailable dependencies, exhausted quotas, failed jobs, rejected store releases and partial data processing. Exercise one incident simulation with the receiving team, including diagnosis, communication, mitigation, rollback and follow-up, then add every unclear step to the open-risk register.

Run the takeover and close access deliberately

Use a practical takeover session as the final review. The receiving maintainer should explain the architecture, make a small change, run tests, produce an artifact, deploy outside production, inspect telemetry, roll back and perform a recovery step. The departing team may answer questions, but it should not secretly operate the process. Record where the receiver needed undocumented help. Those gaps become explicit handover tasks rather than informal promises that disappear when access is removed.

Close with accepted items, unresolved risks, owners and review dates. Separate handover work from any later warranty, support or maintenance arrangement and have contractual questions reviewed separately. Remove obsolete access only after replacement access and recovery paths are verified. IVRYN publicly describes itself as an independent product studio in Paris that designs, engineers and operates its own products and a few for others. That context supports an operational perspective, but it does not prove that any specific engagement is transferred until its own evidence passes this checklist.

Decision criteria

Use the same questions for every option before choosing.