This is the checklist for our handover process. When a new person joins a project, project members are changed, or project is moved to another team, a
handover should be thoroughly planned and executed.


  • Reduce handover time.
  • Make clear for everyone how handover will affect schedules/communication/budget.
  • Reduce risks of post-handover work.
  • Ensure good confidence for new members.

Handover is not a task, and it is not instant. Handover is always a project. Therefore it should be planned and executed like a project. Depend on the stage of project, the dedicated team should pick approriate checklists.

  • Handover process should only take maximum 2 weeks.
  • Diagrams should be made using draw.io or gliffy.
  • Documents should be written in markdown (.md) format and posted directly to source repo.


Project handover
  • Handover plan created and documented (Resources to join handover process)
  • Time for handover allocated.
  • Project description is in an easily accessible place.
  • Project roadmap and past progress and documented.
  • High level diagrams explained.
  • List of tools and access to them.
  • List of what was delivered.
  • What was agreed with customer.
  • Clear tasks for next week.
  • Development process description. E.g. how new features are implemented, tested, released and supported
  • List of currently involved people and their roles (including contacts). RACI or similar table.
  • List of previously involved people, and whether it is ok to contact them.
  • All communication channels are documented.
  • New members added to corresponding communication channels: email lists, chats, recurring calls.
  • List of all change requests.
  • List of things that are not clear.
  • List of past big problems with customer/partners and how they solved.
  • Explained how hours should be recorded and everyone have access to project in time booking system.
  • Expected problems (scalability, security, etc) are documented.
  • Technology stack is documented in single place.
Source Code handover
  • Detailed diagrams created.
  • New team member has been able to compile, run, test, deploy code to all involved systems.
  • Code walkthrough done.
  • New member has written and deployed code to QA without supervision. It could be a bugfix or small feature.
  • New members know how and where to find information why certain design/implementation decisions are done.
  • Do pair programming for at least 1 hour (an old member with a new member).
  • Code review time is scheduled weekly.
System handover
  • All required access (root, etc) is given to systems.
  • Environments are documented.
  • Software Licenses are documented.
  • Backups tested at least once.
  • All scripts and tools can be found from documentation or version control.
  • Process flow diagrams are created for most common cases.
  • Monitoring is documented.
  • Support and Maintenance plans include clear steps for disasters.
  • List of previous problems exist in searchable format.
Handover completeness

Used to verify if handover was successful. Go through this list after one week of finished handover to check if it was successful. If some points can't be
marked, it means that handover is still in progress. Go through it once again after one more week. Always start
with all boxes unchecked.

  • All new members have had clear tasks for past week.
  • No question asked during last week about people/contacts/roles.
  • List of tool is up to date
  • No old change request appear (that was agreed before handover and never mentioned during the process)
  • No past communication channels were introduced (channels that were used in the past, but not mentioned during handover)
  • All things that were not clear (mentioned earlier) were resolved.
  • All handover time is recorded
  • Every new member is confident with the project. No? Ask Why.

We’d love to work with you.

Drop us a message if you’d like to build with the Dwarves.

Let’s build