Software Maintenance Cost: The Ten-Year Picture

Caixa Mágica Team · 28 October 2026

A development budget ends at handover. The life of the system does not. Neither does the software maintenance cost.

That is why the one-year view of software maintenance cost misleads so badly. A system costing €80,000 to build, affordable-looking in year one, becomes a commitment of €200,000 or more across its working life. That number exists whether or not anyone budgeted it. The decision that most affects it is neither the hourly rate nor the technology. It is who keeps the knowledge on delivery day.

Figure	What it means
15–20%	Of build cost, per year, in maintenance. Some sources give 10 to 20 per cent
€200–1,500	Per month in hosting and infrastructure, depending on system size
€150–200k	Ten years of maintenance on a €100,000 build, before any new feature
1.5–2×	What maintenance costs relative to the original build across a decade

The initial budget pays for the smaller part of the project. None of the recurring cost buys new features: it buys the system continuing to do exactly what it already did.

What is software maintenance cost spent on?

Software maintenance cost splits across four kinds of work, distinguished in ISO/IEC 14764 and behaving very differently in practice. Corrective maintenance is the one everyone budgets for. Adaptive maintenance is the one that breaks budgets.

Type	What it covers	In practice
Corrective	Fixing what surfaces	Defects that appear under real use. Not predictable, concentrated in the first months, then it settles.
Adaptive	Keeping up with the outside	Operating systems, dependencies, integrations, law. It arrives from outside, unannounced, and on someone else's schedule.
Perfective	Improving what exists	Performance, usability, small adjustments. The only one you can genuinely defer.
Preventive	Reducing debt before it costs	Predictable, and the first to be cut, because it is the only one with no visible symptom.

Preventive maintenance is the only one that reduces the cost of the other three. A system without it does not look worse in year two. It looks identical, and in year five every change takes three times as long. Technical debt is not an accounting metaphor: it is future work contracted without anyone signing for it.

What actually forces change?

Worth seeing with concrete examples rather than abstract categories. Both of these come from work we do and are publicly verifiable.

A hardware generation changes. Portugal began issuing the Cartão de Cidadão v2 in June 2024, redesigned to meet the security and format standards of Regulation (EU) 2019/1157. The v2 card uses ECDSA keys where v1 used RSA, and it supports contactless reading. Any integration built before mid-2024 and untouched since is running against assumptions the card no longer satisfies. No line of the client's code changed. The context did.

A distribution updates a dependency. On distributions shipping pcsc-lite 2.3.0, such as Ubuntu 24.10 and Fedora 41, a specific flatpak package became necessary for the middleware to work. A decision taken upstream, by people maintaining a Linux distribution, and a real cost to anyone running that software in production.

These two illustrate the general pattern. Adaptive maintenance is not triggered by you. It is triggered by hardware manufacturers, operating system maintainers, regulators and integration partners.

Budgeting a project for 2027? Send us the scope and you get the ten-year picture, not just the build.

Talk to our team →

What moves software maintenance cost up or down?

Six factors move software maintenance cost, ordered by impact across a decade. The first is dominant and the least discussed.

1
Who keeps the knowledge. If the team that built the system disperses at handover, the first year of maintenance is spent rediscovering decisions. Continuity is cheaper than documentation, and documentation is far cheaper than archaeology.
2
Number of integrations. Every third-party system is a change surface outside your control. Integrations add 20 to 30 per cent to the initial build and keep charging for the system's whole life.
3
Technology choices. Not modern versus old, but supported versus abandoned. A boring technology with ten years of guaranteed support costs less to maintain than an exciting framework whose maintainers move on in year three.
4
Test coverage. A system with tests can be changed with confidence. A system without tests requires manual verification of every change, every time, forever. This is where the ten-year number is decided, and it is the line most often cut from the build budget.
5
Compliance requirements. Regulated sectors add evidence, audits and retention. It is real and predictable cost, which is preferable to real and unpredictable cost.
6
Size of the user base. More users means more edge cases found, more support, and more pressure on performance.

When is rewriting cheaper than maintaining?

There is a point where maintaining stops making sense, and it arrives later than most engineering teams would like. A rewrite is justified when the technology has lost security support with no upgrade path, when every change breaks three things elsewhere consistently, when nobody in the organisation understands significant parts of the system, or when annual maintenance approaches the cost of building it again.

Three bad reasons appear far more often. The technology is old, but old and working is an asset rather than a problem. The current team would rather work on something else, which is a management question and not an architecture one. And it is easier to get budget for a new project than for maintenance, which is true, and is how organisations end up rewriting systems that worked.

