What Should a Software Maintenance and Support Agreement Cover?
Software needs attention after it goes live, too. The types of maintenance, response and resolution times, out-of-scope items and the headings to look for in a support agreement (SLA).
Alp3 min read
A significant part of the effort over a piece of software's lifetime is spent after it goes live. Operating systems are updated, the services it depends on change, security vulnerabilities are announced and the business's needs evolve. A maintenance and support agreement defines who will do what, and how quickly, during this period.
The four types of maintenance
In software engineering, maintenance is usually addressed under four headings:
- Corrective maintenance: Fixing the bugs that come up.
- Adaptive maintenance: Adapting the software to a changing environment; new operating system versions, browsers, changing third-party APIs.
- Perfective maintenance: Improving performance, usability and existing functions.
- Preventive maintenance: Work done before problems arise; library updates, code improvements, capacity checks.
A good agreement does not cover bug fixing alone; it clearly states which of these four types are in scope.
Headings the agreement should include
Scope
Which applications, environments and integrations are included in the agreement? Is server and infrastructure management in scope, or only the application?
Priority levels and times
Two times should be defined separately from each other: the response time (notification that the request has been taken up) and the resolution time (fixing the problem or providing a workaround). The table below is an example intended only to show the structure; the times are set according to the business's needs.
| Priority | Definition | Example situation |
|---|---|---|
| Critical | The system is unusable or there is a risk of data loss | The application will not open; payments cannot be taken |
| High | An important function is not working and there is no workaround | Orders cannot be created |
| Medium | A function works partially or there is a workaround | A report gives an incorrect total |
| Low | Visual or minor issues that do not block work | The alignment is off on one screen |
Support hours and channels
On which days and during which hours is support provided? Is there a route for critical situations outside working hours? Where will requests be submitted, and how will their status be tracked?
Monitoring and backups
Are system availability and errors monitored automatically? How often are backups taken, how long are they kept and is restoring tested regularly? An untested backup does not count as a backup.
Security updates
How often are the libraries and components in use scanned for security vulnerabilities, and how quickly are critical patches applied?
Reporting
The periodic report should include the requests opened and closed, the times, the updates made and recommendations. The report is the most concrete way to see what you are getting in return for the agreement.
What is out of scope
New features, out-of-scope integrations or outages caused by third parties are usually assessed separately. How these will be charged should be written down from the start.
Pricing models
- Fixed monthly fee: A predictable cost for a defined scope and period.
- Block of hours: A set number of hours to be used during the month; flexible, but usage needs to be tracked.
- Per request: Economical when usage is low; there is usually no time guarantee in critical situations.
Questions to ask before signing
- Will the team that developed the system provide support, or a separate team?
- What happens when the times are not met?
- When the agreement ends, how are the code, documentation and access handed over?
- Do unused hours carry over to the next month?
Maintenance is not the work done when something breaks; it is the work done regularly so that something does not break.
If you would like to discuss maintenance and support options for your existing software, you can get in touch with us.