How to Review a Maintenance And Support Agreement: a Clause-by-Clause Checklist

How do you review a maintenance and support agreement? Review a maintenance and support agreement by checking that the service you are promised is clearly defined, measurable and backed by real remedies, that the fees are predictable, and that the risk on data, downtime and exit sits where it should. A maintenance and support agreement (sometimes an annual maintenance contract, or the support schedule under a software or equipment contract) is where a product relationship is actually lived day to day, so vague wording here causes months of friction. Read the agreement with its service-level schedule and fee schedule together. The main terms set the framework, but the service levels and the price list decide what you really get. This article is general guidance, not legal advice. The law here varies by jurisdiction and changes over time, so have a qualified lawyer review any agreement before you rely on it. ## The clause-by-clause review checklist ### Scope of services

• Is "maintenance" defined (updates, patches, bug fixes, preventive maintenance) and separated from "support" (help with problems, incidents, questions)?
• Is it clear what is included in the fee and what is chargeable extra (new features, major upgrades, out-of-scope work)?
• For software: are updates, upgrades and new versions clearly in or out of scope?
• For equipment: are spare parts, consumables and on-site visits in or out?
• Are the exclusions fair (misuse, third-party changes, force majeure)? ### Service levels (the clause that decides what you really get)
• Are response times and, ideally, resolution or restoration targets defined by severity level?
• Are severity levels defined objectively, not left to the vendor's judgement?
• Are support hours and channels clear (business hours vs 24x7, portal, phone, email)?
• Is there an uptime or availability commitment, with how it is measured?
• Are there service credits or other remedies if targets are missed, and are they meaningful?
• Is there an escalation path for repeated or serious failures? ### Fees and changes
• Is the annual or periodic fee clear, and is any increase capped (for example to an index or a stated percentage)?
• Are chargeable rates for out-of-scope work stated?
• Are payment terms, taxes (GST in India) and late-payment terms clear? ### Term, renewal and exit
• Is the term clear, and does it auto-renew? If so, is the notice period to stop renewal reasonable?
• Can you terminate for persistent service failure, not only for a payment default?
• On exit, do you get your data back in a usable format, and is there transition help?
• For software, do you keep the right to use what you have paid for after support ends? ### Data, security and liability
• If the vendor accesses your systems or data, are security and confidentiality obligations clear?
• Is data-protection handled (relevant where the vendor processes personal data)?
• Is there a liability cap, and what are the carve-outs (confidentiality, data breach, IP, injury)?
• Is indirect or consequential loss excluded, and is that balanced?
• Is business-critical downtime addressed beyond a token service credit? ## Maintenance and support agreement red flags - Service levels with response but no resolution. A promise to "respond within 4 hours" means little if nothing commits the vendor to actually fix the problem. Look for restoration or resolution targets, or at least continuous-effort obligations.
• Vendor-defined severity. If the vendor alone decides how urgent your issue is, your worst outages can be downgraded. Severity should be defined objectively.
• Uncapped fee increases. An annual fee that can rise by any amount at renewal removes your budget certainty. Look for a cap tied to an index or a fixed percentage.
• Auto-renewal with a long notice window. A contract that renews automatically unless you give, say, 90 days notice can trap you for another term.
• Upgrades excluded quietly. For software, if major upgrades and new versions are out of scope, "maintenance" may not keep the product current.
• Weak or no exit and data return. If you cannot get your data back in a usable form, or lose the right to use software you paid for, switching vendors becomes very costly.
• Token service credits as the only remedy. A small credit for missed service levels, with no right to terminate for persistent failure, leaves you stuck with poor service. ## A note on jurisdiction Maintenance and support agreements follow a similar commercial logic everywhere, but some terms depend on local law. In India the contract is read under the Indian Contract Act, 1872, GST applies to the service fee, and consumer-protection rules may apply for smaller buyers. Liability caps and the exclusion of indirect loss are generally enforceable between businesses but are read against local rules on unfair terms and on excluding liability for certain harms. Where the vendor processes personal data, data-protection law applies (in India, evolving data-protection rules; elsewhere the UK GDPR, EU GDPR, Singapore's PDPA, Australia's Privacy Act, or US state laws). Treat liability limits, data obligations and auto-renewal terms as points to confirm against the governing law rather than assume one answer fits all. ## Where a contract workspace helps A checklist gets one maintenance and support agreement reviewed well. The repeated load is after signing: holding service levels, fee-increase and auto-renewal terms consistent across many contracts, and not letting a renewal date slip by unseen. What helps is having the drafting, the clause-by-clause risk view, the plain-language editing and the renewal tracking for support agreements in a single AI workspace shaped around how your company contracts, rather than scattered across separate tools. Adira is one workspace built on that approach.