An application in production continues to evolve even when no functionality is added. Browsers, systems, libraries, certificates, volumes, and third-party services change. Users encounter unforeseen cases, and security risks are reassessed.
Application maintenance organizes this continuity. It is not limited to a stock of hours or an email address. It defines the scope, responsibilities, priorities, response times, capacity for evolution, and how to measure the service.
This guide helps to structure the system. It does not constitute a legal model; the clauses must be adapted to the context and approved by the parties.
TMA, support, maintenance and IT outsourcing: distinguishing the services
Corrective maintenance deals with anomalies. Preventive maintenance reduces risks before an incident: updates, reviews, backup tests. Evolutionary maintenance modifies the product. Support assists users or administrators. Outsourcing covers the operation of infrastructure and technical services.
TMA, or third-party application maintenance, can encompass several of these activities when they are entrusted to a provider. The contract must specify what is included. A coding error, incorrect data, server overload, and a usage question do not require the same skill or the same level of commitment.
Define the scope before the deadlines
The scope includes applications, versions, environments, interfaces, scheduled processes, third-party services, and hours of use. It specifies who manages the cloud, the database, certificates, backups, DNS, the user workstation, and external providers.
It is also necessary to list the exclusions: undocumented system, unsupported component, access not provided, direct modification by a third party, or absent test environment. An exclusion must lead to a mitigation plan, not become a permanent excuse.
Build a priority matrix
A priority is determined by the impact, the extent, and the existence of a workaround. A generic example:
| Level | Situation | Example | Initial goal |
|---|---|---|---|
| P1 review | Vital service or function unavailable, data/security risk | inability to process orders | immediate support and incident unit according to coverage |
| Major P2 | Important function degraded, limited bypass | import blocked for a team | priority diagnosis |
| P3 standard | Localized anomaly, acceptable bypass | display error or secondary rule | planning in maintenance |
| Minor P4 | slight discomfort or request for improvement | wording, comfort, optimization | evolving backlog |
The qualification must be able to be reviewed after diagnosis. A symptom visible to only one user can reveal a global data defect; an impressive alert may have no impact.
Do not confuse the deadlines
The care start time corresponds to the beginning of treatment. The diagnosis time aims at an initial understanding. The recovery time brings the service back to an acceptable level, sometimes through a workaround. The resolution time provides the definitive fix.
Promising a fixed resolution for any anomaly is rarely realistic, as the cause may depend on a third party or require a migration. A more robust commitment focuses on mobilization, communication, recovery, and escalation.
Set the coverage hours
An application used from Monday to Friday does not automatically require 24/7 on-call duty. However, nighttime processing, international users, or campaigns can create critical periods outside of office hours.
The cover must distinguish:
- reception and recording of requests;
- automatic supervision;
- human care;
- technical intervention;
- availability of business decision-makers.
On-call duty without access, documentation, monitoring, or decision-making authority offers little protection.
Organize the entry channel and the climb
Each request must receive an identifier, a priority, an environment, an impact, reproduction details, and a requester. Emergencies use a specific channel; an email sent at night should not be assumed to trigger on-call duty if this mechanism is not agreed upon.
The precise escalation that is contacted when the incident goes beyond the scope, involves a supplier, requires a business decision, or becomes a crisis. The contact details and roles are reviewed regularly.
The diagram represents seven successive steps. The restoration of the service does not close the cycle: analysis and prevention turn each incident into measurable improvement.
- Detect: detect the anomaly through supervision, logs, or a user report.
- Qualify: measure the impact, the extent, the criticality, and the associated risks.
- Contains: limit the spread and protect the data or pathways still available.
- Restore: restore the service to an acceptable level, if necessary through a controlled bypass.
- Analyze: identify the technical and organizational causes based on the facts.
- To prevent: add fixes, alerts, tests, or procedures that reduce recurrence.
- Improve: monitor actions and adjust the maintenance setup during the service review.
Plan for a capacity, not just a daily rate
Routine maintenance benefits from a reserved capacity. It can take the form of a flat fee, a number of monthly days, a minimum consumption, or a budget based on actual expenses with a ceiling. Each model distributes the risk of resource availability differently.
The budget must distinguish:
- service and governance foundation;
- supervision and on-call duty;
- current patch;
- preventive updates;
- planned developments;
- exceptional construction sites.
Mixing everything into a single envelope often leads to sacrificing updates in favor of visible requests.
Maintain a version policy
The contract describes how dependencies, vulnerabilities, and end-of-support are monitored. Minor updates are tested regularly; major versions are subject to study and a planned project.
The goal is to avoid the alternation between stagnation and urgent migration. A preventive budget smooths the effort and maintains the possibility of evolving.
Measure a useful service
The number of closed tickets is not enough. The indicators may include:
- availability of critical paths;
- detection delay;
- timeframe for care and recovery by priority;
- reopening rate;
- recurring incidents;
- Changes that caused a failure.
- Age of the security backlog.
- corrective, preventive, and evolutionary consumption;
- satisfaction of the interlocutors.
The measures must be interpreted. An increase in tickets may reflect better detection, not a deterioration.
Organize service reviews
A monthly or quarterly review examines incidents, capacity, risks, releases, and the roadmap. It identifies recurring causes and decides on preventive actions. Budget matters are discussed with evidence, not only during an emergency.
The report assigns each action, its deadline, and its closure criterion. Commitment gaps are analyzed to improve the process.
Prepare the exit from the entrance
The system must include reversibility: documentation, client access, ticket export, account ownership, knowledge transfer, and secret rotation. This preparation protects the client and also improves daily quality.
A contract aligned with the actual criticality
Perfect availability does not exist and every requirement has a cost in terms of architecture, tooling, and organization. A good contract makes this compromise explicit. It defines what is critical, how the service is restored, and how risks are reduced over time.
Partitech provides corrective and evolutionary maintenance, hosting, IT management, and, according to needs, on-call support. We can take over a project developed by a third party and build a service framework adapted to its real uses.
To go further in the approach, consult the method for resume the maintenance of an existing application, prepare the continuity and resumption of activity and learn to calculate the TCO of an application over five years. Also discover the offer Maintenance, development and hosting from Partitech.
Official reference
Reference accessed on August 17, 2026: