Our contractor who wrote our database system is retiring. How do we make sure someone else can look after it?

What to secure while the contractor is still available

The aim is simple: on the day the contractor stops, nothing the system needs should be in their head, on their laptop or in their name. Go through the list below with them, and ask for evidence rather than reassurance.

The source code, and the right to it. Put the current code in a repository your organisation owns, and check that it matches what is running. Then read the contract. Code written by a contractor belongs to the contractor unless the agreement assigns it to you, so if the contract is silent, agree a written assignment now, while goodwill is high. Our answer on who owns the source code of bespoke software explains the position; take legal advice on the wording.

A build from source, proven. Someone other than the contractor builds the application from the repository on a clean machine. If it fails, the missing pieces, such as a library, a licence file or a tool installed years ago, are found while the contractor can still name them.

Deployment steps, written down and rehearsed. How a change gets from the code to the live system, including database changes, configuration and anything done by hand. Then have someone else follow the notes to release a small change. Instructions that have never been followed by a stranger are usually incomplete.

Credentials and third-party accounts. Servers, the database, hosting, domain names, certificates, email delivery and anything else the system talks to. Each account should be in your organisation’s name, with the contractor as a user who can be removed. Pass credentials through a password manager or another secure channel, never in the handover document.

Licence keys and subscriptions. Components, tools and services registered to the contractor or paid for on their card. Move them to the organisation, or at least record the renewal date and what stops working if it lapses.

Backups, restored once. Find out where the backups go, who can restore them and when a restore was last tried. Then try one, into a separate environment. A backup that has never been restored is a hope, not a plan.

Whatever runs unattended. Scheduled jobs, imports, exports and emails, including any that run from the contractor’s own computer. These are the usual casualties of a retirement; nobody notices until the month-end report fails to arrive.

A handover is a working session, not a document

Ask a retiring contractor for documentation and you will get a document: the system as they remember it, accurate about the parts they think about and silent about the parts they do by habit.

The better method is to sit the contractor beside whoever takes over and do the work together. Build the system, release a change, restore a backup, walk through the scheduled jobs and the configuration. Record the sessions. The questions that come up, such as why a job runs at five in the morning or what a second connection string is for, are the knowledge no document captures, and the notes taken during the sessions become the documentation.

Pay the contractor for this time at their normal rate, and agree the number of days in advance. It is cheap compared with reconstructing the knowledge afterwards.

Arrange a short overlap

The handover goes best when whoever takes over starts before the contractor finishes. A few weeks is usually enough: long enough for the new party to meet a problem the contractor can explain, short enough to afford.

That new party can be an in-house developer, another contractor or a company. Whichever you choose, the test is the same. Before the contractor’s last day, the new party should have built the system from source, released one change to the live system and restored a backup, without the contractor’s hands on the keyboard. Our software takeover checklist lists ten checks with the evidence to ask for at each, and works as the agenda for the overlap.

Two cautions. Replacing one contractor with another recreates the same dependence on one person, so whoever takes over, insist that the knowledge is written down and that the business holds the access. And a retiring contractor is often happy to stay available for the odd question; put the terms in writing, because an offer to ring if you get stuck is not an arrangement you can rely on in two years’ time.

If they have already gone

Retirement is usually announced, but not always. Illness, a move abroad or a falling-out can end an arrangement overnight. The position is recoverable more often than it feels.

Start with what you can reach. If the system runs on a server you control, the running application, the database, the scheduled jobs and the configuration are all on it. Web applications often run from files close to the source, and compiled .NET applications can usually be turned back into readable code. Then search for the source itself: old laptops, backups, email attachments and accounts on code-hosting services. Where it is appropriate, ask the contractor or their family; most are glad to help.

Our page on a developer who has left sets out the first week in that position. If nothing can be found, the system can usually be kept running unchanged while a replacement is planned from the data and from what the system can be seen to do.

Where a company fits

CodeFirst is a UK software company that takes over systems in this position, starting with the working sessions above and then supporting the system with more than one person behind it. If you would rather keep the arrangement in-house, the checklist and the overlap are still the method; the only difference is who sits beside the contractor.