Before your developer leaves: a handover checklist

Your developer has told you they are retiring, or moving to a new job, or winding down their own business. They have looked after your system for years, it has run quietly, and you have a few weeks to a few months before they go.

That notice period is the most valuable asset you have. Almost everything a successor needs can be handed over in a calm, friendly way while the person who knows the system is still around. Almost all of it becomes slow, uncertain or expensive once they have gone. This article is a checklist for using the time well.

If the developer has already left, our first-week guide is the better place to start.

Ask for an overlap period

Before the checklist, one practical request: try to agree a period of overlap, with the leaving developer and whoever will look after the system next. A few weeks of working side by side is far more useful than a long document handed over on the last day. It also gives you a chance to find the gaps while someone can still fill them.

If the developer is leaving on good terms, a short paid period of availability after they go (an hour or two a month for a few months, for questions) is a modest cost for a lot of reassurance. Agree it in writing, with the terms checked by your own adviser.

The checklist

Work through these with the developer, and ask for each item to be shown, not just described.

1. Source code in your own repository. The code should live in a source control account (GitHub, Azure DevOps or similar) that your organisation owns, with at least two of your people as administrators. If it lives on the developer's laptop or in their personal account, moving it is the first job. Ask for the full history to come across, not just a copy of the latest files.

2. Hosting and cloud accounts in your name. Check who owns the Azure, AWS or other hosting subscription, and whose card pays for it. The subscription, the billing and at least two administrators should belong to the organisation.

3. Domains, DNS and certificates. Find out where the domain name is registered, who controls its DNS records, and when each certificate expires and how it renews. An expired certificate or lapsed domain is one of the most common causes of a sudden outage after a handover.

4. Third-party accounts. List every outside service the system relies on: email sending, payment providers, mapping, SMS, monitoring, licences for components. For each, note whose name the account is in and who receives the invoices and renewal notices.

5. Passwords, keys and secrets in a shared vault. Credentials should be held in a password manager or key vault that your organisation controls, not in someone's memory, a notebook or a spreadsheet. Ask the developer to point out where each secret is used so they can be changed after they leave.

6. How to build and release. Ask how a change gets from the code to the live system. Is it a script, a pipeline or a series of manual steps? Whatever it is, it should be written down and repeatable by someone else.

7. Database and backups. Where does the data live, who can reach it, how often is it backed up, where are the backups kept, and has a restore ever been tried? Until someone has restored one, nobody knows whether the backups work. Then ask the developer to confirm in writing that any copies of your data, exports or backups they hold have been returned or deleted. If they handled personal data for you, UK GDPR expects this at the end of the work.

8. The unusual parts. Every system has them: a scheduled job that must run on the first of the month, a manual step at year end, a file that someone has to upload, a workaround for a known fault. Ask the developer to list these, with an example of each.

9. Who else knows it. Find out whether anyone else, inside or outside your organisation, has ever worked on the system, and what they know. Note any other suppliers that connect to it.

10. Documentation. It does not need to be long. A short description of how the system fits together, where things are and what to do when it breaks is enough to be valuable. Ask the developer to review it with you.

Two sessions that matter more than the documents

A recorded walk-through. Ask the developer to talk through the system on a screen-share, covering the main parts, the awkward parts and the things they would worry about, and record it. People often remember to say things aloud that they would never think to write down. Check with the developer before recording, use a test copy of the system where you can, keep passwords and real customer records off screen, and keep the recording somewhere your organisation controls.

A trial release by someone else. The best test of a handover is to have another person make a small, harmless change and release it, using only the notes and access they have been given, while the developer watches and does not help. Every point where they get stuck is a gap that is now cheap to fix.

Permissions and contracts

Check with your own adviser what your contract with the developer or their company says about ownership of the code, any licences to third-party components, and what happens to access when the agreement ends. This article is not legal advice, and the position varies from one arrangement to another. It is far easier to settle these points amicably while the developer is still engaged.

A sensible first step

This week, do three things:

• Ask the developer for a one-page list of every account, domain and service the system uses, with the owner of each.
• Agree dates for the overlap period, the recorded walk-through and the trial release.
• Check that your organisation owns the source code repository and the hosting subscription, and move them if not.

When Eastpoint looks after a system, the code and documentation stay in the customer's own repository, so you never depend on us holding the only copy. An independent look at the system before the developer goes is what a software health audit is for, and our software care page explains how we look after systems afterwards.