The short answer
Begin handover a fortnight out, require documentation as a deliverable, and prove it works by having one of your own people make a real change to the code with the departing developer watching rather than helping.
Handovers that consist of a document and a meeting fail quietly. You find out three months later when something breaks and nobody can follow the code.
Start earlier than feels necessary
Two weeks is a reasonable minimum for a short engagement and more for anything substantial. Handover is real work and it competes with finishing the last features, which is why it gets squeezed.
Agree at the start that the final weeks are for transition rather than delivery. If that is a surprise at the end, the handover will be a document written in a hurry.
What to require
- A written overview of what they built and why the significant decisions went that way.
- Anything running outside the repository: scheduled jobs, environment variables, third-party accounts, infrastructure they set up.
- Known issues and the things they would have fixed with more time.
- Whatever is in their head about the fragile parts, written down.
- A session where your developer makes a change and they only answer questions.
That last item is the only one that actually tests the handover. Everything above it is preparation for it.
The questions to answer before the last day
| Question | Why it matters |
|---|---|
| What runs on a schedule, and where? | Cron jobs are the classic orphan |
| Which credentials are in their name? | Access disappears with the account |
| What is deployed where, and how? | Deployment knowledge is rarely written |
| What breaks most often? | Saves the next person weeks |
| What did they not get to? | Turns unknown debt into a backlog item |
Access, and closing it properly
Revoke access on the agreed date rather than whenever someone remembers. That includes source control, cloud accounts, third-party services, internal tools and anything with a shared password.
Check for anything registered in their name rather than a company account. Domains, certificates, API keys and service accounts created during a project have a habit of being tied to an individual, and that only surfaces at renewal.
Leaving the door open
Engagements end for reasons that have nothing to do with the work: budget, priorities, a project finishing. A developer who knows your system is worth keeping on good terms with, because a short re-engagement six months later costs far less than onboarding someone new.
Say why it is ending, give proper notice, and pay the final invoice promptly. It is a small industry and the same people come back around.