Software Handover: What to Request
When a software project changes hands, you need more than a zip file. Request full ownership of accounts, the source repository, a tested restore process, monitoring access, current documentation, a data export, and a written support scope. Then run a restore drill and a simple acceptance test before you sign off.
Ownership and access
Ask for a written list of every account tied to the project: domain registrar, DNS, hosting, source control, package registries, payment providers, email sending, analytics, and any third-party APIs. For each one, confirm who owns the billing relationship and who can grant or revoke access. The goal is that your organisation holds the owner role, not an individual contractor.
Do not accept shared passwords. Request that each service be transferred to an account your team controls, or that you are added as an owner with the ability to remove others. If a service cannot be transferred, ask for a documented migration path and a date by which it will be replaced. Keep a record of every change so you can prove ownership later.
Source code and build
The source repository should be transferred to your organisation, not left on a personal account. Ask for the full commit history, not a single snapshot. Request the build and deployment instructions, including environment variables, dependency versions, and any private packages. If the project uses a framework or CMS, confirm which version and how updates are applied.
Check that the repository includes configuration for local development, testing, and production. A handover that only provides production access leaves you unable to reproduce bugs or test changes safely. If the previous team used a custom build step, ask for it to be documented and, where possible, simplified.
Data, backup, and restore drill
Request a full export of the application data in a standard format, plus a current database backup. Confirm where backups are stored, how often they run, and how long they are kept. Ask for the restore procedure in writing. Then run a restore drill on a separate environment: take the backup, restore it, and verify that the application starts and that a sample of records matches the source.
An untested backup gives you no evidence that recovery will work. Include a restore drill in the agreed acceptance plan, using an isolated test environment rather than overwriting live data. Record the recovery time and manual steps. Investigate failures before treating the handover as complete.
Monitoring, documentation, and support
Ask for access to monitoring and alerting tools, or for a list of what is monitored and who receives alerts. Confirm the uptime and error tracking setup. Request current documentation: architecture overview, data model, third-party integrations, and known issues. Documentation should be in your repository or a shared workspace you control, not in a personal drive.
Define the support scope in writing. What is covered after handover, for how long, and through which channel? What is explicitly out of scope? If the previous team will provide support, agree on response times and a clear end date. If not, ask for a list of recommended contacts for each service.
Acceptance checklist and pass/fail test
Use a concrete acceptance test. For example, a hypothetical project: you receive the repository, restore the database on a clean server, deploy the application, and log in as an admin. You then create a test user, place a test order, and confirm the order appears in the database and in the admin panel. You also trigger a test alert and confirm it reaches the monitoring channel. If any step fails, the handover is not accepted.
Record the evidence for each handover item: agreed account ownership, repository access and history, build instructions, data export, isolated restore results, monitoring access and support scope. Give each item an owner and a date. If something remains unfinished, document the risk and who will resolve it rather than quietly treating the whole project as accepted.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.