If you are reading this, someone who knew your software well has probably gone, and you may not be sure what you have. That is a common position, and it is fixable. The order matters, so start with what could be lost, and leave improvements for later.
First things to secure this week
Work through this list with whoever manages your IT, and write down what you find as you go.
- Code. Find where the source code lives. A shared repository account you control (for example on GitHub, Azure DevOps or Bitbucket) is the best case. Code on one person's laptop is the worst. Make a full copy now and put it somewhere your organisation controls.
- Hosting. Identify where the system runs: a cloud account, a hosting company or a server in an office. Make sure your organisation, not the developer, is the account owner, and that at least two named people can sign in.
- Domain names. Check who is registered as the owner of your domain names, and who has the login. Domains registered in a developer's own name are a frequent problem, and renewals go to their email address.
- Passwords and accounts. List every account the system depends on: hosting, email sending, payment providers, third-party services, code signing and app store accounts. Make sure each is owned by your organisation, give named people their own access where the service allows it, and keep any credential that genuinely must be shared in a company-controlled password manager. Then remove the developer's access and change any password they knew. Do this in an orderly way, so you don't lock yourself out of something the system needs.
- Licences. Note any paid components, libraries or tools, who bought them, and when they renew.
- Backups. Find out what is backed up, where it goes and who can reach it. Ask whether anyone has ever tried a restore. A backup nobody has tested is a hope.
If you do only two things this week, make a copy of the code and make sure the hosting and domain accounts belong to your organisation.
Who owns the code and data
Ownership of the code depends on your agreement with the person or company who built it, so look for the contract or statement of work. In general, software written by an employee as part of their job belongs to the employer. Software written by a freelancer or an agency may stay with the author unless the contract assigns it to you in writing. If the paperwork is missing or unclear, take legal advice rather than assume.
Your data is a separate question. Customer and staff information in the system is yours to look after under UK GDPR, wherever it is held, so you need to know where it is and who can get at it. The ICO publishes guidance if you are unsure of your responsibilities.
What to ask the developer before they go
If the developer is still reachable, even only for a few hours, a short conversation is worth more than weeks of detective work later. Ask for:
- Where the code is, and a copy of it.
- A list of everything the system connects to, with the account owners.
- How a change is built and released to the live system.
- What runs on a schedule (overnight jobs, report emails, data imports).
- What breaks most often, and anything they have been meaning to fix.
- Which parts are fragile, undocumented or known to depend on one person.
Our article on the developer handover checklist has a fuller list to work from. If the developer has already gone and can't be reached, the first week guide covers what to do without them.
How Eastpoint takes the system on
We take over systems that other people built, and we expect gaps in the documentation and the tests. Our software care service has three stages.
- A software health audit. A fixed-price, one-week review of one system, giving you a plain-English report with the risks ranked. Read about the software health audit.
- Onboarding. Your code goes into your own source control, we add automated tests, set up a repeatable build and release and monitoring, and write the documentation that is missing.
- Monthly care. We monitor the system, apply security updates, keep it in support and report in plain English.
A named senior engineer is accountable for your system, with a named backup engineer who also knows it. Your code and documentation stay in your own repository, so you are never locked in.
Next step
Start with the list above, and keep it somewhere safe. If you would like an independent view of where the system stands, book a software health audit or talk to an engineer. You don't need to have everything in hand first. If some of it is missing, finding out what is missing is part of the audit.