What a Python Handover Includes
Last updated:
What you should receive
- The repository, with history, in your account
- Credentials in your accounts, not the supplier's
- A setup guide another developer can follow
- A runbook covering alerts, deployment and rollback
- A decisions record, explaining the non-obvious choices
Test the handover
The practical test is whether a developer who has never seen it can get it running from the documentation in a day. If not, the handover is incomplete regardless of its length.
- Someone else runs it locally from the guide
- Someone else deploys a small change
- You access every account independently
- You restore a backup
The runbook is what matters at 7am
Each alert, what it means and the first three checks. How to deploy and how to roll back. What runs when. Who to contact at each provider.
Written for someone under pressure who has not read it before, which is a different document from a technical overview.
Knowledge transfer
A session with whoever will maintain it, walking through the structure, the important parts and the known rough edges. An hour or two, and worth more than the documentation alone.
If nobody in your business will maintain it, settle who will before handover rather than after.
Name the owner
| Role | Responsibility |
|---|---|
| Business owner | Whether the output is right |
| Technical contact | Making changes |
| Escalation | When it stops |
| Reviewer | Monthly check that it ran |
Unowned services drift and fail quietly. The owner does not need to be technical; they need to care whether it works.
Frequently asked questions
What if the supplier holds the code?
How much documentation is enough?
Do we need our own developer?
What about knowledge only in someone's head?
Not sure you actually own your services?
Three checks: the repository, the credentials, and whether someone else could run it.
Related services
What we build for problems like this one