What is the difference between corrective and preventive maintenance?

Corrective maintenance is reactive: it fixes a defect once it has appeared. Preventive maintenance is proactive: it finds and removes latent faults before they surface, and reduces the complexity that makes future failures likely. One responds to problems; the other works to stop them happening. A contract that funds only corrective work pays to react, never to prevent.

What is adaptive maintenance?

Adaptive maintenance adjusts an application so that it keeps working in a changing environment, without altering its features. An operating system upgrade, a browser dropping a technology, an obsolete third-party library, a changed partner API, a new regulatory obligation: the application must absorb each one. It is a core part of keeping a system secure, and the riskiest type to postpone.

What is perfective maintenance?

Perfective maintenance improves an application after delivery. It covers both internal quality, by optimising a slow query, simplifying an interface, refactoring a module or strengthening tests, and enhancements that follow evolving needs, such as a refined business rule or an additional report. Significant enhancements are scoped and architected like small projects rather than slipped into a routine retainer.

What is preventive maintenance in software?

Preventive maintenance is the work done to stop problems before they occur: detecting latent faults, reducing risky complexity, hardening fragile parts, and keeping dependencies and documentation in good order. Its benefit is deferred, which is why it is the first activity cut under a flat fee, and the most costly cut in the long run.

How is application maintenance billed?

Application maintenance, also called application support and maintenance, can be billed as a monthly retainer, on a time-and-materials basis, or as a combination of both. The billing model matters less than how clearly it sets out what it covers. A well-built contract distinguishes the four types of maintenance and assigns each explicit priorities or budgets, rather than a single all-inclusive amount that hides how the work is actually split.

How long should a business application be maintained?

For as long as it is used. A custom business application often has a lifespan of several years, sometimes well beyond ten. Over that period, the cumulative cost of maintenance frequently exceeds the cost of building it. The question is therefore not whether to maintain it, but how to split the effort between fixing, adapting, improving and preventing.

Application Maintenance: Corrective, Adaptive, Perfective, Preventive

On most contracts, application maintenance appears as a single line: a monthly fee, one point of contact, a vague promise to keep the application running. That billing simplicity hides a more demanding reality. Beneath the word sit four distinct engineering activities, with different skills, different costs and different risks. Treating them as one means flying blind over a budget line that, across the lifetime of a business application, often ends up exceeding the cost of building it in the first place.

ISO/IEC 14764, the reference standard for software engineering, classifies these activities by their nature: corrective, adaptive, perfective and preventive maintenance. Together they cover most of what a custom software team does once an application has gone live, and each follows its own logic.

Naming them separately is not a matter of vocabulary. Done well, these four activities are nothing like a comfort expense: they keep a running system reliable, they secure it against a changing environment, and they modernise it so it keeps pace with the business. This is engineering work, not a commodity bought by the month without looking at what it covers. To steer it, you first have to distinguish what you are paying for, what you are neglecting, and what you are entitled to expect.

The four types of application maintenance: corrective (fixing defects, reactive), adaptive (securing against a changing environment), perfective (improving quality and absorbing new needs) and preventive (removing latent faults before they surface), placed on a scale from reactive and endured to proactive and chosen.

Corrective maintenance: fixing what breaks

Corrective maintenance deals with defects: malfunctions, calculation errors, behaviour that departs from what the application should do. It is the most visible and intuitive form of maintenance, the one that comes to mind first when a user reports that a screen no longer responds.

It is reactive by nature. A defect appears, you diagnose it, you fix it, you check that the fix does not introduce another one elsewhere. Its defining economic feature is that it is largely endured: you choose neither the timing nor the scale of a bug, and a critical defect in production demands immediate intervention whatever else is on the schedule. It is also the part of maintenance whose volume says a great deal about what lies underneath. An application that generates a constant stream of fixes does not have a maintenance problem first: it has a design problem, which corrective maintenance merely makes visible month after month.

Not all fixes carry the same weight, though. A blocking defect that halts a processing chain does not call for the same commitment as a cosmetic glitch reported by a single user. This is why a serious contract grades corrective maintenance by severity, with distinct response and resolution times depending on criticality. Blurring those tiers leads to one of two pitfalls: overpaying for a responsiveness you do not need everywhere, or discovering too late that no firm commitment covers the case that actually matters.

Adaptive maintenance: keeping pace with a shifting environment

