Software Maintenance and Support Services: How They Work, With Prices
Every guide on software maintenance and support explains the principle and stops before the one number you came for. Here is how it works, the distinctions that matter in a contract (support vs maintenance, TMA, MCO), and our rates.
Aug 17, 2026
Every guide on software maintenance and support services 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 are software maintenance and support services?
- What is the difference between software support and maintenance?
- How does a maintenance contract work?
- How is a maintenance contract set up?
- 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 do software maintenance and support services cost?
- What you actually sign: response times, tickets and reviews
- The most common case: the Excel macro nobody maintains
- When maintenance is the wrong answer
What are software maintenance and support services?
Software maintenance and support services keep an application working, and changing, after launch. A provider takes on a recurring contract to answer users and handle incidents (support) and to fix, update and improve the code (maintenance), with response-time commitments graded by severity.
When the provider is not the one that built the application, the French call it third-party application maintenance: tierce maintenance applicative, or TMA. It 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.
What is the difference between software support and maintenance?
The two words get used as if they meant the same thing. In a contract they do not, and the gap between them is where an application quietly ages.
| Support | Maintenance | |
|---|---|---|
| What it does | Answers users, triages incidents, gets someone working again | Changes the code: fixes, version and dependency updates, new features |
| Touches the code? | Rarely | Always |
| Trigger | A user or an alert | An incident, a schedule or a business request |
| What it prevents | A blocked user waiting for days | An application nobody can change safely in two years |
A support-only contract keeps the lights on: someone answers, someone restarts what fell over. Meanwhile the dependencies go out of support and every future change gets slower. A maintenance-only contract has the opposite gap: the code stays healthy, but a user who is stuck has nobody to ask. What you want covers both, from the same team, so that the person who hears about a problem is the person who can fix it. That is how our contracts work.
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.
How is a maintenance contract set up?
Four phases. The first is the one suppliers are least keen to bill for, and it is the one that decides everything after it.
1. The takeover. We read the code, the infrastructure and the incident history. By the end we know what breaks, how often, and how many days a month the application will actually need. That is the code audit at €2,500. Without this phase, the monthly volume written into the contract is a guess.
2. Getting it under control. The code goes into version control if it is not already there. Deployment is documented and made repeatable. Access is recovered and put back in your name. Plenty of applications arrive with none of that, and it blocks maintenance more often than the code itself does.
3. The run. The contract starts: fixes, changes, regular reviews. Response commitments apply from here and not before, because they are made against an application we know.
4. Reversibility. This is the phase nobody talks about. At the end of the contract you leave with the code, the documentation, the access and the record of decisions, in a state someone else can pick up. We write it into the contract.
That last phase is the best test of a maintenance supplier. A contract that does not plan for your departure puts you straight back into the situation that made you look for one: an application you cannot hand to anybody.
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 do software maintenance and support services cost?
This is the question none of the guides ranking for this topic answer. Here are our numbers.
| Service | Price | In US dollars (approx.) |
|---|---|---|
| Upfront code audit | €2,500 fixed | $2,900 |
| Maintenance and support, half a day a month | from €400 per month | from $470 per month |
| Maintenance and support, two days a month | €1,600 per month | $1,850 per month |
| Additional day | €800 | $930 |
US clients are invoiced in US dollars.
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.
What you actually sign: response times, tickets and reviews
The price says nothing about the commitment. Here is what a contract with us contains, and what it does not.
Response times, by severity. Three levels, not one.
| Severity | Example | First response |
|---|---|---|
| Blocking | Production is down, nobody can invoice | 4 working hours |
| Major | A core function is degraded, a workaround exists | 1 working day |
| Minor | Annoying, no immediate consequence | Next review |
Note the wording: first response, not resolution. A supplier who commits to a resolution time before seeing the problem is committing to something outside their control. We commit to starting, to telling you what we find, and to giving you a fix estimate at that point.
One traceable channel. Requests arrive in the same place and carry a number. No fix decided in a chat thread, because six months later nobody can work out why a line changed.
A written monthly review. What was done, what it consumed from the day volume, what is coming, and the risks we see building. With notes, because a review that leaves no record did not happen.
What we do not promise. No 24/7 on-call: we are a small team, and a night-time commitment we could not honour is worth nothing. No response time on a scope we have not audited. No unlimited monthly retainer, because unlimited always gets paid for somewhere else, usually in quality.
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.