Warranty vs support vs SLA — unbundling the three
These three get conflated constantly, and the conflation costs money on both sides. They are different instruments doing different jobs, and a well-drafted contract stack keeps them separate but dovetailed.
The warranty (lives in the development agreement)
Free defect-fixing for a defined period after acceptance — typically 6–12 months. It covers defects measured against the agreed specification, nothing more: no new features, no changes forced by a shifting environment. When it lapses, the developer owes you nothing further unless a support agreement takes over.
The support & maintenance agreement (its own contract)
The paid, ongoing service that starts when the warranty ends. Wider than the warranty: corrective work continues, but adaptive and preventive maintenance are added, along with availability of named support channels and committed response times. Priced annually (15–22% of licence or build cost) or as a monthly retainer.
The SLA (the measurement layer inside the support agreement)
Not a separate service — the schedule that makes the support promise measurable: response and resolution targets by severity, coverage hours, escalation paths, and remedies (service credits, termination for persistent failure) when targets are missed. A support agreement without an SLA is a promise without a ruler.
The drafting point that saves the most disputes: make the support term commence on warranty expiry, and ensure that during any overlap the support fee excludes what the warranty already provides free. Customers paying full support fees from go-live are paying twice for the same defect-fixing.
The eight clauses that matter
Support scope by category
Define corrective maintenance (diagnosing and fixing defects), adaptive maintenance (keeping the software working as operating systems, browsers, APIs and third-party dependencies change) and preventive maintenance (monitoring, patching, housekeeping) — and state expressly where enhancement work begins and separate fees apply.
Service levels + severity matrix
Response and resolution targets keyed to severity: Severity 1 (production down) through Severity 4 (cosmetic). Business-hours versus after-hours coverage, escalation paths, and the consequences of missed targets — service credits and termination rights for persistent failure.
Fees + escalation
Annual fee as a percentage of licence or build cost (15–22% is the commercial norm), a fixed monthly retainer, or per-incident rates — plus a defined annual escalation mechanism (CPI or a fixed percentage) so every renewal doesn't become a renegotiation.
Version coverage + end-of-support policy
Which versions the vendor must support (current plus n-1 or n-2 is standard), how long superseded versions remain supported after a new release, and a minimum notice period before any version reaches end-of-support.
Customer obligations
Reproducible defect reports, remote or on-site access to the environment, a staging environment for testing fixes before production deployment, and timeous installation of supplied updates. Vendor obligations are routinely excused where the customer hasn't held up its end.
Third-party dependency updates
Who monitors and applies updates to the database, frameworks, libraries and hosting stack the software depends on — and who pays when a third-party change forces rework. This is the hardest boundary inside adaptive maintenance and the most common fee dispute.
Source-code access + escrow linkage
For custom builds: whether the customer holds the source code (via a section 22(3) Copyright Act assignment) or needs escrow as a fall-back if the vendor fails. The support agreement should cross-refer to the escrow release triggers so abandonment of support activates release.
Term + termination + knowledge handover
Initial term, renewal mechanics, termination notice — and, critically, handover on exit: current documentation, the open and historical ticket record, environment credentials, and paid transition assistance to the incoming support provider.
The enhancement-creep problem
The single most common support dispute is not about response times — it is about what counts as support at all. Customers read “maintenance” to include small new features, field changes, report tweaks and “quick” integrations. Vendors read anything beyond defect-fixing as billable enhancement work. Without a classification mechanism, every “small change” quietly swallows the retainer — or every monthly invoice becomes an argument.
The ticket-classification clause
Define “enhancement” expressly (any change to agreed functionality, any new functionality, any change driven by the customer’s preference rather than a defect or environmental change). Require the vendor to classify every ticket on logging — defect, adaptive, preventive or enhancement — with the customer entitled to dispute within a fixed window and disputed tickets escalating to nominated managers. Unclassified work defaults to maintenance, so the vendor carries the incentive to classify.
For retainer models, add a small-enhancement pool: the monthly fee includes a defined number of hours of minor enhancement work, with anything larger quoted separately under a change-control procedure. State whether unused hours roll over. This converts the grey zone from a standing dispute into a managed allowance — the vendor keeps predictable revenue, the customer keeps its “small changes” moving without procurement friction.
Support for custom-built vs licensed software — what changes
Custom-built software: ownership drives everything
For computer programs — a separate category of protected work under section 2(1)(i) of the Copyright Act — the author is the person who exercised control over the making of the program (section 1(1)), the test the SCA applied in Haupt v Brewers Marketing Intelligence 2006 (4) SA 458 (SCA). Paying for development does not make you the owner; only a written, signed assignment under section 22(3) does. If you hold an assignment, the support agreement is a service choice — you can move maintenance to any competent third party. If the developer kept ownership, they are often the only party who may lawfully maintain the code, and you should negotiate accordingly: source-code escrow linkage, source access, and hard handover obligations.
Licensed (off-the-shelf) software: version policy is the battleground
Ownership is never in play — the licence prohibits modifying the code, so support can only come from the vendor or its accredited channel, and escrow is rarely available. The negotiation shifts to version coverage (current plus n-1 or n-2), end-of-support notice periods, forced-upgrade pricing, and what happens if the vendor discontinues the product or is acquired. Annual fee escalation and the right to drop to a lower support tier matter more here than anywhere else.
One issue cuts across both: where support staff access personal information in your environment — debugging against production data, remote sessions into live systems — the vendor processes personal information as an operator, and written operator terms under section 21 of POPIA are mandatory. If the support desk sits offshore (follow-the-sun models are common), section 72’s cross-border transfer conditions apply too. Build both into the support agreement or a data processing addendum rather than discovering the gap during an incident.
Frequently asked
What does software maintenance legally include?
There is no statutory definition — the contract is everything. Commercial practice divides maintenance into corrective (diagnosing and fixing defects), adaptive (keeping the software working as its environment changes — operating systems, browsers, third-party APIs and dependencies) and preventive (monitoring, patching, housekeeping). Enhancements — new features and changes to agreed functionality — are not maintenance and attract separate fees. If your agreement doesn't define these categories, you will argue about every ticket.
What is the difference between a warranty and paid support?
The warranty in a development agreement is free defect-fixing for a fixed period — typically 6–12 months from acceptance — and is limited to defects measured against the agreed specification. Paid support is the ongoing service that takes over when the warranty lapses, and covers more: adaptive updates, preventive work, and response-time commitments. The two should dovetail: the support term should start when the warranty ends, and during any overlap the support fee should not charge for defect-fixing the warranty already provides free.
What should software support cost?
The rule of thumb is 15–22% of the licence fee or build cost per year. Enterprise software clusters at 18–22%; simpler systems with infrequent change sit nearer 15%. The rule bends where the codebase is unstable (vendors price up), uptime requirements are high (24/7 Severity-1 coverage costs materially more than business-hours support), the environment is heavily customised, or the software is old and the skills to maintain it are scarce. For custom builds, fixed monthly retainers are common — anchor them to a defined included-hours pool.
Can a vendor abandon my version of the software?
Without contractual protection, yes — vendors routinely retire older versions and force paid upgrades. Negotiate a defined version-coverage commitment (current plus n-1 or n-2), a minimum end-of-support notice period (12–24 months for business-critical systems), and price protection for forced upgrades. For custom-built software where the vendor owns the code, link the support agreement to a source-code escrow so that abandonment of the product or of support is itself a release trigger.
What severity matrix is standard?
Four levels. Severity 1 (production down or unusable, no workaround): response within 1–2 hours, continuous effort until resolved. Severity 2 (major function impaired, workaround exists): response within 4–8 business hours, resolution targeted in days. Severity 3 (minor defect): response within 1–2 business days, fix in the next scheduled release. Severity 4 (cosmetic or query): commercially reasonable efforts. The matrix should also state who classifies a ticket (vendor proposes, customer may dispute) and what missed targets cost — service credits, management escalation, and termination for persistent failure.
Can I use a third party to maintain custom-built software?
It depends on who owns the code. For computer programs, section 1(1) of the Copyright Act makes the author the person who exercised control over the making of the program — the test the SCA applied in Haupt v Brewers Marketing Intelligence 2006 (4) SA 458 (SCA) — and paying for development does not transfer ownership; only a written, signed assignment under section 22(3) does. If you took an assignment, you own the program and may hand the source to any competent third party. If the developer kept ownership, third-party maintenance needs the developer's licence. For licensed proprietary software, the licence almost always prohibits modification — support can only come from the vendor or its accredited channel.
What happens to support when the agreement terminates?
A well-drafted agreement obliges the outgoing vendor to hand over current documentation, the open and historical ticket record, environment credentials and configuration detail, and transition assistance (typically 30–90 days at agreed rates) to the incoming provider. Without an express handover clause the vendor has no obligation to cooperate, and the operational knowledge needed to keep the system running walks out the door with them. Confidentiality should survive, and for escrowed custom builds the release mechanics should be cross-referenced.
What does support & maintenance agreement drafting cost in SA?
From R9,500 for a single-vendor support & maintenance agreement including the severity matrix and SLA. R12,000–R18,000 where it forms part of a larger contract stack (development agreement + support + escrow linkage) or where POPIA section 21 operator terms and section 72 cross-border schedules are needed for offshore support desks.