Adaptive maintenance does not touch what the application does. It adjusts the application so that it keeps working in an environment that never stops changing. An operating system upgrade, a browser dropping a technology, a third-party library that is no longer supported, a partner API that changes its format, a regulatory obligation that imposes new data handling: all of these are external changes the application must absorb without the user noticing a single new feature.

It is the easiest maintenance to postpone and the most dangerous to neglect. Deferring a security update or a version upgrade produces no visible effect, until the day the accumulated gap becomes a wall: a dependency too old to update without breaking everything, a known vulnerability left open, an incompatibility that blocks any further change. A large part of securing a business application is decided here, in adjustments that nothing visibly demands.

It is also the only maintenance you can largely anticipate. The end-of-support dates of a system, a framework or a dependency are known in advance; absorbing them as you go, through small regular updates, costs a fraction of what a massive catch-up done under pressure demands. Adaptive maintenance rewards regularity and punishes wait-and-see, which makes it one of the best indicators of how an application is genuinely looked after.

Perfective maintenance: improving without changing the brief

Perfective maintenance improves the application after delivery. Some of it sharpens internal quality without altering behaviour: optimising a slow query, simplifying a screen that has become confusing, refactoring a module to make it clearer and safer to change, strengthening test coverage. Some of it accommodates evolving needs: a refined business rule, an extra report the management asks for, a workflow that grows more elaborate as the activity it supports matures.

This dual nature is where a useful distinction has to be drawn. A genuine enhancement is not a fix slipped into the running retainer: it extends the scope, and it is scoped, costed and architected like a small project in its own right. Treating it as a routine maintenance task risks stacking changes without an overall view, until the application becomes a pile of successive layers no one fully masters. An application that grows well is one whose every addition has been thought through in continuity with its architecture, rather than grafted on under pressure. That is the whole difference between an application that grows and one that merely swells.

Preventive maintenance: the invisible work that keeps cost down

Preventive maintenance is the work you do so that problems do not happen. It looks for latent faults before they surface, reduces the complexity that makes future changes risky, hardens the parts of the system most likely to fail, and keeps dependencies and documentation in a state where the next intervention stays cheap. None of it answers a visible incident, and all of it shapes how the application will behave months from now.

It is the maintenance most exposed to budget cuts, for a simple reason: its benefit shows up not on the day you carry it out, but later, in everything that does not happen. Preventive work kept up means corrective work that stays low, changes that stay quick to deliver, and a codebase whose quality does not erode. The reverse is just as mechanical: an application whose latent weaknesses are never addressed grows steadily more expensive to change, until the smallest modification demands a disproportionate effort. Preventive maintenance is where the durability of an application is decided, and it is also the first thing sacrificed when the four types are not told apart.

Why this distinction decides your maintenance contract

Telling these four activities apart is not academic: it is what lets you steer a maintenance contract instead of enduring it. The four profiles are nothing alike. Corrective is endured, and reveals the quality of the original design. Adaptive is deferrable, but accumulates a security risk. Perfective is an investment that follows the business as it grows. Preventive is an insurance on durability, whose value is measured only by its absence. Pooling these profiles into a single all-inclusive fee amounts to giving up on knowing what you fund.

The danger of that undifferentiated fee is not only that it makes spending opaque. It is the silent pressure it creates towards the only maintenance that shows. A provider paid a flat fee, called on constantly for visible fixes and enhancements, has no incentive to spend time on preventive work, which goes unnoticed. Preventive becomes the adjustment variable, sacrificed first. Yet it is the most expensive cut in the long run: it is what then inflates corrective and perfective work, by letting technical debt settle in quietly.

The vicious circle of a flat maintenance fee: an all-inclusive flat fee pushes towards visible maintenance, which leads to cutting preventive work, lets technical debt settle in, inflates corrective work and raises the cost, which in turn reinforces the original reflex.

A well-built maintenance contract therefore does not come down to a monthly amount. It distinguishes the four activities, assigns them explicit budgets or priorities, and protects the preventive line in particular, the one that short-term logic always pushes to trim. For a board signing or renewing a contract, the useful question is not how much maintenance costs, but what exactly that amount covers, and who decides how it is split. An all-inclusive figure with no detail is not a guarantee of simplicity: it is a blind spot over the work actually carried out. Paying for the structural choices that make an application last, rather than only repairing it when it breaks, is what a contract that tells the four types apart is built to do.