Software handover checklist: what to collect before changing vendors

A software handover checklist is boring until the week your old vendor loses interest and the new team discovers that nobody has production access.

Most vendor changes fail in the gaps: one CI secret, one undocumented cron job, one staging database with different data than production, one person who knew how releases worked and has already left the Slack channel. The code repository is only part of the handover. The real handover is the context that lets a new team make a safe change without guessing.

This checklist is for founders, CTOs, operations leaders, and product owners who are moving a custom software product from one team to another. Use it before the contract ends, not after.

Software handover checklist for the first 48 hours

Start with the things that keep the product alive. If the outgoing vendor has limited time, do not begin with a beautiful architecture document. Begin with access, backups, deployment, and the list of people who know where the bodies are buried.

Collect these within the first 48 hours:

Source code repositories, including archived repos, deployment scripts, infrastructure code, and private package mirrors
Production, staging, and test environment URLs with owners and access paths
Hosting accounts, cloud projects, DNS providers, registrars, email services, analytics, monitoring, and payment systems
CI/CD configuration, build commands, environment variables, secrets inventory, release branches, and rollback steps
Database access rules, backup locations, restore instructions, retention periods, and recent restore test results
Current incident list, open security issues, blocked releases, and known fragile areas

The point is not to migrate everything immediately. The point is to know whether the new team can keep the system running tomorrow if something breaks tonight.

Codebase handover: more than a GitHub invite

A GitHub invite tells the new team where the code lives. It does not explain how the system behaves in production.

Ask the outgoing team to record a one-hour technical walkthrough. It can be a simple screen share: repository structure, main services, local setup, test strategy, release flow, and the parts they are afraid to touch. Save the recording. Written docs are useful, but a spoken walkthrough often reveals the real shortcuts.

For each repository, capture:

Runtime versions, package managers, build commands, test commands, and lint commands
Required local services, Docker files, seed data, feature flags, and mock integrations
Branching rules, release tags, versioning habits, and hotfix process
Generated code, migrations, scripts, background workers, and scheduled jobs
Modules with low test coverage or changes that often cause regressions
Dependencies that are pinned because an upgrade broke something before

A useful rule: a new developer should be able to clone the repo, run the app locally, run tests, and ship a harmless change without a private call with the old team. If that is impossible, write down exactly what blocks it.

Access and ownership transfer before the contract ends

Access is where handovers get political. The outgoing vendor may have created cloud accounts, Apple or Google developer accounts, DNS zones, API keys, monitoring dashboards, and third party subscriptions under their own company email. That is a business risk, not an admin detail.

Build an ownership table with four columns: system, current owner, target owner, transfer status. Include boring services: transactional email, SMS, maps, tax calculation, error tracking, uptime checks, domain renewals, package registries, and design tools.

Then remove shared accounts. Create named accounts for the incoming team, rotate secrets after access changes, and keep emergency owner access inside the client's organization. If nobody at the client can reset a production credential, the handover is not finished.

Documentation that helps the next team

Do not ask for a 60-page document nobody will maintain. Ask for working notes the new team can use in week one.

The handover pack should include:

System overview: services, databases, queues, integrations, and user-facing apps
Deployment guide: how code reaches production, who approves releases, and how rollback works
Data guide: main entities, source of truth, data exports, privacy constraints, and deletion rules
Integration guide: external APIs, webhook endpoints, rate limits, retry behavior, and failure alerts
Operations guide: common incidents, support inboxes, manual admin tasks, and escalation paths
Product guide: active roadmap, abandoned ideas, user pain points, and promised customer work

One good diagram is enough if it is honest. Show the systems that exist, not the architecture someone wishes existed.

Data handover and compliance checks

Data is easy to treat as a technical export. It is usually more sensitive than that. Before the vendor transition, identify which data the vendor can access, where copies exist, and what must be deleted or retained after the handover.

Check customer data, employee data, logs, analytics exports, backups, screenshots in tickets, support attachments, and test databases. If production data was copied into staging, decide whether it must be scrubbed. If the outgoing vendor keeps backups, agree on deletion evidence and timing.

This is also the moment to check whether the system has a real restore path. A backup that nobody has restored is a wish. Run at least one restore test before the old team disappears.

Release handover: prove the new team can ship

The handover is not complete when files are transferred. It is complete when the new team can ship a small change safely.

Plan a controlled release during the overlap period. Pick something low risk: copy change, logging improvement, feature flag cleanup, or a small admin fix. The incoming team drives the release. The outgoing team watches and answers questions. If the release fails, you learn while both teams are still available.

During that release, verify:

CI runs from a clean branch
Secrets are available through the right vault or environment manager
Migrations are reviewed before production
Monitoring shows the deployment and any errors
Rollback instructions are current
Product, support, and operations know what changed

A vendor transition without a test release is a handover on paper.

A 30-day software handover plan

A realistic handover does not need months, but it does need order. This 30-day plan works for many small and mid-sized custom software products.

Week 1: freeze risky scope changes, collect access, inventory systems, export documentation, and schedule technical walkthroughs.

Week 2: run local setup, review architecture, map integrations, check backups, and list urgent risks.

Week 3: rotate credentials, transfer ownership, clean CI/CD gaps, and run the first incoming-team release in staging.

Week 4: ship a small production change, confirm monitoring, close critical access gaps, and agree on the first 90-day maintenance backlog.

If the old vendor is leaving under tension, shorten the plan but keep the order: access, backups, release path, risks, then improvements.

Red flags during a software project takeover

Some handover problems are inconvenient. Others are warning signs that the product needs a deeper audit before anyone promises new features.

Watch for these red flags:

The outgoing team cannot explain how production is deployed
Production secrets are stored in chat, personal password managers, or local files
The client does not own the cloud account, domain, app store account, or payment account
Tests exist but nobody trusts them before release
The staging environment is months behind production
Backups exist but restore steps are unknown
One developer is the only person who understands a critical module
The backlog mixes bugs, promises, invoices, and scope changes with no owner

If you see several of these at once, treat the transition as due diligence, not simple onboarding. Our software due diligence checklist covers the deeper review before you inherit the risk.

Software handover FAQ

What is a software handover checklist?

A software handover checklist is a list of code, access, documentation, data, deployment, risk, and support items that must move from one software team or vendor to another before ownership changes.

How long should a software handover take?

A small product can often be handed over in two to four weeks if access is clean and the outgoing team cooperates. Complex products with multiple integrations, weak documentation, or vendor conflict may need longer.

What should be included in a software project handover?

Include repositories, environments, credentials, cloud ownership, CI/CD, deployment instructions, database backups, restore steps, architecture notes, integration details, known bugs, support processes, and a first release test.

Who owns the code after a software vendor handover?

The client should own the code, repositories, cloud accounts, domains, data, and deployment pipeline unless the contract states otherwise. Check IP clauses and transfer rights before the old vendor leaves.

What is the biggest risk when changing software vendors?

The biggest risk is hidden operational knowledge: undocumented deployment steps, personal accounts, missing secrets, unknown data flows, and fragile code paths that only the old team understands.

Need help taking over a software product?

Syntanea helps companies audit, stabilize, and take over custom software when a vendor changes or a project gets stuck. If you need a clean handover plan before the next contract starts, talk to us. We will start with access, release safety, data, and the risks that can hurt you fastest.