Repair rather than replace – why not for software too?

Imagine your company owns a delivery van. It is ten years old, has a few dents and worn upholstery. But it runs reliably, has long since been paid for and does exactly the job it was bought to do.

A new model would offer more modern technology and additional features. But does the company really need them? Perhaps it would make better economic sense to continue maintaining the van, replacing worn parts and using it for a few more years.

Why should this reasoning be fundamentally different for software?

The European Union has made product repairability a legal objective. Directive (EU) 2024/1799 of 13 June 2024, known as the Right to Repair Directive, requires manufacturers of certain goods to offer repairs even outside the statutory guarantee period. Member States had to transpose the Directive by 31 July 2026.¹

Regulation (EU) 2024/1781 on the ecodesign of sustainable products identifies upgradability, repairability, maintenance and refurbishment in Article 5(1)(d) to (f). Paragraph 2 even takes account of premature product obsolescence, for example when software stops working after an operating-system update.²

These rules concern certain physical goods and do not establish a general obligation to repair business software. Nevertheless, the principle can be applied: why replace something while it still fulfils its purpose and can be operated economically?

Many companies run applications developed twenty or thirty years ago. Extensions and interfaces have been added since then. The user interface and programming language may no longer be modern. Nevertheless, the application processes orders, manages stock or supports production. Above all, it reflects the company's particular requirements: experience, exceptions and business rules that are often no longer fully documented anywhere. Replacing it may therefore have far-reaching effects on business processes.

Existing software has proved itself in production. Employees know the processes, data and interfaces are already in place, and many bugs have long since been fixed.

A targeted enhancement can involve considerably less effort than purchasing a new system. Perhaps all that is needed is a report, an interface, a new pricing calculation or the automation of one step in a process.

Why replace the entire application for that?

An older programming language is not automatically unsuitable either. What matters is maintainability, the availability of development tools and a reliably supported platform.

Gradual modernisation also allows investments to be spread over several years rather than financing a major replacement project.

Where are the limits?

Existing software should not, however, be retained at any cost. Numerous extensions can make program structures difficult to understand; dependencies may be unknown and documentation missing. Even small changes can then have unexpected consequences – so-called technical debt.

Outdated components, missing security updates or unsupported operating systems can pose considerable risks. If every new requirement calls for extensive intervention, continued development may ultimately cost more than replacement.

The decisive factor is therefore not age but the application's long-term technical and economic viability.

The cost of modifying an existing application is often compared only with the purchase price or licence fee of new software. That comparison is too narrow.

A new system involves installation, configuration, data migration, new or modified interfaces and the implementation of individual business processes. There are also training, testing, project management, consultancy and possibly parallel-running costs.

A purely hypothetical five-year example illustrates this:
Existing software: a one-off CHF 40,000 for revisions and enhancements, plus CHF 12,000 per year for maintenance and operation.
Total cost over five years: CHF 100,000.

New software: CHF 110,000 for purchase and implementation, CHF 55,000 for migration and modifications, CHF 15,000 for training, plus CHF 18,000 per year for maintenance and operation.
Total cost over five years: CHF 270,000.

These figures are not market prices; the balance may look different depending on the circumstances. High maintenance costs or fundamental upgrades can also make the existing solution more expensive.

This makes a multi-year cost-benefit analysis all the more important, taking comparable functionality, risks and total costs into account. And even if the new software offers more, what tangible benefit does the company gain?

Changing systems can take many months. Business departments must define requirements, review processes, test functions and document errors. This takes employees away from their day-to-day work. During long projects, requirements may change again before implementation is complete.

Targeted enhancements can often be delivered more quickly without changing the entire IT landscape. They too must be properly developed, tested and documented. Nevertheless, the effort involved in a complete migration should not be underestimated.

New legal or regulatory requirements may demand functionality that can only be implemented in the existing software at disproportionate cost, for example in data protection, security requirements or industry-specific reporting obligations.

A significantly changed business model, additional locations, international expansion or a vastly increased range of functions may also exceed the capabilities of the existing architecture.

Another reason is the lack of technical support: action is needed if essential components are no longer available or the platform can no longer be operated securely. But might modernising the infrastructure be enough, rather than replacing the entire application? A particularly delicate situation arises when nobody understands the software any more.

A functioning application can become a risk when its developer retires, the administrator leaves and the documentation is incomplete. Often, only one person has made changes over many years.

Questions about individual functions are then met with: ‘You'll have to ask our administrator.’ (See the blog article of the same name: You'll have to ask our administrator)

Without that knowledge, changes become risky: nobody can reliably assess their impact. However, loss of knowledge is primarily an organisational problem, not necessarily a technical one.

Source-code analysis, documentation of critical processes and the development of internal or external expertise can make further development possible again. The crucial question is how much effort is needed to recover that knowledge.

Buying new software does not automatically solve this problem. Existing business rules must also be understood during a migration; otherwise, important functions or exceptions may be lost. An assessment of the current system is therefore worthwhile in either case.

Before making any major investment in business software, several questions need answering:
- Does the existing application meet today's requirements?
- Which additional functions will actually be needed in the coming years?
- Can the technical platform continue to be operated reliably and securely?
- Are the source code, documentation and relevant expertise available?

And above all: how do the total costs and risks of further development and replacement compare over a realistic period?

Beyond costs, the effects on employees, customers and business processes also matter. A middle course often makes sense: proven core functions are retained while individual components are modernised or replaced.

Back to the delivery van: as long as it runs reliably, is safe and fulfils its purpose economically, it need not be replaced. Persistently high modernisation costs may, however, justify buying a new one.

The same applies to software. The repairability promoted by the EU offers food for thought: software is not a disposable product; it embodies investment, experience, business processes and often decades of knowledge. New software can bring advantages. But modernity alone is not an economic benefit.

Before embarking on any major replacement project, the question should therefore be:

‘What exactly can we no longer achieve with our existing software – and is complete replacement really the best way to achieve it?’

Original article: Reparieren statt ersetzen – warum eigentlich nicht auch bei Software?