1. A period in which the old team will be available
It’s critical that the new team has someone from the old team available for Q&A for a certain period of time. Usually, 2-4 weeks are enough, but for enterprise projects, it can be up to a couple of months. Not everyone from the old team should be included in that period, however, a tech lead and a project manager must.
A smart thing to do is to define the availability of the old team during the day throughout that period, the time to respond, the communication channel, and the main goals. That way, both sides will know what to expect.
The old team should be compensated for the work they put into this period to keep them motivated in the last days of their project engagement.
2. Code transfer
This one is usually fairly simple. Most dev teams use some code control system (like Github, Bitbucket, Gitlab…) so the only thing the old team needs to do is to invite the new team to the project repositories that they manage. Double-check that the old team did not miss some scripts, mini-projects, code generators, dockerfiles, etc. that might not be included in shared repositories.
3. Documentation
It’s critical that any kind of documentation is handed to the new team. It can save a lot of ping-ponging over some trivial things which would be irritating to both sides. Sometimes, there’s no documentation. If that’s the case, then this transition period can be used to write some. There will be a lot of things said and written during the transition period so making well-organized documentation is absolutely recommended.
4. Access to 3rd party services
It’s likely that the project is dependent on some 3rd party services. It can be Twilio, Jira, Stripe,… Wherever possible, sharing usernames and passwords should be avoided. The new team should receive an invite to the system and then after the transition period is done, the old team should be removed from those.
A useful hack is going through environment variables and dependency lists to find a potential miss in finding all 3rd party services used by the system.
5. Tasks transfer
Most development teams use some task management tool. Bugs and features are usually stored there. So there are two approaches for transferring them to the new team. Either the team gets invited to the task management tool or it receives the export of all tasks.
6. Security
A lot of sensitive data will be transferred, so security awareness must be at the top level. Do not send any security data (API keys and secrets, passwords, etc.) in plain text. There are various tools for securely sending files, and we strongly recommend using some of them.
When the transition period is over, the old team should not have access to any service, data, or code unless agreed on differently.
7. Environment variables
A lot of apps use environment variables stored in files. Use the approach from the previous post and transfer those to the new team.
8. Deployment and CI/CD
Deployment methods vary from project to project. Understanding the setup without documentation might feel like tapping in the dark. All deployment flows should be covered in the handover process and explained in detail. The new team should try a test deployment as soon as they have everything ready to find any potential hiccups in the process.
9. Design Transfer
Projects that include UI or some other designs, design guidebooks, app design files, and other work provided by the previous design team should be shared and explained at a design meeting.
Sometimes, some old designs might be outdated so understanding every bit of it is important for future design implementation.
10. Testing
Most modern development companies are using some way of app testing. It can be automated or manual. All the reports, test flows, coverage, test scripts, and others should be shared and documented.
