Software maintenance: which model should you choose for your business?

Your team relies on an application to manage orders, customers, bookings or internal tasks, but no one is sure what would happen if it stopped working or an integration changed. Waiting for a problem to arise may seem sufficient; arranging regular reviews may seem excessive. The decision depends on which part of your operations the software supports and how much room you have to react.

In this guide, you will compare three software maintenance approaches: reactive, preventive and evolutionary. By the end, you will be able to decide which one best suits your situation, what scope should be defined and when maintenance is no longer sufficient on its own.

The decision: fix it when it fails, review it beforehand or improve it with a plan?

Maintenance does not have the same purpose for every system. An internal tool used occasionally and an application that centralises daily activity do not require the same level of oversight.

Before choosing, separate three questions:

• Objective: what do you need to protect or improve? For example, the continuity of a critical task, data reliability or the ability to adapt the system to a new process.
• Scope: which elements are included in the review? Code, servers, backups, third-party accounts, integrations, data, documentation and training are separate elements.
• Solution: how will those tasks be carried out? The answer may involve on-demand support, scheduled reviews or an evolution plan.

This distinction prevents you from commissioning “maintenance” as an ambiguous label. An agreement may include fixes but not new features. It may also cover technical updates but not changes to processes or integrations. It is best to put this in writing before an issue arises.

Three comparable alternatives

1. Reactive maintenance: intervene when a problem appears

Under this model, support is requested when a fault, one-off need or unexpected behaviour is detected. It is an option focused on resolving specific situations, rather than reviewing the system continuously.

It may be suitable if the tool has limited use, does not manage sensitive operations or you have enough leeway to stop and investigate before acting. It can also be useful when you are still gathering information about a legacy system and do not know which parts need attention.

Its main trade-off is clear: you reduce scheduled work, but accept that some problems will be discovered only once they are already affecting use. In addition, an issue may first require an understanding of access, dependencies and previous changes before a fix can be applied.

2. Preventive maintenance: review to reduce operational uncertainty

Preventive maintenance organises regular checks of the elements that support the software. Depending on the system, it may cover updates, review of logged errors, technical dependencies, backups, access and integrations with external services.

Its purpose is not to guarantee that there will never be incidents. It aims to identify matters worth reviewing before they become a business interruption. It is more appropriate when the software is used frequently, holds relevant information or depends on external tools that may change.

In return, it requires agreement on priorities and responsibilities. There is no point in reviewing everything with the same level of depth: the flows whose interruption would have the greatest impact must be identified first. For example, in a hypothetical case, checking the order creation flow may be more urgent than refining a query screen used sporadically.

3. Evolutionary maintenance: maintain the system and adapt it to the business

Evolutionary maintenance introduces planned changes so that the software continues to meet new needs: a business rule, a new user profile, a different report or a connection to another tool.

It does not replace corrective or preventive maintenance. It complements them. Fixing an error restores expected behaviour; evolving the system changes it to meet a need that did not previously exist or has changed.

This approach makes sense if your company’s processes are changing and the software needs to keep pace. It requires more definition than a one-off fix: who will use the new feature, what data they need, which exceptions must be considered and how you will verify that the change achieves its purpose.

Criteria matrix for comparing the models

The table does not identify a universal winner. In many cases, a combination makes more sense than an exclusive choice: a preventive foundation for day-to-day operation and an evolutionary allowance or plan for approved changes.

When to choose each option

Choose a reactive approach if the software is not critical and you know its limits

It may be enough when a temporary outage does not block operations and the system has few dependencies. Even so, retain a basic record of access, responsible parties and the technology used. Without this information, even a small intervention may begin with a discovery phase.

Do not confuse this model with leaving the system without an owner. On-demand support still requires knowing who can authorise changes, where the accounts are and how a fix is validated.

Choose preventive maintenance if an incident affects your day-to-day operations

It is a reasonable option when several people depend on the tool, when integrations exist or when data and permissions require attention. The key is to design a proportionate scope: what is reviewed, how often, which signals are logged and which decisions require your approval.

Also define what happens outside the reviews. A change request should not automatically be treated as a fix; its impact on other screens, data or processes may be different.

Add evolutionary maintenance if your way of working is changing

If parallel spreadsheets appear, manual steps are used to compensate for limitations or users make recurring requests, the issue may not be maintenance alone. The software may need to evolve.

Before adding a feature, state its objective in one specific sentence. Then define the scope: user, action, data, permissions, error cases and acceptance criteria. This will help you distinguish a necessary improvement from an idea that is best postponed.

Edge cases: when the decision is not only about maintenance

There are situations in which choosing between reactive, preventive or evolutionary maintenance does not resolve the main issue.

You do not have access to the code, servers or required accounts. Before committing to maintenance, you need to check which assets the company controls, who can grant permissions and whether enough information exists to intervene without creating new dependencies.

The system works, but the process has changed completely. Adding patches to a tool designed for different operations can increase complexity. It is best first to review the current objective and assess whether a limited evolution still makes sense or whether the solution needs to be reconsidered.

There is an incident affecting data, access or essential activity. The priority becomes containing the impact and verifying the scope before introducing rushed changes. Decisions concerning communications, applicable obligations or information recovery require validation by the responsible people and, where appropriate, specialist advice.

You do not know what the software actually does. In a legacy system, the first need may be to document functions, dependencies, accounts and critical flows. Promising broad maintenance without this initial map would leave too many unknowns unresolved.

Conclusion: the right model depends on what you cannot afford to lose

Reactive maintenance is suitable when you can accommodate an on-demand response. Preventive maintenance provides regular review when the software supports relevant tasks. Evolutionary maintenance is needed when the tool must adapt to changes in processes, users or business rules.

The best decision is not to choose the broadest model, but to define what must be maintained, what must change and what responsibilities each party has. If you need to assess the condition of an existing application or define a maintenance and evolution plan, you can tell AVSISTEC about your custom software project.