Third-Party Application Maintenance (TMA): The Guide, With Prices
Every guide on application maintenance explains the principle and stops before the one number you came for. Here is how it works, the distinctions that matter in a contract, and our rates.
Aug 17, 2026
Every French guide on third-party application maintenance says the same things: the definition, the types of maintenance, the benefits, a contact form. None answers what a director actually asks: what does it cost, and what am I committing to.
We take over applications and maintain them. Here is how it really works, the distinctions that change something in a contract, our rates, and the cases where maintenance is the wrong answer.
Contents
- What is third-party application maintenance?
- How does a maintenance contract work?
- What are the three types of software maintenance?
- What is the difference between TMA and TME?
- What is the difference between TMA and MCO?
- How much does application maintenance cost?
- The most common case: the Excel macro nobody maintains
- When maintenance is the wrong answer
What is third-party application maintenance?
Third-party application maintenance — tierce maintenance applicative, or TMA, in French practice — means handing maintenance of an application to an external provider who is not the one that built it. That is the whole meaning of "third-party": neither your team, nor the original vendor.
The provider takes on fixes, changes and availability, under a recurring contract with response-time commitments.
The reason this market exists is almost always the same: the application works, but the person who wrote it is gone. A freelancer who stopped replying, an agency the relationship ended with, a technical co-founder who left, or a company acquired along with its in-house software. The tool keeps running and nobody can change it safely.
How does a maintenance contract work?
A readable contract has five parts. If one is missing, you find out which at the first incident.
- The scope, in writing. Which applications, which environments, which integrations. What is not named is not covered.
- The reporting channel. Where a problem gets raised, and who is allowed to raise one.
- Response commitments graded by severity. A blocked checkout and a typo do not deserve the same response time. A contract with a single blanket response time is a badly written contract.
- A monthly allocation of days for changes, and what happens when it is not used.
- A regular review, looking at what was done and what is coming.
One thing we insist on: maintenance starts with a takeover. We will not commit to response times on an application we have not read. That means a code audit first, then the maintenance contract, with a scope built on facts rather than an estimate.
What are the three types of software maintenance?
Three are standard, and many contracts add a fourth.
| Type | What it covers | Trigger |
|---|---|---|
| Corrective | Fixing what is broken | An incident |
| Evolutive | Adding or changing features | A business request |
| Preventive | Acting before failure: version upgrades, dependencies, backups, monitoring | A schedule |
| Adaptive | Adapting to a changed technical or regulatory environment | An external change |
Preventive is the one that gets cut first and the one that costs most to neglect. An unsupported dependency does not cause an incident the day support ends. It simply makes the next fix far longer, six months later, when three major version upgrades have to happen before anyone can touch a line.
What is the difference between TMA and TME?
TME, third-party evolutive maintenance, covers changes only: adding features, moving the product forward.
TMA is broader and includes corrective work, so getting things running again when something breaks.
In practice, many contracts titled TMA cover both. The useful consequence: read the scope, not the acronym. The question is not "is this TMA or TME" but "who fixes production on a Friday evening, and within what time".
What is the difference between TMA and MCO?
MCO, maintien en condition opérationnelle, aims to keep a system in working order. It is weighted toward infrastructure: monitoring, operations, backups, availability.
TMA is about the application code: fixing and evolving the application itself.
They overlap on availability, which is where the misunderstandings start. A perfectly monitored server does not prevent a functional regression, and impeccable code does not survive a database with no backups. On a small scope the same provider often does both, which is simpler than making two contracts talk to each other mid-incident.
How much does application maintenance cost?
This is the question none of the guides ranking for this topic answer. Here are our numbers.
| Service | Price |
|---|---|
| Upfront code audit | €2,500 fixed |
| Maintenance | from €1,600 per month (2 days) |
| Additional day | €800 |
The monthly volume is set from the real size and condition of the application, established during the audit rather than guessed.
The useful benchmark, if you are comparing quotes: maintenance is counted in days per month, not as a percentage of the original build cost. A percentage has no relationship to actual workload — an application that was expensive to build but is clean needs less upkeep than a cheap one with no tests. What moves the price is test coverage, the age of the dependencies, and how automated deployment is.
The most common case: the Excel macro nobody maintains
Not the request you would expect, but the most frequent: an Excel file with VBA macros, written years ago by someone who has left, that part of the business depends on. Invoicing, pricing, production planning.
Nobody dares touch it. It runs on one machine. It exists in exactly one copy on a network share, and its backup is a dated file sitting next to it.
It is a perfect maintenance candidate, with one caveat: the right answer is usually to stabilise first, replace second. Secure what exists, put it under version control, document the business rules buried in it — and only then decide whether to replace it with real software. Maintaining a VBA file indefinitely is not a strategy, but rewriting it in a panic after an outage is worse.
When maintenance is the wrong answer
We would rather say this before signing.
If the application serves one person, a maintenance contract is disproportionate. A monthly fee for a tool with no consequences when it breaks costs more than the risk it covers.
If you do not own the source code, no third party can legally work on it. That is the first thing to check, before any technical discussion, and it blocks more engagements than people expect.
If the application is being replaced within six months, pay for stabilisation, not a recurring contract. Maintenance on a product already condemned funds upkeep that gets thrown away.
If your need is really infrastructure, you want MCO, not TMA. The difference is above, and picking the wrong contract costs a quarter.
If you recognise your situation, the entry point is always the same: a fixed-price code audit at €2,500. It says what is sound, what needs work, and what maintenance actually amounts to in days. If our conclusion is that you do not need a maintenance contract, we write that down and you keep the report.