Transitioning Checklist

While we all enjoy a degree of autonomy on our projects, we also need to agree to a certain level of consistency and have empathy for new team members and those that will further develop or maintain our solution.

Understand that the people supporting the solution going forward may be working under pressure to solve an issue for a frustrated customer. Anything you can do to make this easier helps the person working with the solution provide a better customer experience.

Before a project can be handed off to someone else (client or internal), you need to do your best to address the following:

Documentation

Every project should have some level of documentation. It can be light, but it must be possible for the next person to reasonably pick up where you left off.

• README - Are there instructions that make it easy to pick up the project and run it? Are they up to date? Are there any dev environment dependencies that need to be installed?
• Lightweight architecture/decision record - are there any architecture decisions that need to be explained?
• Domain documentation - are there any complex features or business rules documented?

Build & release

There should not be any manual or error-prone build or deployment steps and it should be easy for someone to pick up, make changes, and deploy a new version in an emergency.

• Environments - are there dev/test/prod environments that are correctly named and configured? Are they appropriately isolated from each other?
• Cloud Resources - is resource creation automated and repeatable?
• Continuous Integration - builds code and runs tests and static analysis on commits
• Automated releases - Builds versioned release packages and deploys to each environment reliably without manual steps

Integrations

• Communication - Ensure that outward communication points are clearly understood and protected. For example, ensure that it is not possible to accidentally send an email to a real person from the dev environment by mistake. External
• Integrations - ensure that dev codebase does not connect to production integrations

Testing

There should be a reasonable set of tests, covering core business logic at a minimum, and additional tests included that provide value. Prioritize tests and testing strategies that add the most value for the cost:

• Server side unit tests
• Front-end unit tests
• Integration tests
• UI tests

You should also consider and have a plan for the following:

• Performance & load tests - are you sure the app will perform as expected under normal user load?
• Security tests - would the client running an audit find obvious flaws?

Logging & analytics

In the case that someone needs to investigate an issue, will they be able to do that fairly easily?

You need to have a base level of logging in your application to make it possible at all for someone to troubleshoot. Imagine the frustration of the next person supporting your code in an emergency in production with a customer yelling at them to fix it and they have no tools in place to support them.

Consider the essentials first: exception logging, request tracking... so that someone can see usage and dive into errors, but also consider extending with user events and performance metrics so the customer can see how their users are using the system and make good decisions going forward.

Set up logging early in your project as it can be helpful to surface issues that clients or testers run into but don't report

Security

• Are all secrets/passwords/etc. in a secure location and accessible to the people you are transitioning ownership to? Have you removed access for everyone that no longer needs it?

Cleanup, Known Limitations

• Is there code that is no longer needed that should be removed?
• Are there features that should be disabled going forward?
• Are there known better ways of doing something that you'd like to improve?
• Are all of the items in the backlog still current? Close out anything that can be closed and remove items that are no longer relevant.
• Are there stale branches in source control that should be deleted?

If you're not sure how to do any of these things, reach out to your peers. We're here to help.