What an AMC should cover, and the clauses to refuse

Software is bought once and maintained for years, so over a five-year life the maintenance contract is often the larger number. It usually gets a fraction of the scrutiny the delivery quote gets, partly because it is signed when everyone is tired and the system is finally working.

Here is what it should say.

The distinction everything else depends on

**A bug is the software not doing what was agreed. A change request is the agreement changing.**

Bugs are fixed at no cost, within the support window. Changes are quoted. That is standard and reasonable.

The disputes happen in the gap between them, so the contract should define the gap rather than leaving it to good will. Two cases worth naming explicitly:

• **A rule changed outside your control.** A tax rate moves, a board changes its result format, a payment gateway alters its API. This is neither party's fault. Decide in advance whether it is covered, capped, or billed — the worst outcome is discovering there was no agreement during the week it becomes urgent.
• **It worked before and now it does not.** If nothing in the requirement changed, that is a bug, even if the cause was a server update. Say so in the contract.

Response times, stated properly

"We will respond promptly" means nothing. A usable clause separates severity:

• **System unavailable, or data at risk** — response within a stated number of working hours, work continues until resolved
• **A core function broken with no workaround** — response within one working day
• **A defect with a workaround, or something cosmetic** — response within a few working days, fix in the next scheduled release

Two details matter more than the numbers. **Response is not resolution** — a clause promising a four-hour response is promising a reply, and should say what happens next. And **working hours must be defined**, including whether that covers admission week, results day, or year-end, which is precisely when institutional software fails and precisely when a standard support window is closed.

What should be included and often is not

• **Security patches** for the framework, libraries and server. This is the single most important line and the most frequently omitted. An unmaintained system becomes a liability on a schedule nobody controls.
• **Version upgrades** of the underlying platform when it reaches end of life.
• **Backup verification.** Not "backups are taken" — a periodic test restore. An untested backup is not a backup.
• **Uptime monitoring**, with the vendor finding out before you do.
• **A named contact and an escalation path**, so a problem does not depend on one person's phone.
• **A fixed number of support hours** for small changes, so trivial requests do not each become a quotation.

Clauses worth pushing back on

**Automatic renewal with an uncapped increase.** Renewal is fine. Uncapped is not. Tie the increase to something, or state it.

**Support conditional on hosting with the vendor.** These are two separate services and bundling them is a lock-in mechanism, not a technical requirement.

**Ownership of anything built during the AMC.** If you pay for a change, you own it on the same terms as the original system. Some contracts quietly carve this out.

**A cost to leave.** Getting your own data and code out at the end should be routine work, not a penalty. If the exit cost is unusual, that is the most informative number in the document.

**Any reference to "best efforts" without a definition.** It is not an obligation.

What it should cost

There is no single correct figure, but a useful frame: annual maintenance is commonly a percentage of the delivery cost, and something in the region of 15 to 20 percent is a normal shape for an actively maintained system.

Be suspicious in both directions. Very cheap usually means nothing is actually included and every real request becomes a quotation. Very expensive should come with a specific list of what is being done for it — hours, patching cadence, monitoring — rather than a vague promise of availability.

The question that clarifies most negotiations: what, specifically, will you do for this money in a month where nothing breaks?

A good answer describes patching, monitoring, backup verification and the support hours. A vague answer means you are buying insurance, and you should price it as insurance.

Before you sign

Get the AMC figure **before** the delivery contract is signed, not after. Once the system is built and running, your negotiating position is considerably worse than it looks, and both sides know it.