+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

What belongs in a software maintenance contract

IT Strategy By Mits Engineering Team 2 min read
What belongs in a software maintenance contract

The software is delivered, everyone is pleased, and a maintenance agreement is signed with little attention because the interesting part is over. It is the document that governs the next several years of the relationship, and it is usually two pages saying the supplier will provide support and fix defects. Both of those terms need defining or the first disagreement will be about what was promised.

Start with what counts as a defect. The useful definition is behaviour that differs from what was agreed at delivery — which requires that something written down exists to compare against. Without it, every request becomes a negotiation about whether this is a bug the supplier fixes free or a change the client pays for, and both parties can argue it sincerely. Naming the specification, acceptance criteria or documentation that defines correct behaviour is the single most valuable clause in the agreement.

Separate the categories explicitly, because they have different economics. Corrective work fixes defects. Adaptive work keeps the software running as the world changes around it — a dependency upgrade, an operating system release, a payment gateway changing its API, a regulatory change. Perfective work is improvement and new features. Most disputes come from adaptive work, which the client assumes is included because the software stopped working, and the supplier assumes is billable because nothing they did caused it.

Define response and resolution separately and by business impact. Response is when a human acknowledges and starts, and is entirely within the supplier's control. Resolution depends on the fault, on third parties and often on the client. Set severity levels by what the user cannot do rather than by technical symptom, state who classifies an incident, and state how disagreement about severity is settled — because that argument always happens at the worst moment.

Cover the boring operational questions that decide whether the arrangement works. Coverage hours and whose holidays. Who may raise a request, and through what channel — an agreement supporting anyone emailing anyone produces untracked work and no accountability. How many hours or requests are included and what happens beyond them. Whether unused hours carry forward. And what the annual price increase is, capped, so renewal is not an annual negotiation.

Finally, write the exit into it while everyone is friendly. What documentation exists and stays current. Who holds the credentials — all of which should be in your name throughout. What handover assistance is provided if you move to another supplier, over what period and at what rate. A maintenance contract that makes leaving difficult is not a maintenance contract, it is a dependency, and the moment you discover the difference is the moment you have least leverage to do anything about it.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy