The types of software maintenance fall into four categories defined by an international software engineering standard: corrective, adaptive, perfective, and preventive, each triggered by a different kind of problem. Most explanations treat these as a fixed taxonomy. The more useful fact is that skipping one type doesn't remove the work; it converts it into a costlier version of another type later. This guide covers the four types, what each one costs to skip, and how they show up together once software has been running for a while.
The Four Types of Software Maintenance, Defined
Where the four-type definition comes from. These four types of software maintenance aren't a marketing framework; they come from ISO/IEC 14764, the international software engineering standard for software life cycle maintenance processes. A 2022 revision of the standard added a fifth type, additive maintenance, though the original four remain the ones most teams still work from day to day. Citing the standard here is for definitional accuracy only, not a claim that any team holds a certification tied to it.
Corrective, adaptive, perfective, and preventive, briefly. Corrective maintenance fixes a defect after release. Adaptive maintenance keeps the software working as its environment changes. Perfective maintenance improves something that already works. Preventive maintenance catches a risk before it becomes a problem. Between them, these types of maintenance that software engineering has relied on for decades cover almost everything that happens to software after launch. Most teams already do some version of all four without necessarily naming them, which is part of why these software maintenance categories are worth naming explicitly: it's hard to budget for work you haven't given a name to.
Skipping One Type Doesn't Remove the Work, It Converts It
Skipped preventive maintenance becomes an emergency corrective fix later. Skipped adaptive maintenance becomes a scramble when a dependency stops being supported. The work doesn't disappear when it's deferred. It just shows up later, usually under worse conditions and at a higher cost.
This isn't a small amount of capacity to lose track of. Stripe's Developer Coefficient report, based on a Harris Poll survey of over 1,000 developers and over 1,000 C-level executives across five countries, found that developers spend roughly 42% of their working week on technical debt and bad code. That's how much accumulates when this kind of work gets deferred instead of scheduled on purpose.
Why deferral feels reasonable in the moment. Nobody decides to skip maintenance outright. A preventive upgrade gets pushed back one sprint to hit a deadline, then pushed back again, and by the time it's urgent, it's no longer preventive; it's corrective, and corrective work always jumps the queue. Each of these small, individually reasonable decisions is how a business ends up with technical debt it never explicitly chose to take on.
The Four Types, Side by Side
Here's each type, what triggers it, and what happens if it's skipped.
Corrective
What triggers it: A defect found after release
What happens if it's skipped: Not really skippable; it becomes an emergency fix under pressure
Adaptive
What triggers it: The environment changes (an OS update, an API a system depends on)
What happens if it's skipped: The software breaks on someone else's schedule, not yours
Perfective
What triggers it: A performance or usability gap surfaces
What happens if it's skipped: Technical debt and slow workarounds accumulate
Preventive
What triggers it: A dependency nears end of support, or a review finds a latent risk
What happens if it's skipped: A scheduled dependency upgrade becomes an unscheduled corrective fix
Why these four, and not a longer list. It's tempting to split maintenance into more granular categories: security patching, performance tuning, documentation updates. Nearly all of them fit inside one of these four software maintenance categories once you ask what triggered the work. A security patch triggered by a newly discovered vulnerability is corrective. One applied ahead of a known deadline is preventive. The trigger, not the label, is what decides which type of maintenance software engineering teams are actually doing.
What This Looks Like as a Support Retainer
What a retainer typically covers. A support retainer typically covers ongoing corrective fixes, routine dependency upgrades, and a scheduled amount of perfective work, the kind of maintenance that's predictable enough to plan for in advance. Structuring a retainer around these software maintenance categories, rather than a vague "support hours" line item, makes it much easier to tell whether the retainer is actually sized correctly for what a system needs.
What still needs a separate conversation. A major adaptive change, migrating off a platform that's being discontinued, for example, usually needs its own scope and quote rather than being absorbed into a standard retainer. Response times and exact scope depend on the specific agreement in place, not a blanket promise that applies to every engagement, and it's worth confirming that scope explicitly before an urgent adaptive need arrives and the gap becomes obvious at the worst possible time, mid-migration, with a deadline already set by someone else's platform decision.
How to tell if a retainer is sized right. A retainer that's constantly overrun by corrective work is a sign preventive maintenance isn't happening elsewhere, not a sign the retainer itself needs to grow. The fix in that case is usually a scheduled dependency review, not more hours added to the same reactive pattern, since more hours just buys a faster response to the same recurring emergencies.
A Simple Way to Audit Where You Stand
Before agreeing to any retainer size, it helps to actually categorize the maintenance work a system already needs. Walk through each of the four types and ask one question for each: is this scheduled, or is it waiting for something to break first?
If corrective work is the only category getting attention, that's usually a sign the other three have been quietly deferred for a while. Adaptive risk builds up as dependencies age. Perfective work piles up as workarounds. Preventive reviews stop happening because nobody's asking for them. None of that shows up on an invoice until it becomes an emergency, which is exactly why naming these software maintenance categories explicitly, rather than lumping everything into a vague "support" line, makes the real state of a system visible before it becomes a crisis.
Where Burhani Fits
DevOps and maintenance sit under our Cloud Solutions work, covering the ongoing side of a system once it's live. This is one condition-dependent fit, not a universal claim, and what a specific engagement covers depends on what's already running and what shape it's in.
FAQs on Types of Software Maintenance
What are the four types of software maintenance?
The four types of software maintenance are corrective (fixing a defect), adaptive (keeping software working as its environment changes), perfective (improving something that already works), and preventive (catching a risk before it becomes a problem). They're defined by the ISO/IEC 14764 standard, and together they make up the standard software maintenance categories most engineering teams plan around.
What is the difference between corrective and preventive maintenance?
Corrective maintenance responds to a defect that's already happened. Preventive maintenance addresses a risk before it turns into a defect, like upgrading a dependency before it loses support. Preventive maintenance is usually cheaper per hour of work, but it's also the type most often deferred, which is exactly how it turns into corrective work later.
What is a dependency upgrade, and why does it matter?
A dependency upgrade updates a library, framework, or service that a system relies on. Skipping it doesn't remove the need to eventually upgrade; it just means the upgrade happens later, under time pressure, once the old dependency stops being supported or becomes a security risk that can't wait any longer.
Does every project need a support retainer?
Not every project needs one immediately, but any system expected to keep running needs some ongoing plan for corrective, adaptive, and preventive maintenance. Whether that's a formal retainer or a less structured arrangement depends on how critical the system is and how often its environment changes around it.
Is there a fifth type of software maintenance?
Yes. The 2022 revision of the ISO/IEC 14764 standard added a fifth type, additive maintenance, covering new capability added to an existing system. The original four, corrective, adaptive, perfective, and preventive, remain the types of maintenance software engineering teams reach for most often day to day.
The Bottom Line
Skipped maintenance doesn't disappear. It changes type and gets more expensive, usually right when it's least convenient to deal with. Naming which of the four types of software maintenance a piece of work actually is, before deciding to defer it, is the single cheapest step in this whole picture.
Talk to our team about what maintenance your system currently needs, and what it would cost to keep deferring it for another quarter.
