Skip to main content
  • Maintenance
  • Contracts

Application maintenance: what it really costs, and what you think you are paying for

Maintenance contracts are rarely compared on the right metric. Ticket counts say nothing; restoration time and accumulated debt say everything. How to read a maintenance proposal.

· 4 min read · AzerOps

Third-party application maintenance is the worst-compared contract on the market. Proposals are presented in ticket counts or man-days, two units that do not measure what you care about: the time during which your application is not doing what it should.

Ticket counts measure nothing

A provider handling two hundred tickets a month is not better than one handling thirty. They may simply be working on a less stable application, or splitting work more finely. Worse, counting tickets creates a perverse incentive: it becomes profitable to close fast and let issues come back.

The two indicators that matter are response time — how long before a human looks at your incident — and restoration time — how long before the service is normal again. Both must be contractual, differentiated by severity, and measured on data you can verify.

The three costs proposals do not show

The cost of single-person dependency. Many maintenance contracts rest in practice on one consultant who knows your application. While they are there, everything is fine. Their departure costs you three to six months of takeover, and that cost appears nowhere in the monthly price. Require two trained people on your file, and have it written down.

The cost of accumulated debt. A provider paid per fix has no interest in reducing technical debt. They have an interest in fixing quickly and moving to the next ticket. After three years the application is more fragile than at the start and you never saw it coming. Ask for a monthly debt report: what was created, what was repaid.

The cost of non-documentation. If your provider does not document as they go, you are paying every month for knowledge that stays with them. It is a lock-in mechanism, often unintentional, sometimes not.

How to structure an enhancement allowance

Most contracts mix corrective and adaptive work in a single allowance. That is a mistake: corrective work is imposed, adaptive work is chosen. When both share a budget, a bad month of incidents eats the enhancements and nobody notices until the quarterly review.

Separate them. Corrective work belongs under a time commitment, not a day quota. Adaptive work belongs in a day allowance, poolable across the quarter to absorb quiet months.

What to ask before signing

  • Response and restoration times, by severity, with the written definition of each level.
  • The number of people trained on your file, by name.
  • The contents of the monthly report, with a real anonymised example.
  • The escalation procedure: who to call, on what number, at what hours.
  • Reversibility conditions: notice period, exit pack contents, assistance duration.
  • What happens if the enhancement allowance is not consumed.

The right order of magnitude

A maintenance contract on a medium-sized business application generally sits between one and three per cent of the application's replacement value per month. Below that, the provider cannot keep two competent people available. Above it, you are probably funding a dedicated team you do not need.

The question to ask is not "what does this maintenance contract cost", but "what would a week of downtime on this application cost". The ratio between those two numbers tells you whether you are overpaying or under-insuring a risk.

Related articles

Twenty minutes is enough to know whether we are useful

No sales deck. You describe the need, we say whether it is in scope, at what price and on what timeline. If it is not for us, we say so during the call.