When nobody knows how to maintain your software: take stock first

Context

Your software still does its job. It handles work your business relies on, and nothing else quite covers it. Then you need to change something: perhaps a connection to another system. The original developer has left, and nobody can tell you where to start or what else the change might affect.

Even a routine request can stall like this. To decide what to do, you need information that is scattered, incomplete or held in somebody's memory. You can start recovering that knowledge without having committed to replacing the software.

This is a representative scenario, drawn from our experience of taking on existing systems. It brings together problems we encounter in manufacturing and service businesses; it is not an account of a single client project.

The challenge

1. The documentation doesn't cover maintenance. The problem crops up in a discussion on r/ItalyInformatica, where written communication is described as 'inadequate, poorly written, or missing altogether' (13 June 2024; translated from Italian). In this scenario, you might have a perfectly good user manual, yet nothing explaining how the code works or why it was written that way.

2. The people who know the system are about to leave. An account of legacy migrations on synsphere.it (13 May 2026) describes knowledge often concentrated in one or two people, nearly always changing roles or approaching retirement. If every exception needs their attention, a handover will have to capture the rules that have never been written down.

3. Nobody has tried rebuilding it. A working system tells you little about whether you could rebuild it elsewhere. You might have a copy of the source code without the tools to compile it, or a backup that has never been restored. Until someone tries, you cannot know what is recoverable or how much work it will take.

4. There's no dependable way to check a change. Without tests of current behaviour, checks rely on people remembering what to try. A fix can have consequences that only become apparent during everyday use. Requests stall, while staff work around the system by hand. The time they spend doing so rarely gets recorded.

The numbers worth looking at

You can start answering these questions yourself. Use the records you already have and note where evidence is missing. Those gaps help define what the inventory needs to cover.

• How many people can keep this system running? Count those who could deal with a fault.
• How many requests over the past year needed the original supplier or the person who knows the system?
• How many days does it take to understand a proposed change before anyone can estimate or carry out the work?
• How many critical functions have no named contact? Check whether you know whom to involve in investigating a fault and checking the fix.
• Do you have access to the complete source code in a repository your business controls? A copy of the server alone does not answer that question.
• Can someone other than the current maintainer rebuild it on a new machine using written instructions?
• When was the last restore test, did it succeed, and how long did it take?

The approach

1. Start with the inventory. We begin with the code and the access available to us. We record the environments, external dependencies and licences. We also examine the database, the systems that read from it and the scheduled tasks: an overnight process can be essential without ever appearing in the manual. For each item, we record where it is and who controls it. Gaps stay visible in the inventory, alongside the checks needed to fill them.

2. Build the documentation with the people doing the work. We read the code and ask people to show us how they handle everyday work, including exceptions. An odd-looking rule may serve a purpose that still matters. We ask you to involve the people who understand it and agree how much of their time we need. We write instructions someone can follow, then try them with a person who did not write them.

3. Write tests before changing the code. We start with the operations your business depends on. Tests capture what the software does today, including unusual behaviour, so we can compare it with what happens after a change. Recording a behaviour in a test does not make it correct: if it captures a bug, we agree how the software should behave before fixing it. We also record which functions still lack tests and will need manual checks.

4. Compare the options, including leaving it as it is. Only then do we weigh up maintaining the system, rebuilding part of it or replacing it with a standard product. For each option, we set out the costs we can estimate and the unresolved obstacles. Keeping it as it is for another two years is a valid conclusion. If that is our recommendation, we put it in writing, along with the maintenance still needed and the circumstances that would warrant a review. Keeping the system takes work too, and that belongs in the comparison.

What changes

You have a documented basis for decisions. You know where to find the code and which access is still missing. If a restore has been tested, you have a recorded outcome and a measured recovery time. If it failed, you know what prevented it.

When someone requests a change, you can ask for an estimate based on the parts involved, with uncertainties made clear. You can plan a handover knowing which knowledge still needs to be recovered.

You can also address the question: is it still worth keeping? You have evidence to compare maintenance with replacement, including the work either would create for your own staff.

What people fear, and what we say

'The inventory will turn this into a bigger, more expensive job.' It can. An unsupported component or a forgotten external service may need further investigation and additional work. We agree the scope of the assessment at the start. If something needs investigation beyond that scope, we explain what is missing and what the extra work involves before proceeding. If a problem needs fixing, that work comes at a cost on top of the assessment. We help you distinguish what can wait from what must be addressed before the next change.

'If it won't compile, the assessment will have been money wasted.' A rebuild can fail, and the time spent attempting it still has a cost. That is why we try it early, in an environment separate from the live system. If a missing component cannot be recovered, we document the obstacle and explain what remains possible: observing the system's behaviour, testing data recovery or assessing a replacement. Those activities have their own costs, to be agreed before continuing. The assessment may end without making the software maintainable.

'This just replaces dependence on the old supplier with dependence on you.' That can happen if the knowledge stays with us. A useful handover takes time to prepare and check with whoever takes over. We include that work in the scope and cost we agree with you. We agree in writing which access and materials will remain under your control, taking account of existing rights to the code. We hand over the documentation, tests and available procedures, with unresolved issues recorded. We check that the incoming maintainer can use the instructions to carry out the agreed tasks. You should be able to move maintenance elsewhere without starting the investigation again.

How we approach it today

When we take on software written by others, we start with the information available and the work it needs to keep doing. The first conversation helps establish what you already have and define a clear scope for the inventory. Decisions about changes come afterwards.

• Custom software, handover and maintenance
• Our Odoo Partner path, when switching to a standard product makes sense
• Document management in an integrated ERP

Have software nobody dares touch any more? Let's talk — 30 minutes, no strings attached.