What does software maintenance and management cost?
The build cost of software is only half the story. Once a system is live, a recurring cost begins for hosting, patches, monitoring and further development, which often outweighs the initial development. An honest overview of what maintenance costs and which choices determine those costs.
Maintenance is not an afterthought, but a budget in its own right
Many organisations budget carefully for building a system and then assume that maintenance "will just be part of it". In practice, maintenance is a structural, recurring cost with its own dynamics: infrastructure keeps running, dependencies age, and users ask for small changes once the system is in use.
On this page you will read about the forms of maintenance defined in the international ISO/IEC/IEEE 14764 standard, which factors determine the costs, and how to set a realistic maintenance budget alongside your development budget.
- Hosting and infrastructure costs
- Security patches and dependency updates
- Monitoring and incident response
- Agreed SLA level and response times
- Ongoing development alongside upkeep
- Age and complexity of the system
The four types of software maintenance
The international standard ISO/IEC/IEEE 14764 (originally defined in IEEE 1219) distinguishes four types of maintenance. Each type has its own cost pattern and its own point at which you pay for it.
Fixing faults
Reactive, following a report
Fixing bugs that only surface after go-live: a crash on specific input, a calculation that is wrong, an integration that gets stuck. This is the most visible form of maintenance, but usually not the largest cost.
Keeping pace with the environment
Driven by external changes
Changes needed because the environment changes: a new operating system version, a modified API at a connected party, or changed legislation such as GDPR or NIS2 that introduces new requirements.
Improving and further developing
Demand-driven, ongoing
Extensions and improvements that stem not from a fault but from evolving insight: a faster report, an additional role in the permissions structure, or a workflow that, after half a year of use, needs to work slightly differently.
Preventing problems
Proactive, before something goes wrong
Work carried out before a problem arises: updating outdated libraries while they are still supported, monitoring code quality, and tracking performance before users experience a system as slow.
Which factors determine the costs?
Regardless of which form of maintenance is needed, these factors account for most of the annual running costs.
Hosting and infrastructure
Server costs, storage and data transfer continue for as long as the system runs, and scale with the number of users and the volume of data. A system that grows periodically requires a review of its infrastructure choices.
Security patches and dependency updates
Frameworks, libraries and operating systems receive continuous updates, some of which are critical for security. A system that falls behind here accumulates technical debt, which becomes more expensive to clear later.
Monitoring and incident response
Actively monitoring whether a system is running properly takes time, whether or not any incidents actually occur. The faster a fault must be resolved, the more availability demands on the maintenance side.
Agreed SLA level
A response time of a few hours on working days requires a different setup than 24/7 availability with guaranteed response times. The stricter the agreement, the higher the cost of meeting it.
Ongoing development alongside upkeep
Simply keeping a system running is cheaper than one that keeps evolving to meet new requirements. Most organisations want both, and often budget them as a single item, even though they are two distinct activities.
Age and complexity of the system
An older system with little documentation and outdated technology costs more to maintain than a recently built system using modern, well-supported technology. Deferred maintenance is rarely cheaper the longer it waits.
Basic maintenance or structured management: which trade-off matters?
Not every system needs the same level of management. The right choice depends on how critical the system is to your operations and how often the processes around it change.
Basic maintenance is sufficient if
the system performs a supporting, stable function, faults have no direct business-critical impact, and the surrounding process rarely changes.
Structured management with an SLA is needed if
the system is business-critical, downtime has a direct impact on customers or revenue, or the surrounding process changes regularly and the system needs to keep pace with it.
Not sure whether a system should be custom-built at all, or whether an off-the-shelf package will do? Read build vs. buy: off-the-shelf or custom software. If you'd rather outsource the management of an existing system than organise it yourself, see outsourced application management.
What does a maintenance engagement look like in practice?
Handover and documentation
Documenting how the system is built, which integrations exist and which choices were deliberately made during construction, so that maintenance does not start with reverse engineering.
Setting up monitoring and incident handling
Agree how faults are detected, who picks them up and within what timeframe, in line with how critical the system is.
Regular maintenance cycle
Fixed moments for updating dependencies, checking security patches and reviewing system performance, rather than postponing this until something goes wrong.
Periodic review and further development
Regularly review which requests have come in since go-live, and which of them are worth scheduling as further development.
How do you budget sensibly for maintenance?
Set aside a maintenance budget separate from the development budget, rather than hoping no further costs arise after handover. Maintenance is not a one-off item; it continues for as long as the system is in use.
Distinguish between upkeep (keeping the system running as it is) and further development (letting the system grow). Both are legitimate, but they don't automatically belong under the same budget line.
Schedule dependency and security updates periodically, rather than letting them pile up. An update postponed for two years almost always costs more to catch up on than one that was kept current all along.
Agree in advance who is responsible for which type of maintenance, especially if the build and the management sit with different parties. Lack of clarity here is a common cause of delays during incidents.
Frequently asked questions about maintenance costs
Maintenance costs depend heavily on the complexity and age of the system, the agreed SLA level and how much further development you want alongside upkeep. A generic figure would be misleading; after an intake, we can give you a realistic estimate.
Maintenance keeps the system running as it is: fixing bugs, applying updates, monitoring. Further development adds new functionality or adjusts existing functionality. Both are legitimate, but each deserves its own budget line, because one is reactive and the other demand-driven.
Postponed updates and neglected monitoring accumulate as technical debt: outdated dependencies that are no longer safe, and a system that becomes harder to change over time. Catching up therefore almost always costs more than keeping up periodically.
Not necessarily, but a party that knows the system needs less time to get up to speed during incidents. If maintenance moves to another party, make sure there is good documentation and a handover moment, so that knowledge of earlier choices isn't lost.
Look at the impact of downtime: if a fault directly affects customers or revenue, a tight SLA with short response times is sensible. If the system is supportive and a few hours of outage is acceptable, a lighter level will suffice.
Yes, keeping security-critical updates current for frameworks and libraries is part of preventive maintenance. Ideally this happens before a vulnerability is actively exploited, not only after it has been reported.
Yes, following a technical intake in which we review the code, documentation and current status of the system. Based on that, we determine whether and how we can responsibly take over its maintenance.
Maintenance assessment for your system?
Briefly describe the system involved and the maintenance you currently carry out. Within a few working days we will give you a realistic assessment of what structured maintenance would involve for your situation.