- Maintenance
- Delivery
Taking over an application nobody documented
The market's reflex is to propose a rewrite. It is the most profitable assignment to sell and the riskiest to buy. Here is the alternative, and what it actually costs.
· 4 min read · AzerOps
A critical application has been running for twelve years. Nobody documented it. The person who knows it is leaving. You consult three providers and all three propose a rewrite quoted at between twelve and twenty-four months.
That is the most common answer and it is rarely the right one.
Why a rewrite is the default answer
It is easier to sell: the scope is that of a greenfield project, the technology is modern, the sales team knows how to present it. It is also more comfortable to deliver: nobody needs to understand the existing code.
The problem is that it often recreates the same flaws in newer syntax. The business rules accumulated over twelve years are written nowhere else but in that code. Rewriting them means rediscovering them one by one, usually at the moment a user reports that the new system gives a different result from the old one.
The alternative: takeover
Takeover means making the existing application maintainable without replacing it. It runs in four stages.
The takeover audit. Two to four weeks mapping what actually exists: modules, dependencies, scheduled jobs, integrations, fragility points. The deliverable is a note usable by a third party — that is, by someone who has never seen the application.
Characterisation tests. On untested code, the first thing to write is not a fix but a test describing the current behaviour, including where that behaviour is odd. A characterisation test does not say "this is correct", it says "this is what the system does today". Without that safety net, every fix creates two regressions elsewhere.
Reproducibility. A rebuildable test environment and a backup restore actually executed. Many old applications are developed directly in production for lack of an environment, and that is the real risk, well ahead of the age of the language.
Ending single-person dependency. Two trained people instead of one. It is the only measure that addresses the real cause, which is not the technology but the concentration of knowledge.
The honest arithmetic
A takeover audit costs between four and eight thousand euros depending on size. A full stabilisation, a few tens of thousands. A rewrite of a medium-sized business application, several hundred thousand, with a high overrun risk and a period of dual operation during which you pay for both systems.
The ratio is an order of magnitude. That does not mean a rewrite is always wrong; it means it should be decided after the audit rather than before.
The four questions that decide
The criterion is not the application's age but:
- Is the technical stack still supported by its vendor?
- Is the application documented, or can it be within a few weeks?
- Does more than one person know how to evolve it?
- Does it still meet the business need?
If all four answers are good, replacing the application means spending a large budget for no functional return. If two or more are bad, migration becomes a serious question — but one asked with numbers, after the audit.
If the key person leaves in two months
Start immediately, and run the audit paired with them while they are still there. Tacit knowledge transfer is what has the most value, and it is exactly what disappears on departure. Two weeks paired are worth three months of reverse engineering afterwards.
It is the only situation in which we advise starting before the contract negotiation is finished.