Software maintenance is the work done on a piece of software after it has gone into use, to keep it working, secure and useful. It covers fixing faults, keeping the software running as the technology around it changes, improving it for the people who use it, and dealing with weaknesses before they cause a failure. Those four jobs are the four classic types of software maintenance: corrective, adaptive, perfective and preventive.
This article explains each type with examples from ordinary business systems, and then what maintenance looks like in practice for a company that depends on software somebody built for it.
The four types of software maintenance
The four types are defined in the international standard for software maintenance, ISO/IEC/IEEE 14764. They are distinguished by the reason for the change.
| Type | Why the change is made | Example |
|---|---|---|
| Corrective | A fault has been found in use | An invoice total is a penny out when a discount is applied |
| Adaptive | Something around the software has changed | The database version it runs on is going out of support |
| Perfective | The software could serve its users better | A report that takes two minutes to open is made to open in seconds |
| Preventive | A hidden weakness could cause a failure later | A nightly job with no error handling is given some before it fails silently |
Corrective maintenance
Corrective maintenance repairs faults discovered after the software went live. Every system has them, however carefully it was tested, because real users and real data find paths that testing did not. A good repair deals with the cause. If the same fault keeps coming back and is patched each time, the cause has not been found.
Adaptive maintenance
Adaptive maintenance keeps the software usable when its surroundings change. The software itself may be untouched and working, but the operating system, database, browser or a connected service has moved on. SQL Server 2016, for example, stopped receiving security fixes on 14 July 2026, and .NET 8 reaches the end of its support on 10 November 2026. A supplier withdrawing an old version of its interface, or a change in tax rules, calls for the same kind of work. Our end-of-support dates list the platforms we are asked about most.
Perfective maintenance
Perfective maintenance improves software that already works: a new field on a form, a quicker screen, a clearer layout, a report that somebody currently builds by hand in a spreadsheet. The standard also counts work that makes the code easier to change in future, even though users never see it.
Preventive maintenance
Preventive maintenance corrects faults that are present but have not yet caused trouble. Examples are a backup that is taken every night and has never been restored, an order number field that will run out of digits next year, and a calculation with no automated test around it. This is the type most often skipped, because nothing appears to be wrong.
A fifth type in the current standard
The 2022 edition of the standard adds a fifth type, additive maintenance, for larger new functions added after delivery. It also groups the types in a way that is useful when reading a contract. Corrective and preventive work are corrections: they make the software do what it was already meant to do. Perfective and additive work are enhancements: they meet a new requirement. Adaptive work can fall on either side. Support agreements commonly include corrections in the fee and charge for enhancements, so it is worth knowing which is which before you sign.
Why software needs maintaining when nothing is broken
Software does not wear out as a machine does. The code that ran correctly last year will run the same way this year. What changes is everything around it.
The platform ages. Vendors publish the dates on which each version of a database, framework or operating system stops receiving security fixes, and those dates arrive whether or not anyone has planned for them.
The business changes. A new product line, a second warehouse or a different way of pricing does not fit the screens that were designed five years ago, and staff start keeping spreadsheets on the side.
The data grows. A query that was instant with ten thousand records can take a minute with two million.
The people change. The developer who knew why a rule was written that way moves on, and the knowledge goes with them unless it was written down.
None of these is a fault in the usual sense. Left alone, each one makes the system slower, less safe or harder to change.
How maintenance differs from support
The two terms are used loosely and often together. Support usually means responding when something goes wrong or a user needs help: a person to call, a ticket, a fix. Maintenance is the planned work that keeps the system healthy, such as updates, security fixes, performance work and small changes.
A supplier that only offers support will react to faults and never get ahead of them. One that only does planned work may not be available on the day something breaks. When you compare quotes, check that both are covered and by whom. The opening sections of our software maintenance page describe how we combine them.
What maintenance looks like month to month
For a bespoke business system in steady use, a typical month includes some of each type:
- faults reported by users are diagnosed, fixed and released;
- security updates are applied to the server, database and the libraries the code depends on;
- error logs and monitoring are reviewed, so that problems are found before users report them;
- a backup is restored to prove that it can be;
- a few small changes requested by the business are made;
- build and release instructions are updated when something changes.
In our experience, fixing faults is the smaller part of the work on a system that is in active use. More of the effort goes on adapting and improving it, which is why a budget that allows only for bug fixes tends to run short.
Maintenance is normally paid for as a monthly fee against a written scope, with larger pieces of work quoted separately. A version upgrade or a new module is a small project, and it is reasonable for it to have its own price. We explain what moves the monthly figure in how much software maintenance costs.
What happens when maintenance stops
Usually nothing, for a while, and that is the danger. The system keeps running, the money saved is visible and the cost is not.
The cost builds in two ways. Skipped upgrades and postponed repairs accumulate as technical debt, which shows up later as changes that take weeks when they should take days. And the platform slips out of vendor support, so that security weaknesses found from then on are never repaired. A system in that position has become what people call a legacy system, and catching up costs more than keeping up would have.
There is a legitimate case for minimal maintenance: a system that will be retired within a year or two. Even then the security updates and the backups are worth keeping going.
Five checks to make on your own system
You can find out how well a system is being maintained without reading any code. Ask whoever looks after it these questions.
- When was the last security update applied to the server, the database and the framework, and what versions are they on now?
- Which of those versions goes out of support in the next two years, and is there a plan and a budget for each?
- When was a backup last restored, as opposed to taken, and how long did the restore take?
- When was the last change released, and could a different person have done it from the written instructions?
- If a serious fault appeared tomorrow, who would fix it, and have they built the system from its source code recently?
Clear answers to all five mean the system is in good hands. A vague answer to any of them is the place to start.