The build is finished. Who maintains it now? What belongs in a support contract

You find out whether a maintenance contract works during the first serious outage. On that day, four questions need written answers: what counts as a defect versus a change request, how fast someone answers and what they have actually promised to fix, who applies patches and dependency updates to the running system, and what gets handed over when the agreement ends. If those four are missing, every incident turns into a small negotiation, and the worst possible time to negotiate is while the system is down.

Maintenance is four jobs, and most contracts buy one

The 2022 edition of ISO/IEC/IEEE 14764 splits software maintenance into four categories. Corrective maintenance fixes defects that surface after release. Adaptive maintenance keeps the software working while the world around it moves: a cloud provider retires an API, a payment processor bumps its SDK, a browser enforces a new rule. Perfective maintenance improves something that already works, from query tuning to screen layout. Preventive maintenance closes problems before they become incidents, such as replacing a library whose support calendar is about to run out.

The same standard puts migration and retirement inside the maintenance process. We almost never see either of them named in a contract.

The word "maintenance" on its own means different things on each side of the table. The customer reads all four categories into it. The supplier, more often than not, reads only the first.

Most of the money does not go to bug fixing

The 1978 survey by Lientz, Swanson and Tompkins, still cited today, measured the split of maintenance effort as 17.4 percent corrective, 18.2 percent adaptive, 60.3 percent perfective and 4.1 percent other. Later studies that measured actual change records rather than asking people found corrective work running at more than twice the survey figure, but the shape held. Most maintenance effort goes into fitting the software to a changing environment and a changing business, not into repairing what was broken at delivery.

The practical consequence is easy to predict. A support contract scoped as "bug fixes" turns into a stream of quotes by the end of the first year, and each quote adds two weeks of waiting to work that should have been routine.

"That's not a bug, that's a change request"

You will hear that sentence eventually, so define the boundary before you do. The workable rule is short: behaviour that contradicts a written requirement or acceptance criterion is a defect and the supplier absorbs it, anything that extends the requirement is a change request. The rule only holds if the requirements were written in measurable form, which we covered in writing software requirements and acceptance testing.

Then assign the grey areas in advance. A screen that slows down as data grows is a defect if the acceptance criteria carried a number, and an argument if they did not. A mobile layout that breaks after an OS update is adaptive maintenance, and the bill usually lands on the customer. A third-party service retiring an API version sits in the same bucket. Writing those three examples into the contract settles three arguments you would otherwise have next year.

A warranty period is not a maintenance agreement

A warranty covers defects that existed at delivery, for whatever term the contract states; three to twelve months is common. Maintenance is continuous work that starts after delivery and is paid for. Customers who conflate the two expect monitoring, patching and version upgrades during the warranty term, while the supplier believes it committed to fixing defects and nothing else.

Statutory liability runs on its own track, and your warranty clause does not switch it off. Under the Turkish Code of Obligations, to take one example, claims arising from a defective work product are time-barred two years after delivery, and that stretches to twenty years where the contractor is grossly at fault. Limitation periods differ by jurisdiction, but the principle is the same everywhere: the end of the warranty clause is not the end of liability.

An SLA has two separate clocks

Response time is an obligation to acknowledge. Resolution time is an obligation to complete. Putting them on the same line is the most reliable way to produce a dispute. Priority deserves the same care: the widely used ITIL approach derives it from impact and urgency, a three-by-three matrix that resolves into levels from P1 down to P4. Targets seen in practice run from 15 to 30 minutes for a P1 with round-the-clock coverage, down to a few working hours for a P3.

Write down the mechanics too. Which channel opens a ticket (a developer's personal messaging app is not a channel), when the clock starts and what pauses it, which time zone the coverage hours refer to, and whether anyone is actually on call. Do not accept resolution commitments for things the supplier does not control. When the cause is a third-party outage, the promise should be a workaround and a fixed communication interval, not a repair deadline.

There is a second-order problem here. If the clock starts when a ticket is opened and nobody is watching the system, your customers become the alerting mechanism and the minutes in the contract stop measuring real downtime. Settle whether monitoring is in scope, and line the thresholds up with the ones from your observability and SLO work rather than inventing a second set.

Hour pool, fixed fee, or per-ticket

Three models circulate: a fixed monthly fee against a defined scope, a pool of hours, and per-ticket billing. Enterprise software has settled into a narrow price band that makes a useful reference point. Oracle charges annual support at 22 percent of the net licence fee for its technology products, and SAP lands at 19 or 22 percent depending on the support tier. Custom software has no licence fee to anchor to, so those percentages do not transfer directly, but they give you a defensible starting point for budgeting annual maintenance as a share of build cost.

Do not buy a bare pool of hours. Attach a scope list to it: monitoring, patching, backup verification, version upgrades, small enhancements. State what happens to unused hours, what the emergency rate is, and what happens when the pool runs dry mid-month. Estimates of maintenance as a share of total lifecycle cost range from roughly 60 to 80 percent across the literature. There is no single correct number, but every version of it points the same way: the larger half of the spend comes after delivery.

Security patching needs its own clause

A support contract that only processes tickets you open has nobody watching the CVE feed. A vulnerability in a dependency does not wait for someone to file a report. Four things belong in writing: who applies dependency and OS updates, how many days each severity level gets before it must be closed, who owns the container base image and the runtime, and when the annual upgrade window falls. The order of operations from patch and vulnerability management works well as a contract annex.

Put support calendars on the calendar as well. Your language runtime, database and framework all have published end-of-support dates, and the agreement should commit to raising them at least six months ahead. Otherwise you meet end-of-life software the hard way, on a random Tuesday.

Whose name is on the accounts

However well the relationship runs, access concentrated in the supplier's hands narrows your options later. The cloud account, the domain and DNS, app store developer accounts, the code repository, the secret store and the monitoring tools should all be registered to you, with the supplier holding delegated access. We went through the detail in source code ownership and escrow.

Add a transferability requirement next to it: deployment steps reproducible from documentation in the repository, environment variables listed, restore-from-backup procedure written down. The test is simple. If the supplier's most experienced developer takes a month off, who keeps the system running?

What happens when the contract ends

The exit clause is easiest to write on signing day and hardest to write on the day you part. It should cover the notice period, the contents of the handover package, the format and deadline for data delivery, how many hours are reserved for knowledge transfer, the schedule for transferring accounts and access, and when the supplier deletes its remaining copies. ISO/IEC/IEEE 14764 treats migration and retirement as processes for a reason: the last day of a system needs a plan as much as the first.

Maintenance you do not measure is maintenance you overpay for

Ask for a monthly report and keep it light: ticket volume and its split across the four maintenance categories, SLA compliance, hours consumed, patch and dependency status, and the five issues that recur most. Add a review meeting once a quarter.

That report exposes something a quote never will. If most tickets trace back to the same three modules, you are not buying maintenance, you are paying interest on technical debt. The answer at that point is to fix the modules, not to buy more support hours.

One thing to do this week

Open your current agreement and look for answers to five questions: how defects are separated from change requests, whether response and resolution are committed separately, who applies security patches, whose name is on the accounts, and what the handover package contains on termination. If more than two of them come back blank, write an addendum before the next incident rather than during it. Drafting it takes a day. Skipping it usually gets paid for on a night when nothing is working.