Applications & maintenance practice
Business applications: maintain, evolve, and migrate only when justified
An application that delivers the expected service does not need rewriting. It needs documenting, testing, and to stop depending on one single person.
The market's reflex when facing an old application is to propose a rewrite. It is the most profitable assignment to sell and the riskiest to buy: it ties up a large budget for twelve to twenty-four months, and it often recreates the same flaws in more modern syntax.
Our reflex is different. We start by taking over what exists: mapping, documenting, writing characterisation tests, reducing single-person dependency. That first step costs a fraction of a rewrite and removes the immediate risk. Migration remains possible afterwards, module by module, when a business need justifies it.
The symptoms we see most often
- One single person knows the application, and they are leaving or nearing retirement
- No architecture or business-rule documentation
- Development happens directly in production, for lack of a test environment
- The technical stack version is no longer supported by the vendor
- Every enhancement takes three times longer than planned
- Integration requests with other tools are systematically refused for lack of a way to do it
How we approach it
The takeover audit before any decision
Two to four weeks to map what actually exists, identify the debt and write a note usable by a third party. That document is what then allows arbitration between maintaining and migrating, on facts rather than intuition.
Characterisation tests before any change
On untested code, the first thing to write is not a fix but a test describing the current behaviour, including where it is odd. Without that, every fix creates two regressions elsewhere.
Open up rather than rewrite
When the need is to integrate the application with the rest of the IT estate, exposing a REST API over what exists solves the problem for a fraction of a rewrite's cost, and lets you plug in a modern interface without touching the business core.
Two people on every file
The source of risk is not the old technology, it is single-person dependency. We systematically train two people on every maintained application, including where one would be enough for the workload.
Services in this practice
Frequently asked questions
Does an old application necessarily need replacing?
No. The criterion is not age but four questions: is the technical stack still supported, is the application documented, does more than one person know how to evolve it, and does it still meet the business need. If all four answers are good, replacing it would spend a large budget for no return.
How much does taking over an undocumented estate cost?
The takeover audit runs from €3,900 to around €8,000 depending on the size and age of the application. At the end you hold a usable note and a firm quote for stabilisation. It is deliberately a small spend: it exists to decide, not to commit.
What if the historical developer leaves in two months?
Start immediately, and run the audit paired with that person 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.
Twenty minutes is enough to know whether we are useful
No sales deck. You describe the need, we say whether it is in scope, at what price and on what timeline. If it is not for us, we say so during the call.