What a software AMC should actually cover (and the clauses to question)

Annual maintenance contracts have a mixed reputation in India, and not without reason. Many businesses have paid an AMC fee every year for a website or application and struggled to say what they got for it. Then, when something actually broke, they were told the fix was “outside AMC scope” and sent a separate quote.

That does not mean AMCs are a bad idea. Software that nobody maintains decays. Security patches pile up, the hosting environment changes underneath it, a payment gateway updates its API, a mobile operating system drops support for an old library. A good AMC is how you avoid finding out about those problems from a customer.

The difference between a useful AMC and an expensive formality is almost entirely in what the contract writes down. Here is what to look for.

1. A clear line between a fix and a change

This is the clause that causes most disputes. A fix restores something that used to work, or should have worked according to the original scope. A change makes the system do something new.

The contract should define both, with examples relevant to your system. “The invoice PDF shows the wrong GST total” is a fix. “Add a new column to the invoice PDF” is a change. “The booking page stopped loading after a browser update” is a fix. “Allow customers to book two slots at once” is a change.

Be wary of contracts that cover “bugs” without saying what a bug is, or that exclude anything “caused by third parties”. Almost every modern system depends on third parties, and a reasonable AMC should at least cover adapting to routine changes in the services you were set up with.

2. Response and resolution times, by severity

“We will respond promptly” is not a commitment. Look for a table that splits issues by severity and gives a time for each. For example:

• Critical (system down, or customers cannot pay): response within a few hours, work continuing until it is resolved or a workaround is in place.
• High (an important feature broken for many users): response the same working day.
• Normal (an inconvenience with a workaround): response within one or two working days.
• Low (cosmetic issues): scheduled into the next maintenance window.

The exact numbers depend on what you pay and how critical the system is. What matters is that they are written down, that “working hours” and holidays are defined, and that you know how to raise an urgent issue outside office hours if your plan covers it.

3. Security updates and dependency upgrades

Modern software is built on dozens or hundreds of open-source libraries, plus a framework, a language runtime, a database and an operating system. All of them release security updates. Applying them is routine but not trivial, because updates sometimes break things and need testing.

A good AMC says how often updates are reviewed and applied, and treats urgent security patches as a priority. If the contract is silent on this, assume it is not happening.

4. Monitoring and backups you can verify

Ask what is monitored: is the site or app checked for uptime? Are errors logged and reviewed? Who gets alerted, and when? You want to hear about a failed payment integration from your vendor before you hear about it from a customer.

Backups deserve their own line. The contract should say what is backed up, how often, where the copies are stored and how long they are kept. Most important, it should say how often a restore is tested. A backup that has never been restored is a hope, not a backup.

5. A bank of hours for small changes

Every live system collects small requests: a new field on a form, a tweak to a report, an extra email notification. Many AMCs include a fixed number of hours per month or quarter for these. That is usually good value, because it avoids a quote-and-approve cycle for twenty-minute jobs.

Check what happens to unused hours. Do they roll over, and for how long? Is there a cap on a single request before it becomes a separately quoted project? Clear answers here prevent friction later.

6. What happens with hosting, domains and third-party services

Find out whether hosting is included in the AMC fee or billed separately, and in whose name the hosting, domain and other accounts are registered. Our strong recommendation is that they are always in your company’s name, with your vendor given access. If an AMC includes hosting on the vendor’s own account, ask what happens to your site and data if you stop renewing.

The same goes for paid services such as SMS gateways, WhatsApp messaging, email delivery and AI usage. The contract should say who pays for them and who is responsible when their pricing or terms change.

7. Reporting

You should not have to ask what you are paying for. A useful AMC includes a short periodic report, monthly or quarterly, covering incidents and how they were handled, updates applied, hours used, backups and restore tests, and any risks the vendor sees coming, such as a framework version approaching end of life.

This report is also how you decide at renewal whether the AMC was worth it.

8. Exit and handover

Finally, the contract should say what happens if either side ends it: notice period, handover of credentials and documentation, and a reasonable amount of help transferring the system to someone else. A vendor confident in its service has no reason to resist this clause.

How to compare AMC quotes

AMC prices are often quoted as a yearly percentage of the original project cost. That is a convenient shorthand, but it hides more than it reveals. Two quotes at the same price can cover very different things.

Put the quotes side by side against the eight points above. Which ones define fix versus change? Which commit to response times? Which include security updates, monitoring and tested backups? How many hours of small changes are included? Who holds the accounts?

A cheaper AMC that covers only “bug fixes” with no response times may cost more over the year than a more expensive one that includes monitoring, updates and a bank of hours.

When you might not need an AMC

A simple brochure website on a managed platform, with no custom code, may not need a full AMC. The platform handles updates, and a few hours of paid help per year may be enough. Likewise, if you have an in-house developer who understands the system, you may only need a vendor for occasional specialist work.

For anything that takes payments, holds customer data, runs daily operations or integrates with other systems, though, some form of maintenance is not optional. The only question is whether it is planned, written down and paid for in advance, or handled in a panic after something breaks.

If you are about to commission new software, agree the support terms alongside the scope. Our guide on scoping a project before asking for quotes covers the rest of that document.