What a Software Maintenance Contract Should Cover

The Five Kinds of Maintenance Work

The software engineering standard for maintenance, ISO/IEC/IEEE 14764, sorts the work into five kinds. A contract that only promises to fix bugs covers one of them.

1. 1
   Corrective

   Fixing what is broken: a report that shows the wrong total, a screen that fails for one customer. The contract should say whose defects are covered. Ours covers defects in code we wrote.

2. 2
   Adaptive

   Keeping the software working as everything around it changes: the operating system, the runtime it runs on, the browser, the API of a system it connects to. Security patches and runtime upgrades are most of this work, and it never stops. A contract that is silent on it leaves the software to age until support for its platform ends. For .NET, our .NET Upgrades page lists the end-of-support dates.

3. 3
   Perfective

   The small improvements people ask for once they use the system every day: a column, a shortcut, a report. This is the work that waits for months when nobody has time set aside for it. A plan with a monthly block of time covers it; a contract without one quotes each request.

4. 4
   Preventive

   Finding and fixing faults before they reach anyone: a dependency with a known vulnerability, a job that will fail when the data grows, code that has drifted from what runs in production. It is the easiest kind to leave out, because nothing is visibly broken when it is skipped.

5. 5
   Additive

   New features: a report that did not exist, a portal for customers, a connection to another system. The standard counts it as maintenance; a plan's monthly block of time does not cover it. The contract should say how such requests are quoted.

The standard covers changes to the software. Running it is a separate job: monitoring, backups, and restore tests are operations, not maintenance, and the contract has to say who does them too. The checklist below includes them.

What the Contract Should Say

Check that the contract answers each of these. "We'll take care of it" is not an answer.

• Which software, and where. The applications, the environments, the integrations, and who hosts each piece.
• Which of the five kinds of work are included, and for each, what the fee covers.
• How patches are applied. On a set schedule, by whom, and who watches the end-of-support dates of the platform the software runs on.
• What is monitored. What is watched, who is alerted, and during which hours.
• Who runs the backups and who tests them. A backup that has never been restored is a guess.
• How fast they respond. A response commitment, in writing, with the coverage hours it applies to.
• Who reviews changes. Every change reviewed by a named person or team before it is released.
• What is in your name. The source code in a repository you own, and the accounts, domains, certificates, and secrets registered to you.
• What happens to a request beyond the plan. A quote, a queue, or a rate, decided before the first such request.
• Term, renewal, and notice. How long it runs, how it renews, and how much notice either side gives.
• What you get back when it ends. The source, the account inventory, a runbook, and the open requests.

Response Time Is Not Resolution Time

A response time is how long until someone replies to your request, not how long until work on the problem starts. A resolution time is how long until the problem is fixed. A vendor controls the first and not the second: the cause may sit in a third-party service, in your own network, or in a change someone else made. A contract that promises resolution times either carries a buffer in the price or will be broken the first time the cause is outside the vendor's reach.

What a fair contract promises instead: a reply within a stated time, continued work on serious problems during coverage hours, and updates until a fix or a workaround is in place. We do not promise how long every fix will take, because we cannot know.

What a Fair Contract Leaves Out

Exclusions protect you as much as the vendor. A contract with none has an argument waiting for the first unusual request. A fair one excludes new features and other work bigger than the plan's monthly time, which is quoted separately with a written scope; outages in third-party services, which the vendor can help diagnose and cannot fix; manual data work; and problems caused by changes someone else made to the software. Ours exclude the same four; the full list is on the Care Plans page.

Coverage hours belong here too. A plan that covers business hours and says so is worth more than one that promises round-the-clock support from a team that cannot staff it. Ask who answers at three in the morning. If the answer is a name, the promise is real.

What You Get Back If You Leave

The exit terms are the part you will care about most on the day you need them, and the part that is easiest to leave out while everyone is getting along. With what the contract gives you, could another developer take the software over next month? For that they need:

• The latest source code, with every change made under the plan, in a repository you own.
• An inventory of the accounts, services, secrets, certificates, and domains, with who owns each one.
• An up-to-date runbook: how to deploy, what is monitored, how backups run, and the known issues.
• The status of every open request.

Ask for these in the contract before you sign, with a date by which they arrive after the plan ends. A vendor who hesitates is telling you how much of your system they expect to hold.

The contract that matters most covers the years after launch, not the months before it.

Software You Did Not Build

When the software comes from a vendor who is gone, or you are moving it from one vendor to another, the contract should start with an assessment rather than a promise. Nobody can commit to keeping a system running without knowing what it runs on, whether the source matches what is in production, and when a backup was last restored. We take software we did not build onto a plan only after a Production-Readiness Review, which scores those things with evidence and tells you what needs fixing first. When the review finds that the code is missing or the system is one failure from gone, Software Rescue & Takeover comes before any maintenance plan.

Keep Reading