Knowledge Transfer When a Developer Leaves: The Handover Interview Template

Knowledge transfer when a developer leaves usually fails for a boring reason: nobody asks the right questions before the last day. A handover document gets written, it covers the obvious parts of the system, and then three weeks later something breaks because of a scheduled job nobody knew existed or a manual step the document never mentioned. The fix is not a longer document. It is a structured conversation, run while the developer is still around to answer follow up questions, built from a specific list of prompts instead of a vague request to "write everything down."

This is that list. Use it as a script for the handover interview, adjust the order to fit your situation, and record the conversation if your developer is comfortable with that. A transcript catches detail that notes taken in the moment will miss.

Why a document is not enough for knowledge transfer when a developer leaves

A document only captures what the writer remembers to include, and a developer who has run a system for years tends to leave out exactly the things that feel obvious to them. The quarterly database cleanup script that nobody else has ever opened. The fact that the staging environment uses a different payment provider key and will silently fail if someone copies the wrong one over. The vendor contact who only responds to emails from a specific address.

An interview surfaces these gaps because a good question forces the answer into words, while a document relies on the writer to think of the question first. Run the interview before the document, or alongside it, rather than treating the document as the finished product and the conversation as optional.

Set up the interview properly

Schedule at least ninety minutes, and split it into two sessions if the system is large. Block the time early in the notice period rather than the last week, so there is room to ask follow up questions once you have had a chance to digest the first answers. Bring a second person if you can, someone to take notes while you ask questions, since trying to do both at once means missing details.

Tell your developer directly that the goal is not to test them or catch gaps in their work. It is to get what is in their head onto paper before it leaves with them. People answer more completely when they are not worried the interview is a performance review in disguise.

The questions that surface what is not written down

These are the questions that tend to produce the answers a written handover document misses.

On scheduled jobs and automation: what cron jobs or scheduled tasks are currently running, what does each one do, and what happens if one of them silently stops? Is there a job that nobody checks on anymore because it has just always worked? Which scheduled tasks depend on data that could change shape and break quietly?

On manual fixes and workarounds: what is the thing you do by hand every month, or every time a specific error shows up, that nobody else knows about? Is there a step in deployment or data processing that requires a judgment call rather than following a fixed procedure? What would you tell a replacement to never, ever touch without asking you first, if you were still reachable?

On what is currently broken or held together: what is half fixed right now, or being patched around rather than properly solved? Which part of the system would you be least surprised to see fail in the next six months? Is there a piece of code you are quietly embarrassed by that still works fine, so nobody has ever questioned it?

On history and context: who else, outside the current team, has ever touched this codebase? A former contractor, an agency, a previous employee who left code behind without documentation. Is there a decision in the architecture that looks strange today but made sense for a reason that is no longer true?

The single most useful question to end on: if you got a call about this system a year from now, asking what broke, what would be your first guess? That question tends to name the fragile part of the system faster than anything else on this list, because it asks the departing developer to use their own judgment one last time instead of just listing facts.

Supplier and vendor contacts

A separate section of the interview should cover every outside party the system depends on, because this list rarely lives anywhere written down. Walk through each vendor relationship the developer has: the hosting provider, the domain registrar, the payment processor, the transactional email service, any third party API the product relies on, and any contractor or agency that gets called in occasionally for specific work.

For each one, capture the account login details or confirm who already has access, the support contact or account representative if one exists, any contract terms that matter such as renewal dates or usage limits, and anything unusual about how that vendor needs to be contacted, such as a support channel that only works from a specific registered email address.

This is also where billing surprises tend to hide. Ask directly whether any of these services are on a free tier that will stop working at a certain usage threshold, or a trial that is about to expire. A developer who set something up two years ago may not remember the renewal date offhand, but asking the question while they can still check is far better than finding out when the service goes dark.

The access removal checklist

Once the interview is done, you still need to secure the system, which is a separate task from documenting it. Work through this list and confirm, for each item, that someone other than the departing developer has owner or admin level access, and that any credential tied personally to them has been rotated:

the domain registrar and DNS management console, the hosting account or cloud provider, the production database and any backup or replica service, the CI/CD pipeline and its deployment keys, the payment processor and its API keys, the transactional email service, every third party API the product depends on, the source control host and who has admin rights on the repository, the password manager or credential vault if one exists, and any two factor authentication tied to a personal device or authenticator app.

This checklist and the handover interview answer two different questions. The interview tells you how the system works. The checklist tells you who can still get into it. Both need to be closed out before the last day, not after it. For the full first two weeks sequence that covers both of these alongside everything else that needs to happen, our guide on the first 14 days after your only developer quits walks through the order to do it in.

What to do with the answers

Write up the interview notes within a day while the conversation is still fresh, and organize them by system component rather than by the order the questions were asked. Someone reading this later will be looking for "how does deployment work" or "what does the nightly job do," not trying to reconstruct the interview itself.

Rank anything that came up as broken or fragile by how much damage it would cause if it failed, and keep that list visible for whoever takes over, whether that is a new hire, a fractional developer, or an outside team brought in to cover the gap. If you want a sense of how exposed the business already is before you get to this stage, our guide on bus factor risk has a short set of questions that will tell you.

If the gap between your developer leaving and a permanent replacement starting is longer than a few weeks, you need someone who can work from these notes and keep releases moving in the meantime. Our web application development team has taken over systems they did not build before, working directly from handover notes like these. Reach out to hello@wolf-tech.io, or find more detail at wolf-tech.io, and bring whatever you have from the interview. The first conversation costs nothing.