What Is Software Maintenance?

Engineers group ongoing maintenance into four kinds. Corrective work fixes defects found after release, such as a report that miscalculates a total or a screen that crashes on one phone model. Adaptive work changes the software as its surroundings change: a payment gateway retires an API, a mobile OS drops an old permission model, or a tax rule changes.

Preventive work finds problems before they cause an outage: patching a library with a known vulnerability, adding monitoring, or tuning a query close to timing out. Improvement work, also called perfective, is polish too minor to hold up launch, such as a clearer error message or a faster report.

Consider a dispatch app. Its first year might bring a fix for a bug that double-counts fuel costs, an adaptive change when the map provider alters an API, and a security upgrade. All of it is maintenance. None of it is a new project.

A warranty is narrow by design. It covers defects that existed in the code at handover, for a fixed window, and ignores new operating system versions, browser cookie changes and processes that evolved after launch.

Maintenance is an ongoing, usually paid arrangement covering whatever keeps the software correct and current, including problems that appeared only because something outside the code changed. A new project adds capability the software never had, such as a reporting module, a second business location or an integration with a newer system. Maintenance keeps what exists working. A new project extends it.

Maintenance is mostly routine. A team, in-house or outsourced, watches uptime and error rates so problems are caught before customers report them, and applies security patches to the framework on a regular cycle. It also takes backups, proves they restore, reviews logs for slow-building problems and works through the ticket queue raised by staff and customers.

None of it is dramatic. That is why it slips when a business gets busy, and why well-run businesses put patching and backup checks on a calendar instead of waiting for a failure.

The provider usually owns the application code, its dependencies and the fixes agreed in scope, while the business keeps its data, hosting account and vendor choices. Ownership stays with the business even when the provider runs those services daily.

Exclusions matter equally. Scope should say whether it covers new features, third-party outages, custom hardware, or recovery after data loss caused by something outside the software. Owners who skip this step assume maintenance covers everything that could go wrong, then discover only after an outage that a specific problem was never included. Ask before you sign.

Hold a short recurring review, monthly for a business-critical system and quarterly for lower-stakes ones, covering open tickets, upcoming end-of-support dates for core technologies and deferred preventive work. Small issues stop piling up.

A short prioritised list, reviewed with whoever holds the budget, is usually enough, provided the review happens on a calendar and not only after a support ticket arrives. The preventive item that looks least urgent on the list is often the one that saves the most money over the following years.