In this guide
- Define what maintenance does and does not include
- Define covered systems and environments
- Separate incidents, defects and changes
- Set response and resolution expectations
- Address security and updates
- Require documentation and reporting
- Set response, security and change terms explicitly
- Practical checklist
- Questions to take into the next discussion
- Common mistakes to avoid
- Frequently asked questions
- Make the plan easy to maintain
- Related support from Phoneix Global
- Official references and further reading
A software maintenance agreement should explain exactly what is covered—bug fixes, updates, support response times, security patching—and what is not, such as new features. Disputes arise when ‘maintenance’ is undefined, so the scope’s job is to make both sides’ expectations explicit before they diverge.
This article provides general technology and operational guidance. Security, legal and contractual requirements depend on the system and data involved. Use qualified specialists for risk sensitive decisions.
Define what maintenance does and does not include
The word ‘maintenance’ means different things to different parties. A good agreement spells out what is covered—fixes, updates, patching, support—and what counts as new work charged separately. Ambiguity here is the source of most maintenance disputes, so resolve it in the scope, not in argument later.
Define covered systems and environments
List applications, websites, integrations, hosting, databases and third party services. State which versions and environments are supported.
Separate incidents, defects and changes
A defect is not the same as a new requirement. Define categories, priority levels and the process for estimating change work.
Set response and resolution expectations
Response time means acknowledgement, not always a fix. Use severity definitions and realistic target restoration or workaround times.
Address security and updates
Clarify vulnerability monitoring, dependency updates, backups, access reviews and emergency patching. State who approves changes.
Require documentation and reporting
Maintenance should produce ticket history, release notes, access records and regular service reports. Documentation reduces dependence on one person.
Set response, security and change terms explicitly
Define service levels in concrete terms: how quickly issues are acknowledged and resolved by severity, how security patches are handled and on what timeline, and how the software is kept compatible as its environment changes. Vague commitments to ‘reasonable support’ give neither side a standard to rely on.
Clarify the boundary between maintenance and enhancement, and how change requests are scoped and priced, so adding a feature does not become a disagreement about whether it was ‘included’. Cover data handling and security responsibilities too, since these depend on the system and the data and may carry legal obligations that vary by jurisdiction.
Read the agreement and mark each item as clearly in scope, clearly out, or ambiguous. Every ambiguous item is a future dispute—resolve it in writing before signing.
Practical checklist
- Covered systems list
- Incident and change definitions
- Severity and response matrix
- Security maintenance duties
- Reporting and documentation
Questions to take into the next discussion
- What is excluded from the monthly fee?
- Who can raise a priority one incident?
- How are third party outages handled?
- What documentation is updated after each release?
Common mistakes to avoid
- Leaving data migration, access control, backups and security review until the end of the project.
- Using vague terms such as complete, fast or user friendly without measurable acceptance criteria.
- Failing to document ownership of source code, accounts, domains, licences and technical records.
- Treating launch as the end of the project instead of the start of maintenance and monitoring.
- Buying a tool or beginning development before the workflow and user need are understood.
Frequently asked questions
What should a maintenance agreement cover?
What is included—bug fixes, updates, patching, support response times—and what is excluded, such as new features charged separately.
Why define response times?
Concrete service levels by severity give both sides a standard, unlike vague ‘reasonable support’ commitments.
How should change requests be handled?
The agreement should define how enhancements are scoped and priced separately from maintenance.
Make the plan easy to maintain
Keep the agreed scope, service levels and change-request process in one document both sides accept, and review it as the system and its environment change, since maintenance needs evolve over the software’s life.
Related support from Phoneix Global
For tailored guidance on defining a software maintenance scope, look at our advisory offering or contact the team with the specifics of your case.
