The developer who knew the system has left
When the one person who understood your software leaves, the system keeps running but nobody can safely change it. We help you secure what you need straight away and then take the system on.
A common position to be in
A great many business systems were built and looked after by one person: an employee who wrote it years ago and has maintained it since, or a freelancer the business has used for a decade. It works well for a long time. Then that person retires, takes another job or becomes unavailable, and the business discovers how much was never written down.
Nothing breaks on the day they leave. The risk is in what follows. Each small change the business needs goes unmade, and the first real fault has nobody to fix it.
What usually turns out to be missing
When we take on a system in this position, the same gaps appear:
- The code on the server is newer than the code in the repository, or there is no repository.
- Deployment was done by hand, from memory, from the developer’s own computer.
- A scheduled job that the business relies on ran under their personal account.
- Passwords are in their head, their browser or a file on their laptop.
- Backups exist but have never been restored.
None of these is a criticism of the developer. They are what happens when one capable person carries a system alone.
Your options
Recruit a replacement. You regain someone in-house, though recruiting takes months and the new person faces an undocumented system. You are also back to depending on one individual.
Use a contractor. Quicker, and useful for a specific fix. A contractor has little reason to invest in documentation, and leaves when the contract ends.
Hand the system to a team. A maintenance arrangement puts several people and written documentation behind the system. It costs less than a salary for most systems, because you pay for the attention the system needs.
What we would do first
We start by making sure you hold everything: code, access, backups. Then we prove that the system can be built from its source, restored from a backup and changed safely. If the developer is still around, we sit down with them and ask the questions that matter while there is time.
From there the system is a known quantity, and you can decide at leisure whether to maintain it as it is or improve it. Our takeover process describes each step.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss a software handover 0800 433 7990What to secure first
- The source code
- The current code, in a repository your organisation controls, and confirmation that it matches what is running in production.
- Every login
- Servers, databases, hosting, domains, cloud accounts and third-party services, with administrator access held by the business.
- Backups
- Where they are, who can restore them, and when a restore was last tried.
- How a change is released
- The steps from a code change to the live system, including anything done by hand.
- What runs in the background
- Scheduled jobs, imports, exports and emails, including any that run from the developer's own machine.
- Licences and subscriptions
- Anything registered in the developer's name or paid for on their card.
What we do
Take stock
We find out what you hold, what is missing and what is most at risk.
Capture knowledge while you can
If the developer is still available, we run a structured handover with them and record the answers.
Prove the basics
We build the system from source, restore a backup and release one small change.
Write down what was in their head
How the system is built, deployed and operated, in a form the next person can follow.
Look after it
The system moves onto a maintenance arrangement, with a team behind it.
A good fit when
- A sole in-house developer has resigned or retired.
- A freelancer who built the system is no longer available.
- The developer is still there but has given notice, and you want to prepare.
- You have realised the business depends on one person and want to fix that before it becomes urgent.
Probably not for you if
- The developer left years ago and nobody holds the code or any access; start with our page on systems with no documentation.
Questions we are asked
The developer leaves in two weeks. What should we do now?
Ask them for administrator access to everything, the location of the source code and backups, and a walk-through of how they release a change. Record the walk-through. Then get someone technical to check that the code can be built. We can run that handover for you.
They have already gone and we cannot contact them. Is it too late?
No. If you have access to the server the system runs on, a good deal can be recovered from it: the running code, the database, the scheduled jobs and the configuration. It takes longer than a cooperative handover but it is usually possible.
The system is working fine. Why act now?
Because the first problem will arrive at a bad time: a certificate expiring, a server update, a change in a system it connects to. Establishing that the system can be built, released and restored takes far less effort when nothing is on fire.
Should we hire a replacement developer?
You can, but it recreates the same dependence on one person. Whoever takes over, insist that the knowledge is written down and that the business holds the access.
What will it cost?
An initial assessment is a small fixed-price piece of work. Ongoing support is a monthly fee quoted once we know the size and condition of the system.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.