Six months after launch, the software breaks on a Sunday. The vendor who built it quotes emergency rates, takes two days to respond, and the business loses orders in the meantime. The owner wishes someone had been responsible for keeping the system running. A software AMC contract creates exactly that responsibility: a formal agreement defining what support you get, how fast, and at what cost.
A software AMC contract is an annual maintenance agreement where a vendor provides defined support for your software: bug fixes, updates, monitoring and helpdesk access, governed by service-level agreements on response and resolution times. You pay a fixed fee, usually yearly or quarterly, and in return the vendor is contractually bound to keep your system running.
Why software needs support after launch
Software is never finished. Dependencies release security patches, operating systems update, traffic patterns change, and users discover edge cases that testing missed. Without someone responsible for this ongoing reality, small issues accumulate until they become outages. The question is not whether your software will need attention, but who will give it and under what terms.
Professional service firms feel this acutely: their internal tools, client portals and reporting systems are revenue infrastructure. An hour of downtime during a client deadline costs more than a month of support fees. A contract converts that risk into a predictable line item with a named party accountable for it.
Five things an AMC is not: maintenance vs support vs development vs hosting vs enhancements
Most AMC disputes come from these five terms being used interchangeably. Pin them down before signing, because each one has different cost and responsibility implications:
| Term | What it means | Usually in an AMC? |
|---|---|---|
| Maintenance | Keeping the existing system healthy: security patches, dependency updates, monitoring, backups | Yes — this is the core of the contract |
| Support | Helpdesk for your team: answering questions, troubleshooting, handling incidents within SLA | Yes — governed by response and resolution times |
| Development | Building new features or changing existing behaviour | No — scoped and billed as separate work |
| Hosting | Servers, cloud infrastructure, domains, SSL certificates | Sometimes — clarify who pays the cloud bill and who holds the accounts |
| Enhancements | Small improvements beyond bug fixes: a new report, a tweaked workflow | Sometimes, capped — define the monthly hour limit and what counts as a new feature |
The most common dispute is a development task disguised as a support ticket. Agree the boundary in writing with examples: "fixing a broken report" is support, "adding a new report type" is an enhancement, "building a new module" is development. Without this, every small request becomes a negotiation.
What a software AMC contract should include
A strong software AMC contract spells out six things. First, scope of coverage: which systems, modules and environments are included, stated explicitly. Second, included services: bug fixes, security patches, minor enhancements, monitoring, backups, and helpdesk support, each defined. Third, service-level agreements: guaranteed response and resolution times by severity. Fourth, exclusions: what costs extra, such as new features or third-party failures. Fifth, reporting: what you receive monthly to verify the work happened. Sixth, commercial terms: fee, payment schedule, term length, renewal and exit clauses.
Vague contracts hide behind phrases like best effort support and reasonable response times. Every operative term needs a number attached: hours, not adjectives. If a clause cannot be measured, it cannot be enforced.
SLA anatomy: response time versus resolution time
The heart of any AMC is the SLA table. Response time is how quickly the vendor acknowledges and starts work; resolution time is how quickly the issue is fixed. Vendors quote the first eagerly and the second reluctantly. Insist on both.
| Severity | Example | Response target | Resolution target |
|---|---|---|---|
| Critical | System down, data at risk | 1 hour | 4–8 hours |
| High | Core feature broken | 4 hours | 1–2 business days |
| Medium | Non-critical bug | 1 business day | 1 week |
| Low | Cosmetic issue, questions | 2 business days | Next release cycle |
The numbers above are starting points for negotiation, not standards; adjust them to your business reality. Also define support hours: a 4-hour response means little if it only applies on weekdays. For revenue-critical systems, negotiate extended or round-the-clock coverage explicitly, with the cost stated.
Pricing models for software support
AMC pricing usually follows one of three models. Fixed annual fee is the classic: predictable, simple, and appropriate when the system is stable. Tiered plans offer bronze, silver and gold levels with different SLA commitments; choose the tier that matches the cost of downtime, not the cheapest one. Hourly buckets sell a block of support hours at a discounted rate, which suits systems with sporadic needs but creates disputes over hour counting.
Watch how price relates to risk transfer. Cheap AMCs push risk back to you through exclusions, slow SLAs and narrow scope. Expensive ones are only worth it if the SLA commitments and coverage justify the premium. Price the contract against one bad outage, and the right tier usually becomes obvious.
Exclusions and red flags
Read the exclusions section as carefully as the coverage. Common legitimate exclusions include new feature development, issues caused by third-party services, and damage from unauthorized changes. Red flags are different: exclusions so broad that little remains covered, no SLA credits when targets are missed, automatic renewal with price escalation buried in fine print, and termination clauses that make exit painful.
Two more warning signs: the vendor will not put response times in writing, and the contract has no reporting obligation. Both indicate a vendor selling the appearance of support. Compare this with website care plans, which follow the same logic at smaller scale; our website maintenance and support guide shows the pattern applied to websites.
When an AMC is overkill
Not every system needs a full AMC. Skip it for internal tools with low usage where a few days of downtime costs nothing, for software nearing end of life that will be replaced within the year, and for simple static systems with no moving parts. In these cases, pay-per-incident support or a small hourly retainer is more economical.
The honest test: estimate the cost of your worst realistic outage, including lost revenue, staff idle time and reputation damage. If that number is smaller than the annual AMC fee, self-insure. If it is larger, the contract pays for itself the first time it matters.
Comparing support proposals
When vendors bid for your support business, compare them on identical terms: same scope definition, same severity levels, same reporting requirements. Ask each bidder how they handle an incident end to end, who exactly responds at 2 AM, and for two client references you can call about real outages. The proposal evaluation discipline in our proposal evaluation guide applies here with equal force.
Understand what the vendor actually does day to day. Ongoing support is DevOps services work — monitoring, deployment hygiene, incident response — combined with cloud monitoring and optimization for the infrastructure underneath. Ask about their monitoring stack and on-call rotation; vague answers predict vague support. The habits that make software supportable are built during the build itself, which is why our software development process treats operability as a first-class requirement. Our perspective for service businesses is on the professional services industry page.
AMC and SLA evaluation checklist
Score every proposal against this list before signing. A missing item is a negotiation point, not a dealbreaker — but it should be a conscious decision:
- Scope names every system, module and environment covered — no "etc."
- Response and resolution times defined per severity, with support hours stated
- SLA credits or remedies when targets are missed
- Exclusions listed explicitly: new features, third-party failures, unauthorized changes
- Security patching cadence and backup/restore responsibilities defined
- Monthly reporting: tickets handled, SLA performance, uptime, work performed
- Escalation path with named contacts, including after-hours coverage
- Documentation handover: architecture notes, credentials, runbooks
- Ownership: you hold the repository, infrastructure access and data
- Renewal terms: notice period, price-change caps, no silent auto-renewal traps
- Termination: for convenience with 30–90 days notice, plus handover assistance
- Enhancement boundary: monthly hour cap for small improvements, and what counts as a new feature
Frequently asked questions
What is the difference between warranty and AMC?
The warranty covers defects in what was delivered, usually for 30 to 90 days after launch, and only for bugs in the original scope. An AMC covers the ongoing life of the software: new issues, updates, monitoring and support long after the warranty expires. Do not confuse the two when a vendor says support is included.
Should the AMC be with the vendor who built the software?
Usually yes for the first year, because they know the codebase. After that, you can competitively bid it, provided the code is documented and you own the repositories and credentials. Vendor lock-in at the support stage is a sign of poor handover practices during the build.
What response time should we demand?
Match it to the cost of downtime. For systems where an hour offline loses revenue, demand one-hour critical response with resolution commitments. For back-office tools, next-business-day response is fine. Paying for aggressive SLAs on non-critical systems is wasted money.
Can we cancel the AMC mid-term?
Only if the contract allows it, which is why exit clauses matter before signing. Negotiate termination for convenience with reasonable notice, typically 30 to 90 days, and ensure handover assistance is included. A vendor confident in their service will not need contractual handcuffs.
Pay for accountability, not promises. Talk to our team about a support arrangement with SLAs you can verify, and we will scope it to your actual risk.