A rewrite restarts the clock: a new build cost, a new wave of early defects, and the same 15 to 20 per cent per year from then on. It pays only when the maintenance bill is genuinely worse.

The proof that is hard to have

Most software companies cannot show what happens to a system at year ten, because they were not there. We have worked on Portuguese national digital identity middleware, including the Citizen Card software, for over a decade. In that period the middleware absorbed a card generation change with a different cryptographic algorithm, the introduction of contactless reading, several versions of the applicable European regulation, and dependency changes at the Linux distribution level.

None of those changes was requested by a customer. All of them had to be absorbed for the system to keep working. That is what maintenance is, and it is why the annual percentage is not a service fee: it is the price of the system continuing to exist in a world that does not hold still.

How do you budget for software maintenance cost?

Treat maintenance as a budget line from the start. Build plus 15 to 20 per cent per year plus infrastructure, over the horizon the system will genuinely have. If that number is unacceptable, the project is not viable, whatever the build costs.

Decide who maintains before you deliver. The team that built it, an internal team receiving the code, or a mixed model. Any works. None works if the decision comes six months later.

Buy test coverage during the build. It is the only line in the initial budget that measurably reduces the cost of the following ten years. Cutting it to fit the build budget moves cost somewhere you do not have to justify it today.

Separate maintenance from evolution. Maintaining is the system continuing to do what it did. Evolving is making it do more. Merging them into one budget line guarantees evolution eats maintenance, and the system degrades while nobody notices.

What should a software maintenance contract cover?

The four kinds of work, each named separately. A contract that only says "maintenance" usually covers corrective work and leaves adaptive work to be negotiated each time. That is where software maintenance cost becomes unpredictable.

Beyond scope, three clauses matter most. Response times by severity, so that a production failure and a cosmetic issue are not handled the same way. Responsibility for dependencies and platform changes, so it is clear who acts when an operating system or a library moves. Knowledge transfer on exit, so the system can be handed to another team without starting from zero.

A monthly or quarterly report on what was done, broken down by type, closes the loop. It shows whether preventive work is happening or only being promised.

Frequently asked questions

Software maintenance cost in numbers

How much does software maintenance cost per year?

Public references converge on 15 to 20 per cent of build cost per year, with some sources giving 10 to 20 per cent. Infrastructure and hosting add €200 to €1,500 a month depending on the size of the system. On a €100,000 build, that is €15,000 to €20,000 a year before any new feature.

Does maintenance cost more than the original build?

Over a ten-year horizon, yes. At 15 per cent a year, accumulated maintenance reaches one and a half times build cost; at 20 per cent, double. That is simple arithmetic on the published percentages, and it is why budgeting only for the build understates the real commitment.

Why it happens

Why does software that is not changing need maintenance?

Because the context changes. Dependencies lose support, operating systems alter behaviour, partners change APIs, hardware generations shift and legal obligations take effect. The Cartão de Cidadão v2, issued from June 2024, moved from RSA to ECDSA keys, which affects integrations that did not change a single line of code.

What are the types of software maintenance?

Corrective, which fixes defects; adaptive, which keeps up with external changes such as operating systems, dependencies and legislation; perfective, which improves what exists; and preventive, which reduces technical debt. Adaptive is the least predictable, and preventive is the first to be cut despite being the only one that lowers the cost of the other three.

What to do about it

When is a rewrite worth it instead of maintaining?

When the technology has lost security support with no upgrade path, when every change consistently breaks other things, when nobody in the organisation understands significant parts of the system, or when annual maintenance approaches the cost of rebuilding. Being old is not by itself a reason to rewrite a technology that works.

How do I reduce maintenance cost?

Keep the knowledge close to the system through team continuity and documentation; buy test coverage during the build, which is the initial line with the largest effect on the following decade; limit the number of integrations; choose technologies with predictable support; and budget preventive maintenance rather than cutting it under pressure.

Caixa Mágica Team

Caixa Mágica Software is a Portuguese software company with 20+ years of experience delivering custom software, AI solutions and nearshore development teams for European businesses.

Software Development · Caixa Mágica Software

Talk to a team that was still there at year ten

We have worked on Portuguese national digital identity middleware for over a decade, and keep systems in production with the same client for years. If you are budgeting a project for 2027, send us the scope and you get the ten-year picture rather than the build alone.

Custom software development Start a conversation