What Should a Software Maintenance Contract Include?
A sound software maintenance contract sets out exactly which systems are covered, response and severity targets, whether change requests are included or billed separately, who owns code and access, and how either party can exit. Vague contracts cause disputes later — specific ones prevent them by settling expectations before work begins.
Define Exactly What Is Covered
A maintenance contract should name the exact systems it covers — which application, which environments (production, staging, any mobile apps), and which integrations — rather than referring vaguely to 'the software'. It should also state exclusions clearly: hardware, third-party platform outages, custom hosting incidents outside the vendor's control, or components that were not part of the original build.
Imagine a retail chain with an in-house inventory app that talks to its point-of-sale system and an accounting package. If the maintenance contract only says 'inventory software' without naming the POS integration and the accounting sync as covered systems, the chain may discover — during an actual integration failure — that the vendor considers that specific connector out of scope, even though it looked like part of 'the software' to everyone on the retail side.
Set Support Hours, Severity Levels and Escalation
Support hours should state precisely when the vendor is reachable — business hours only, or an extended or 24x7 window — and what happens outside those hours for a genuinely urgent issue. Severity levels, commonly something like critical, high, medium and low, should be defined with real examples relevant to the business, not left as abstract labels, so both sides agree in advance on what counts as 'the whole system is down' versus 'a minor cosmetic issue'.
The contract should also set an escalation path — who gets contacted, and by when, if the agreed response time is missed. Without one, a missed response typically just goes unnoticed until the business happens to check.
Separate Maintenance From Change Requests and Third-Party Costs
Ongoing maintenance and new feature work are different kinds of spend, and a contract that does not separate them tends to cause friction. Maintenance usually covers keeping the existing system stable, patched and working; a change request — a new report, a new field, a new workflow — is new scope, and the contract should say whether it is included within a maintenance retainer, billed separately, or capped at some number of hours per month before extra billing applies.
The contract should also address who bears the cost when a fix requires action from a third party outside the vendor's control — a hosting provider, a payment gateway, a mapping or SMS API — since resolving those issues can take vendor time even though the underlying fault is not the vendor's code.
Cover Access, Ownership, Confidentiality and Exit Terms
Access and ownership terms matter because they determine what the business actually controls if it needs to leave. The contract should state that source code, credentials, and infrastructure accounts remain under the business's own control, or are handed over in full on request, rather than living solely inside accounts the vendor administers on the business's behalf.
It should also cover confidentiality of the business's data, and set out exit terms — a notice period, a defined handover process, and what documentation or knowledge transfer the vendor owes the business if the relationship ends. None of this is a substitute for the business's own legal review before signing; a lawyer familiar with services contracts should check severity definitions, liability limits and termination clauses against the business's specific risk, since the right terms vary by situation.
Build in Reporting and Regular Review
A contract that never gets revisited tends to drift out of step with how the business actually uses the software. Build in a fixed reporting cadence — a monthly or quarterly summary of tickets resolved, patches applied and any pending risks — and a periodic service review where both sides can adjust scope, severity definitions or support hours as the business's needs change.
This review is also the natural point to check whether the contract's original assumptions still hold — whether the systems named in scope are still the systems actually in use, and whether response times that felt adequate at signing still match how critical the software has become to the business.
Maintenance scope comparison checklist
A side-by-side checklist for comparing maintenance proposals from different vendors across scope, severity definitions, response and resolution targets, change-request handling, access and ownership terms, and exit provisions, so an SMB can spot gaps before signing rather than after.
Frequently asked questions
Does a response SLA mean a guaranteed fix time?
No. A response time is a commitment to acknowledge and start working an issue by a set deadline; it says nothing about how long the fix itself will take. Resolution or restoration time — a separate, usually longer, target — is the commitment that relates to when the issue is actually fixed, and a contract should state both separately rather than only one.
Are feature requests included?
Only if the contract explicitly says so. Most maintenance contracts cover keeping the existing system running — bug fixes, patching, monitoring — and treat new features as separate change requests, either billed on top or capped at a limited number of hours per month. Check this explicitly before assuming a maintenance retainer will absorb ongoing feature development.
Have a specific situation to work through?
This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.