Short answer
Before taking over a software project, verify four things: whether you hold access to all accounts and repositories, whether the application installs and runs in a clean environment, whether backups and monitoring exist, and whether open work is written down. Do not consider the handover finished until these are complete.
Access and ownership
Inventory repositories, domains, servers, databases, email and third-party accounts. Plan authorised account transfer and key rotation rather than relying on a shared password list.
In the access inventory, list not only technical accounts but also the accounts that should belong to your company, such as the domain registrar, DNS, app-store developer accounts, payment provider, email service and monitoring tools. Check whether an account is tied to a personal email address.
Reproducible setup
Run installation, database migrations and the core workflow in a clean environment with sample data. An application working only on its current server has not been reliably handed over.
Try the setup using written steps that someone who does not know the project could follow. Missing steps, hidden environment variables or files that exist only on the developer's computer appear in this trial. Add every gap to the handover list.
Operations and outstanding work
Check backup restoration, deployment, error monitoring and incident ownership. Distinguish known defects from unfinished features. Record licence and dependency terms.
Try restoring from a backup at least once; that backups are taken does not mean they can be restored. Write down who has access to error logs and who is alerted during an outage.
Acceptance meeting
Review missing access, the working release, risks and the initial action plan together. Assign an owner and verification method to each item. A checklist does not replace contractual or scope review.
For every item left open at the acceptance meeting, write an owner, a date and a way to verify it. Decide separately whether a gap is an acceptable risk or a blocker that should delay the handover.
Common gaps
These gaps are common in handovers: secret keys held by a single person, undocumented manual deployment steps, domains or certificates about to expire, unused services still being paid for, environments without test data, and third-party services tied to the developer's personal account. Each of them should be a separate line in the handover list.
A handover acceptance worksheet
Add an owner and date to every row. Accept an item after seeing the evidence, rather than relying on a verbal confirmation. Keep credentials and customer data out of the worksheet.
Frequently asked questions
The questions we hear most often when taking over a software project.
Is a code review needed before taking over?
Yes, even a short one. How readable and testable the code is, and how current its dependencies are, determine the cost of the handover. For a detailed review, see our software and technical consulting service.
What if the previous developer does not cooperate?
First confirm which accesses belong to your company. If the domain, repository and accounts are yours, work can proceed technically; missing information means reverse-engineering the system, which adds time and cost. For the legal side, take advice from a lawyer.
Do we need to shut the system down during the handover?
Usually not. The checks can be done on a separate copy without touching production. If production needs to change, that is planned separately.
Can I use the checklist with my own team?
Yes. Download the CSV at the end of the page and fill it in with your team; do not write keys or customer data into the table.
