What a Software Maintenance and Support Agreement Should Cover
A software maintenance and support agreement should state what is covered, how problems are reported and ranked by severity, how fast the supplier must respond and restore service, how security updates, backups and monitoring are handled, how changes are requested and priced, and how you can leave with your code, data and documentation. Without those terms, “support” means whatever the supplier decides on the day something breaks.
Launch is the start of a system’s working life, not the end of the project. Most of its cost and most of its value arrive afterwards.
The short answer
- Scope: the application, hosting, integrations and third-party components, each named.
- Four kinds of work: fixing faults, adapting to change, improving, and preventing problems, including security.
- Severity levels with a response time and a restore time for each, plus the hours they apply.
- Security, backups and monitoring as named duties, with tested restores.
- Changes requested, estimated and approved through one route.
- Exit: code, data, documentation and accounts handed over on request.
“Launch is the start of a system’s working life, not the end of the project. The support agreement is where you decide whether it stays healthy or quietly decays.” — Abdulqader Wahiba, founder and CEO of ZAWAT
Why software needs maintenance at all
A business system sits in a world that keeps moving: tax rules change, browsers and phones update, connected services change their interfaces, and your own processes evolve. In 1980 the computer scientist Meir Lehman described this as a law of “continuing change”: a system used in the real world has to keep being adapted, or it becomes progressively less satisfactory.
In practice, maintenance falls into four kinds of work:
- Corrective: fixing faults that users find.
- Adaptive: keeping the system working as its surroundings change, such as a new operating-system version, a payment gateway update or a new e-invoicing requirement.
- Perfective: improving what exists, such as speed, usability or new reports.
- Preventive: fixing weaknesses before they cause failures, especially security updates to the frameworks and libraries the system is built on.
A good agreement says which of these the fee covers and how the rest is handled.
1. Define the scope
List what the agreement covers: the application itself, the hosting environment, the database, the integrations, and the third-party services and licences the system depends on. Then list what it excludes. A common dispute is a fault in a connected system, such as the accounting package or a payment gateway: who investigates, and who pays?
2. Severity levels, response and restore times
Rank problems by impact, and agree two times for each level: how fast the supplier responds, and how fast service is restored, even by a temporary workaround.
| Severity | Typical meaning | What to agree |
|---|---|---|
| Critical | System down, data at risk, or a core process stopped for everyone | Fastest response; work continues until service is restored; hours that match your operating hours |
| High | A major function broken, with no reasonable workaround | Response within business hours; restore target in hours, not days |
| Medium | A function impaired, with a workaround | Response within a business day; fix in a scheduled release |
| Low | Cosmetic issues and questions | Handled in the normal release cycle |
The numbers belong to you and the supplier, and depend on how critical the system is. Two things matter more than the figures: that they are written down, and that “response” and “restore” are defined separately. A reply saying “we are looking into it” is a response. It is not a restored service.
Agree the support hours too. If your branches open in the evening or at weekends, a support desk that works only office hours on weekdays will not help when it matters.
3. How problems are reported
One channel, such as a ticket system or a shared support address, so every request has a number, a time and a history. WhatsApp is convenient for urgent calls but poor as a record; if you use it, the issue should still be logged. Ask for a monthly summary: issues raised, times met or missed, and recurring problems.
4. Security updates, backups and monitoring
These should be named duties, not assumptions:
- Security updates to the framework, libraries and server, applied on a stated schedule, with urgent patches outside it.
- Backups on a stated frequency and retention, stored separately from the main system, with restore tests at agreed intervals. A backup nobody has restored is a hope, not a backup.
- Monitoring of availability, errors and disk space, so the supplier often learns of a problem before your staff do.
- Access reviews: who on the supplier’s side can reach your production system and data, reviewed periodically. Hiring a software company without handing over your data covers the confidentiality terms.
Where the system is hosted also matters, especially for personal data; cloud hosting rules in Oman explains the constraints.
5. Changes: one route in, priced before work starts
New features and changes are not faults, and they need their own path: a written request, an estimate, approval by your named owner, then scheduling. Some agreements include a monthly allowance of hours for small changes; others price each change separately. Either works if it is clear. What fails is a vague promise that “small changes are included”, which both sides will define differently.
A short review every quarter, to look at requests, recurring issues and the roadmap, keeps the system aligned with the business.
6. Documentation and knowledge
The agreement should require documentation to be kept current: how the system is deployed, how it is configured, how to restore it, and why it is built the way it is. ZAWAT’s published principle is that this documentation is written as the project runs rather than assembled at handover. It is what lets someone other than the original developer support the system.
7. Exit: make sure you can leave
Abdulqader Wahiba’s test for any support agreement is simple: could you hand the system to another team next month without depending on the current supplier’s goodwill? To pass it, the agreement should guarantee, on request and at the end of the term:
- the complete source code, in a repository your company owns;
- the database and all data, in a usable format;
- deployment configuration, credentials and documentation;
- reasonable transition help, at an agreed rate.
Who owns the software you paid for explains the legal side under Omani law, and choosing a software partner in Oman lists the contract clauses to settle before the build even starts.
Price and term
Agree how the fee is calculated, what it includes, how often it can change and with how much notice, and how either side can end the agreement. Ask what happens to hosting and data if a payment is late: suspending service to a system you rely on is a serious step, and the agreement should set out a process before it can happen.
Frequently asked questions
Do we need a support agreement if the system works well? Yes. A working system still needs security updates, backups, monitoring and adaptation as the things around it change. Without an agreement, those either do not happen or happen only after a failure.
What is the difference between a warranty and support? A warranty covers defects in what was delivered, for a fixed period after launch, usually at no extra cost. Support covers the system’s ongoing operation, updates and help afterwards, under a separate agreement.
What is an SLA? A service level agreement: the part of a support contract that sets measurable commitments, such as response and restore times by severity, support hours and availability targets, and what happens when they are missed.
Should our supplier host the system, or should we? Either can work. What matters is that the hosting account is in your company’s name or transferable to it, that backups and monitoring have an owner, and that you can move the system if you need to.
How should small changes be handled? Through the same route as larger ones: a written request, an estimate and an approval. A monthly allowance of hours can make small changes quicker, as long as both sides track how it is used.
Sources: M. M. Lehman — Programs, life cycles, and laws of software evolution (Proceedings of the IEEE, 1980)
Want a system that is supported properly after launch? ZAWAT provides integration and support for the systems it builds and documents them so you are never locked in. Book a call.