What Is Software Maintenance?

Software engineers generally group ongoing maintenance work into four categories. Corrective maintenance fixes defects that surface after release — a report that miscalculates a total, a screen that crashes on a particular phone. Adaptive maintenance changes the software so it keeps working as the world around it changes — a payment gateway updates its API, a mobile OS drops support for an old permission model, a tax rule changes. Preventive maintenance finds and fixes problems before they cause an outage — patching a library with a known vulnerability, adding monitoring, cleaning up a query that is close to timing out under load. Improvement (sometimes called perfective) maintenance is smaller-scale polish that was not urgent enough to hold up the original launch — a clearer error message, a faster report, a screen that needed one more field.

Imagine a logistics company running a dispatch app that routes drivers to daily deliveries. In its first year of maintenance, that same app might see a corrective fix for a bug that double-counts fuel costs, an adaptive change when the map provider changes its pricing API, a preventive upgrade to its authentication library after a security bulletin, and an improvement that lets dispatchers filter routes by driver instead of only by zone. All four are maintenance — none of them is a new project.

A warranty period, when a vendor offers one, is narrow by design: it covers defects that existed in the code at handover, for a fixed window, usually at no extra cost. It does not cover new operating system versions released after handover, a browser vendor changing how cookies work, or a business process that has evolved since launch — those fall outside what a warranty was ever meant to include, even though they still need fixing.

Maintenance is different in scope and structure. It is an ongoing, usually paid, relationship that covers whatever keeps the software correct and current over its life — including problems that did not exist at launch and only appeared because something outside the code changed. A new project, by contrast, adds capability the software never had: a new reporting module, support for a second business location, an integration with a system that did not exist when the original app was built. Maintenance keeps what exists working; a new project extends what exists.

In practice, most maintenance work is unglamorous and recurring rather than a single big event. A team — in-house or outsourced — typically runs uptime and error monitoring so problems are caught before a customer reports them, applies security patches to the framework and its dependencies on a regular cycle, takes and periodically tests backups, and works through a queue of support tickets raised by staff or customers.

None of these activities is dramatic on its own, which is exactly why they are easy to let slip when a business gets busy. The businesses that manage maintenance well tend to treat this list as a fixed operating rhythm — patching on a schedule, checking backups on a schedule — rather than as a set of tasks that only happen when someone remembers or something goes wrong.

A maintenance arrangement works best when both sides know exactly where the line sits. The maintenance provider is usually responsible for the application code, its dependencies, and the fixes and changes agreed in scope. The business typically retains ownership of its own data, its hosting or cloud account, and any decisions about which third-party services the software depends on — even when the maintenance provider manages those services day to day on the business's behalf.

What falls outside the boundary matters just as much as what falls inside it. A well-written scope states explicitly whether it covers new features, third-party service outages, custom hardware, or work needed after a data-loss event caused by something outside the software itself. Business owners who skip this step often assume maintenance covers everything that could possibly go wrong with 'the app' — and are surprised later to find a specific problem was never included.

Maintenance stays manageable when it is reviewed on a fixed schedule rather than only when something breaks. A short recurring review — monthly for a business-critical system, quarterly for something lower-stakes — that looks at open support tickets, upcoming end-of-support dates for the software's core technologies, and any preventive work that has been deferred, keeps small issues from accumulating into a backlog no one has time to clear.

The output of that review does not need to be complicated: a short prioritised list, reviewed with whoever owns the budget, is usually enough. What matters is that the review happens on a calendar, not only in response to a support ticket — because the preventive work that saves the most cost in the long run is almost always the least urgent-looking item on the list.