Application maintenance contracts: what should be in an AMC

An annual maintenance contract for software is the document that decides whether the system you paid to build is still working in two years. Most AMCs we are asked to review are two pages of legal boilerplate around a monthly fee and the phrase "reasonable efforts". That is not a maintenance contract; it is an invoice schedule. A useful AMC states what is monitored, how fast someone responds by severity, how many hours are included and what they may be spent on, when dependencies are patched, what you receive in writing each month and, if the system includes AI, how quality and cost are checked as models and prompts change. This article walks through each clause, why it matters, and what to push back on.

Why the AMC scope matters more than the price

The fee is the easiest number to compare and the least informative. Two AMCs at the same monthly price can differ in whether anyone is watching the system at 2 a.m., whether a critical vulnerability gets patched this week or next quarter, and whether the ten hours you are paying for include the meeting where you ask what happened. Scope is where the value lives. Read the AMC as a list of promises and ask, for each one, how you would know if it had been broken.

Response and resolution by severity

Support SLA terms only mean something when they are tied to severity and to a cover window. Define three or four severities in plain language: the system is down or data is at risk; a core function is broken for many users; a function is degraded with a workaround; a cosmetic or low-impact issue. For each, state the response time (someone acknowledges and starts work), the resolution target (a fix or a mitigation) and the hours during which the clock runs. An eight-hour response during business hours is a different promise from a one-hour response around the clock, and the price should reflect it. Our own tiers are simple: Essential covers business hours IST with an eight-hour critical response, Standard is 24×5 with four hours, Enterprise is 24×7 with one hour and a named engineer. The full SLA question is treated in SLAs that mean something.

Included hours and what they may be spent on

Every AMC should state the number of engineering hours included each month, whether unused hours roll over and for how long, and the rate for hours beyond the allowance. Then it should say what the hours are for. Maintenance covers fixing defects, patching, monitoring response, small configuration changes and the monthly review. It does not cover new features, integrations to new systems or a redesign; those are change requests with their own estimate. The line between the two is the most common source of friction in a maintenance agreement, so write it down with examples. A three-line change to a validation rule is maintenance; a new report is a change request.

Patching cadence and dependency updates

A production application accumulates known vulnerabilities in its dependencies whether or not anyone is looking. The AMC should commit to a patching schedule: critical vulnerabilities within a stated number of days of disclosure, routine dependency updates monthly, framework and runtime upgrades planned quarterly, and automated scanning in the CI pipeline so nothing waits for a human to remember. NIST's guidance on enterprise patch management is a sensible reference for the risk-based approach. We cover the practical cadence in security patching for production applications.

Monitoring, alerting and who gets woken up

"We will respond to issues" is meaningless if the first person to notice an outage is your customer. The AMC should list what is monitored (uptime, error rate, latency, queue depth, disk, certificate expiry, and for AI systems token spend and answer quality), where alerts go, and who is on call in each cover window. It should also say who pays for the monitoring tooling and who owns the dashboards. If the vendor's monitoring lives in the vendor's account, you lose it when the contract ends; insist that it lives in yours.

Reporting: what arrives every month

A written monthly report is the mechanism that keeps a maintenance agreement honest. It should list incidents with severity, response and resolution times against the SLA; changes deployed with dates; hours used against the allowance; patches applied and outstanding; and the risks the engineer sees coming. For AI systems, add evaluation results for any prompt or model change, the cost per feature and any drift observed. A report you can read in ten minutes, every month, is worth more than a quarterly business review with slides.

For AI systems: evaluation and cost reviews

An application with an LLM or a model in it changes even when nobody deploys. Vendors update models, retrieval corpora drift, user behaviour shifts and a prompt that worked in March produces different answers in September. A traditional AMC has no clause for this. A modern one should require that every prompt, model or retrieval change is run against the evaluation suite before release, that the suite itself is maintained as new failure cases appear, and that inference cost is reviewed monthly against a budget with routing and caching adjusted when it drifts. The four cost levers are set out in cutting inference costs by a third. Our stance is that evals over demos applies after launch as much as before it.

Ownership, access and exit

The clause most often missing from an AMC is the one that matters when the relationship ends. The contract should state that the client owns all code, prompts, models, infrastructure and documentation; that repositories, cloud accounts and secrets are held in the client's name with the vendor as a contributor; and that on exit the vendor delivers a handover pack, rotates or removes their credentials and hands over the monitoring and runbooks. If any of that is missing, ask why. A vendor confident in its work has no reason to hold the keys.

A worked example

A university that had modernised its ERP without a rewrite came to the end of the build with a system that worked and no plan for keeping it that way. The original proposal had a one-line "support available" clause. We replaced it with an AMC that named the severities, put critical response at business hours with a defined clock, allocated a monthly hour budget with rollover for one quarter, committed to monthly dependency patching with scanning in CI, moved monitoring into the university's own cloud account, and added a monthly report to the registrar's office. Two things changed in practice: the IT team stopped emailing individual engineers, and the finance office could see for the first time what the money bought each month. The engagement is described in university ERP modernised without a rewrite.

Team and timeline

An AMC with us takes the form of a Care Plan: Essential at $1,000 a month (business hours IST, eight-hour critical response, 10 hours), Standard at $2,500 (24×5, four-hour response, 25 hours) or Enterprise at $5,250 (24×7, one-hour response, 60 hours and a named engineer), with INR pricing on the pricing page. For a system we built, the plan starts the day hypercare ends. For a system built elsewhere, we run a takeover audit first, usually one to two weeks, so the contract is signed against a known baseline. Systems that need more than maintenance, such as an ageing platform that needs structural work, are better served by legacy-to-AI modernisation with the Care Plan following.

Before you start: a checklist

• Severity definitions written in plain language with examples
• Response and resolution times per severity, with cover hours
• Included hours, rollover rules and the rate for extra work
• A written line between maintenance and change requests
• Patching cadence for critical, routine and framework updates
• Monitoring list, alert routing and ownership of dashboards
• Monthly report contents agreed and a named reader on your side
• Ownership, access and exit clauses reviewed by your legal team

Questions clients ask

• Can unused hours roll over? Yes, for a bounded period; a quarter is typical. Indefinite rollover turns the plan into a prepaid bank and defeats the point of predictable capacity.
• What if we need more hours one month? The AMC states the overage rate in advance and requires approval before it is used.
• Do we need 24×7 cover? Only if the system's users or its revenue run outside business hours. Many internal tools are fine on Essential.
• Can the AMC be cancelled? Yes, with notice. The exit clause matters more than the notice period.
• Does the AMC cover AI model upgrades? Evaluating and switching models is within scope; building new AI features is a change request.

Related reading

What a Care Plan should cost and what it should include, Taking over a system you didn't build and Total cost of ownership for AI systems cover the questions that come next.

An AMC is a list of promises with clocks attached; if you cannot tell when one has been broken, it is not in the contract.