There are many ways to get here: the freelance developer retires. The small agency is wound up or sold. The colleague in your own IT team who developed the application on the side changes jobs. Or the vendor simply stops answering.

The software keeps running anyway, often for years. The problem only shows once something has to change: a new law requires an extra detail on the invoice, a server update breaks a function, or a bug appears that nobody can fix.

What to secure straight away

While you are still in touch with the previous developer, now is the best time. Later it gets harder or impossible.

  • The source code. The readable blueprint of the software, as complete as possible and in the version that is actually running. Ask explicitly for the current version, not just any version.
  • The accounts. Server, hosting, database, domain, email delivery, third-party services and app store accounts where relevant. Every account without which the software does not run should be in your name.
  • Passwords and keys. Credentials for interfaces, certificates, licence keys. They are often held only by the developer.
  • Instructions for building and deploying. How does the source code become the running software? Without these instructions the code is a jigsaw without the picture.
  • A backup. A current backup of the database that has actually been restored once.
  • What is in their head. If possible, a thorough conversation: where are the tricky parts? What runs automatically at night? What should never be touched?

Which rights you hold in the software is set out in the contract. What to look out for is covered in Who owns your software? Whether you can demand the source code when the contract says nothing is a question for your lawyer.

When there is no contact any more

Sometimes the developer can no longer be reached and nobody has the source code. Then the situation is harder, but rarely hopeless:

  • Search in-house. Is there a copy on an old PC, on the server or in a backup? The code is often closer than you think.
  • Check the server. With some technologies, the code sits on the server in readable form. With others, only the finished program is there.
  • Rescue the data. Even if the code is lost, the data is usually in a database that can be read out. The data is the most valuable part.

Without source code, the software can no longer be developed further in any sensible way. What remains is to replace it, and recording what it does today starts with the screens, the reports and the people who work with it every day.

The review

Once code and accounts are available, a new developer should look at the software thoroughly before changing anything. A good review answers these questions:

  • Does the software run from the source code you have? Can a version be built from it that works exactly like the running one? That is the first and most important test.
  • How old are the components? Software is made of many components from other providers. Are they still maintained and receiving security updates?
  • What state is the code in? Is it clearly structured, or has it turned into a patchwork over the years?
  • Are there tests? Automated tests show whether a change breaks something else. Without them, every change becomes riskier.
  • Where are the risks? Missing security updates, passwords in the code, unprotected access from outside.

The result should be a clear assessment, not a list of technical terms. Afterwards you should know how the software stands and what needs to happen next.

Develop further or replace?

After the review, two routes remain.

Developing further fits when the code is understandable, the components can be brought up to date and the software still fits the business. A new developer then takes over maintenance, brings security up to date and makes the outstanding changes. What ongoing maintenance involves is covered in Software after launch.

Replacing fits when the code can hardly be saved, the components are outdated or the software has reached its limits for the business. That does not have to happen in one go. The old software can keep running while one area after another moves to a new system. The signs are described in our guide Signs your system is at its end.

Often it is a mix: the software is first stabilised and made secure so it keeps running, and then replaced step by step.

We replace old systems with ElbDesk, the foundation we build on: ElbDesk brings sign-in, permissions, collaboration and documents with it, and only what defines your workflow is developed. What that looks like step by step is shown on our page about replacing old systems.

So it does not happen again

The main lesson is simple: software must not depend on one person. For the new or further developed software that means:

  • The source code sits in an account you can access yourself.
  • All accounts are in your name.
  • There is documentation with which another developer could carry on.
  • More than one person knows the software.
  • All of this is in the contract.

Which questions to ask a new vendor about it is covered in Choosing a software partner.

Checklist for today

  • Do you have the current source code, and where is it?
  • Are the server, domain and all services in your name?
  • Is there a backup that has actually been restored once?
  • Who besides the previous developer knows how the software is built and deployed?
  • Which change is due next, and by when must it be done?