Third-party application maintenance: what your TMA contract must cover

Third-party application maintenance (TMA) means entrusting an external provider with the maintenance of an application that is already in production. A delivered application keeps costing money: incidents, security updates, business changes. A good TMA contract states who does what, within what time frame, at what price, and how to exit. Here is what it must contain.

TMA, MCO, application maintenance: what does each term cover?

Application maintenance concerns the software itself: incident analysis, fixes, updates, testing and adaptations. TMA (see the definition in our glossary) refers to the case where a third-party provider takes on all or part of it. MCO (maintien en conditions opérationnelles, i.e. keeping systems in operational condition) is broader: it includes monitoring, backups, certificates and infrastructure.

The distinction matters when you sign. An application maintenance contract does not automatically cover hosting, backups or operating systems. If the provider is responsible for them, it must be spelled out in black and white.

An IT TMA contract must therefore start with an inventory: applications, environments (development, staging, production), code repositories, databases, cloud services, third-party APIs. "Maintenance of the application" without an inventory is too vague a wording to be enforceable.

What are the 4 types of maintenance and what share of the budget do they represent?

An IT maintenance contract distinguishes four kinds of work. Most guides, such as those from Hydatis or Kern IT, keep three (corrective, evolutive, preventive), and the fourth, adaptive, is often attached to one of the others.

What split should you aim for?

There is no universal split, and we know of no reliable published statistic that claims otherwise. Everything depends on the age, the code quality and the criticality of the application.

Our scoping grid, to be adjusted after an audit, looks like this: 25 to 40% for corrective, 15 to 25% for preventive and security, 10 to 20% for adaptive, 25 to 45% for evolutive. An old, poorly tested application tips the budget toward corrective work.

At Fragments Studio, we defend a simple position: preventive work is the line item most often sacrificed, because it produces no visible feature. Yet its absence raises the cost of every subsequent fix and every subsequent change. This is the mechanism described in our article on technical debt: diagnose, estimate and pay it down.

Why can't security patches wait?

Recent vulnerabilities hit very different stacks, including the most widely used ones:

• Next.js, March 2025: the CVE-2025-29927 flaw made it possible to bypass middleware access controls with a single HTTP header.
• React, December 2025: React2Shell (CVE-2025-55182), rated 10 out of 10, enabled remote code execution on servers using React Server Components, including Next.js with the App Router. It was exploited within days of disclosure, and three new flaws were published a week later, which required a second deployment.
• npm, September then November 2025: the Shai-Hulud worm compromised several hundred packages to steal secrets from developers and CI pipelines (Datadog analysis).
• Linux, March 2024: the backdoor slipped into xz-utils was a reminder that an inconspicuous system component can be targeted too.

Between the release of a patch and the first attacks, sometimes only a few hours pass. An application whose dependencies have not moved in a year cannot be fixed in an evening: you first have to catch up on versions, then test, then deploy. Preventive work exists precisely to stay a few versions away at most, so that the urgent patch is a routine update.

So require in the contract:

• vulnerability monitoring on all dependencies, with tools such as Dependabot or Renovate and vendor security advisories;
• a maximum deployment time for critical patches, for example 24 to 72 hours depending on the application's exposure;
• a deployment pipeline able to ship out of cycle, without waiting for the next planned release;
• written tracking: vulnerabilities detected, applications affected, fix date or justification if the patch is postponed.

What should your TMA contract include: SLA, response times, on-call, monitoring?

An effective TMA contract sets measurable commitments on four topics: incident criticality, response times, coverage hours and monitoring.

Which criticality levels and which SLAs?

An SLA (Service Level Agreement, see the glossary) is the provider's written commitment on time frames and a level of service. A four-level classification remains the most readable:

• P1 (blocking): the service is unavailable or an essential function is unusable.
• P2 (major): significant degradation, limited workaround.
• P3 (minor): anomaly with no critical impact.
• P4 (request): question or non-urgent improvement.

Each level gets its own time frames. As a benchmark, you often see acknowledgment within 2 to 4 hours for a P1 and 8 to 24 hours for a P2. These values depend on the actual criticality of your service and on your budget.

Insist on distinguishing the time to acknowledge, to diagnose, to work around and to restore. Be wary of a guaranteed "resolution time" when the provider does not control all the dependencies: a restoration time is more honest.

Do you need on-call coverage?

On-call coverage is a standby arrangement that allows intervention outside business hours. The contract must specify the days and hours covered, the incidents that trigger it, the emergency channel, the callback time and the rate for night or weekend interventions.

24/7 on-call coverage only has value if incident detection actually exists. Without automatic alerting, the standby is useless: you find out about the outage from your users.

What monitoring and what reports?

Monitoring must cover availability, response times, application errors, processing queues, certificates, backups and security alerts. Our article on NestJS Observe and native observability shows what this looks like in practice on the code side.

Add a monthly report: incidents by criticality, actual response times, recurring incidents, change credit consumed, preventive actions carried out, vulnerabilities detected and the time taken to fix each one. It is your dashboard for deciding whether or not to renew.

Which clauses on testing, security and access?

The contract must also state who writes the tests, who signs off acceptance testing, who authorizes production releases and how rollbacks are handled. On the security side, require named accounts, strong authentication, traceability of interventions and revocation of access at the end of the contract.

How much does TMA cost: fixed fee, hour credits or time and materials?

There is no standard rate. According to Castelis, the cost depends on the size and complexity of the application, its technical condition, the expected volume of incidents and the level of service required.

For orders of magnitude, GoLive Software cites roughly €300 to €450 per day for nearshore and €500 to €750 for a French company, depending on the profile. Fixed fees published by providers range from a few hundred euros per month for a low support volume to several thousand for a critical application.

Our advice: corrective and preventive work lend themselves well to a fixed fee, because their volume can be estimated from the existing system. Evolutive work depends on your decisions and is better managed with hour credits. Combining the two is the most common formula.

To compare offers, ask for separate pricing for the initial takeover, the audit, recurring maintenance, changes, on-call coverage, monitoring tools and reversibility. A very low price without a detailed scope almost always hides exclusions or a lack of commitment on response times.

How do you switch maintenance providers without risk?

Reversibility is the ability to hand the application over to another team without depending on the outgoing provider. It is negotiated at signing, not at the time of departure.

The reversibility plan is its reference document. At a minimum, it must list:

• the complete source code and its version history;
• the deployment scripts and configuration files;
• the database schemas and architecture documentation;
• the accounts, access rights and secrets, handed over through a secure procedure;
• the automated tests, the backups and the incident history;
• a transfer period with its duration, deliverables and price.

Ask four questions before signing. Who owns the cloud accounts and the domain names? Do the code repositories belong to you? Is the documentation kept up to date during the contract? Are transfer costs capped?

A clause that is never tested remains theoretical. Every year, plan a backup restoration, a documentation review and a redeployment to a blank environment. If you inherit a messy existing system, our article on taking over a poorly developed project details the steps to follow.

Frequently asked questions

What is third-party application maintenance? Third-party application maintenance is when an external provider takes charge of maintaining an application. It covers fixes, changes and prevention, under a contract that specifies scope, time frames and rates.

What is the difference between TMA and MCO? TMA focuses on the software: bugs, changes, updates. MCO also covers operations: monitoring, backups, certificates, infrastructure. A TMA can include MCO, but it is not automatic.

How do you choose between a fixed fee, hour credits and time and materials? Choose a fixed fee for corrective and preventive work on a stable application. Take hour credits for irregular changes. Reserve time and materials for active projects that need quick reinforcement. Many contracts combine a base fixed fee with a change credit.

Why is reversibility important in a maintenance contract? Without it, you depend on a single provider to understand, deploy and evolve your application. Reversibility guarantees that the code, the documentation and the access come back to you, and makes competition possible at each renewal.

Conclusion

A third-party application maintenance contract is not just a fixed fee or a number of days. It describes a scope, four types of work, criticality levels, SLAs, on-call coverage, monitoring, a billing model and an organized exit.

Our recommendation: precede the signing with a technical audit (code condition, debt, documentation, incident frequency). The maintenance budget then becomes a quantified decision, not a fixed fee chosen blindly.

Take over or frame the maintenance of your application

If your application runs without a safety net or if your current provider no longer meets its commitments, we can audit the existing system and structure a clear contract.

• Discover our project takeover offer to audit, stabilize and take over an existing application.
• For monitoring, deployments and infrastructure, see our cloud and DevOps expertise.
• If your project involves an internal tool that needs to evolve, our custom development team can support you.
• Get an initial estimate with our project estimator.
• Or let's talk directly.