Software Maintenance Agreements: Scope, SLAs & Pricing

A software maintenance agreement is the contract that defines what happens to your software after launch: which fixes are included, how fast the vendor must respond, and what you pay for it. The common benchmark for packaged software is 20% or more of net license fees per year, escalating annually — and scope plus service levels drive the number far more than headcount does.

The most expensive argument in any software project happens about three months after launch. You think a broken report is a defect. Your vendor thinks it is a change request. Neither of you wrote it down, so the argument is settled by whoever is more stubborn — and while you argue, the report stays broken.

That gap is almost never bad faith. Your development contract described the work up to delivery; nothing described the decade after it. The maintenance agreement is the document that covers that decade, and it is usually drafted in a hurry, copied from a template, and never read again until something breaks.

This guide approaches the agreement from the buyer's side rather than the lawyer's: how to write scope so it cannot be reinterpreted, which response times are realistic, how annual fees are actually calculated, and which omissions quietly inflate your invoice later. The focus is web and enterprise software; mobile apps carry a different maintenance profile, covered separately.

Table of Contents

• What a Software Maintenance Agreement Actually Covers
• The Four Types of Maintenance and Why Adaptive Work Breaks Budgets
• What Should Be Out of Scope
• SLA Design: Severity Levels, Response and Resolution Times
• Service Credits: Does Your SLA Have Teeth?
• Pricing Models: Retainer, Hours Bank, Break-Fix
• How Annual Maintenance Fees Are Calculated
• The 12 Clauses Every Agreement Needs
• Data Protection When Your Vendor Touches Production Data
• The Compounding Cost of Skipping Maintenance
• Web and Enterprise Software vs Mobile App Maintenance
• Renewal and Switching Vendors: The Exit Clause
• Frequently Asked Questions

What a Software Maintenance Agreement Actually Covers

A software maintenance agreement commits a vendor to keep working software working, and it prices that commitment. It is the sequel to your development contract, but its subject matter is different: one promises to build something new, the other promises to preserve something that already runs.

A useful agreement separates four blocks rather than quoting one lump sum:

• Reactive work. Diagnosing and fixing reported defects, incident response, rollback.
• Proactive work. Security patching, dependency upgrades, backup verification, monitoring.
• Flexible work. Small improvements and configuration changes inside a monthly hours quota.
• Governance. Reporting, a periodic review meeting, an escalation ladder, and a change-request process.

If all four blocks hide inside one price, you cannot audit the price and you cannot resolve a scope dispute. Writing them separately costs you one extra page and saves you the first argument.

The legal guidance on this is consistent. The Pinsent Masons Out-Law guide to software maintenance agreements stresses that "response times (and where possible resolution times) should be agreed and incorporated in the maintenance agreement as a measure for both parties of whether the supplier's maintenance obligations are being properly discharged." It also flags the question most templates skip: are new releases, versions and upgrades included in the agreed fee, or billed separately?

The Four Types of Maintenance and Why Adaptive Work Breaks Budgets

Software engineering splits maintenance into four categories. Lifting those four categories straight into your scope clause closes most of the "is this included?" conversations before they start.

Adaptive maintenance is the category buyers consistently underestimate, because you do not control its calendar — upstream vendors do. Two concrete examples from the platforms most business software sits on:

PHP's official support schedule shows PHP 8.2 receiving critical security fixes only, with even that ending on 31 December 2026; PHP 8.4's active support ends on the same date. On the JavaScript side, Node.js release history shows Node 20 already end-of-life, with only the 22 and 24 LTS lines recommended for production.

These are not optional improvements. Software running on an unsupported runtime goes unpatched the next time a serious flaw lands in it. If your agreement excludes these upgrades, the cost does not disappear — it compounds and arrives later as a migration project.

What Should Be Out of Scope

A strong software maintenance agreement lists exclusions as explicitly as inclusions. These eight items generate most disputes:

1. New modules and new screens. Building functionality that does not exist is a project, not maintenance.
2. Platform migration and rewrites. Framework changes, database migrations and architectural changes are modernisation work.
3. Third-party licences and usage fees. Hosting, TLS certificates, email and SMS delivery, map APIs, payment processing.
4. Content entry. Loading products, posts and images is an operational service, billed separately.
5. Data corrections caused by user error. Usually doable, but it should draw down the hours quota.
6. Changes forced by an integration partner. When a bank or marketplace changes its API version, decide in advance whether that sits inside the fee.
7. Infrastructure scaling driven by growth. Tripling traffic is a capacity decision, not a maintenance line item.
8. Training and onboarding new staff. Define it as separate hourly work.

Pair the exclusion list with a written change-request process: how a request is submitted, how many working days the vendor has to quote it, which hourly rate applies, and who on your side can approve it. Those four sentences stop out-of-scope work from accumulating on a handshake.

SLA Design: Severity Levels, Response and Resolution Times

The service level agreement is the measurable half of your contract. Keep two clocks apart: response time is how fast the vendor acknowledges and starts work; resolution time is how fast the problem goes away. An SLA that commits only to response times commits to almost nothing, because acknowledgement is trivially easy to hit.

Mature SLAs start by defining severity. Large cloud providers set the de facto ladder here: the AWS Support plans commit to a response in under 15 minutes when a business-critical system is down, under 1 hour when a production system is down, under 4 hours when a production system is impaired, under 12 hours for a non-production impairment, and under 24 hours for general guidance.

For a custom web or enterprise application, a realistic adaptation looks like this:

Three details decide whether that table means anything. First, when the clock starts — at the moment your ticket arrives, or at the start of the next business day? Second, the coverage window: business-hours cover and genuine out-of-hours cover differ in price by two to three times, because the second one requires a separate on-call rota. Third, who assigns severity: if you say S1 and the vendor says S3, who decides? The practical fix is to define each level with examples and require mutual confirmation of severity in the first response.

One more precondition: name a single intake channel. Without it, requests arrive by chat, email and phone at once, and nothing is measurable — least of all SLA compliance.

Service Credits: Does Your SLA Have Teeth?

A time commitment with no consequence is a wish. In mature contracts the consequence is a service credit: miss the commitment, and a defined percentage of that period's fee is credited back.

Published vendor SLAs are a useful reference for how to build this. Atlassian's service credit terms apply a 10% credit when monthly uptime falls between 99.0% and 99.9%, 25% between 95.0% and 99.0%, and 50% below 95.0%, with an additional 5% tier for enterprise plans between 99.9% and 99.95%. Claims must be filed within fifteen days of the end of the month in question, and credits are applied against future invoices rather than refunded.

You do not need to copy that structure, but any credit clause needs three elements:

• A measurement method. What tool measures uptime, from where, and does planned maintenance count against it?
• Tiered consequences. A sliding scale rather than one flat penalty.
• A claim procedure and deadline. Does the credit apply automatically, or must you request it within a window?

Be realistic about what credits achieve. Twenty-five percent of a monthly retainer rarely approaches the cost of a full day of downtime. That is why the clause that matters most sits next to it: the right to terminate without penalty after repeated SLA breaches. That single sentence is your strongest position in any renewal negotiation.

Pricing Models: Retainer, Hours Bank, Break-Fix

Four models dominate. Each shifts risk to a different party.

In practice the most balanced structure is a fixed retainer plus an overage rate: proactive and reactive blocks sit inside the flat fee, flexible work draws on a monthly quota, and anything beyond the quota bills at a pre-agreed hourly rate. Allowing unused hours to roll forward one month (capped at the quota) removes the "I paid for nothing" friction without exposing the vendor to an unbounded backlog.

If you choose an hours bank, write down two things the template will omit: how long the hours remain valid, and whether the SLA survives an empty pool. Skip the second clause and you will be negotiating a top-up purchase while your system is offline.

How Annual Maintenance Fees Are Calculated

For packaged software the benchmark is well documented. A software maintenance negotiation white paper published through the US General Services Administration notes that "it is common for a Software Publisher to charge 20% or more of net (discounted) license fees for the initial year of software maintenance, then escalate maintenance annually." Its blunt summary of the consequence: "Under this model, organizations essentially pay for new licenses every five years."

The same paper shows why the escalation rate deserves as much attention as the headline percentage. On a $25 million list-price deployment, the difference between maintenance at 22% of net licence fees with 4% annual escalation and 18% with 2% escalation exceeds $12 million across a 15-year lifecycle. Negotiating the percentage alone is half the job; negotiating the escalation rate and what it is indexed to is the other half.

Custom-built software has no licence fee, so the calculation is anchored differently. Three approaches work:

• A percentage of the build cost. Simple to budget, and it scales with the surface area you are maintaining. The more integrations your system touches, the higher that percentage sits.
• Bottom-up from hours. Estimate the monthly proactive workload honestly — patching, backup restore tests, monitoring review — then add a buffer for reactive work.
• Infrastructure separated from labour. Hosting, backup storage, monitoring tools, certificates and third-party services belong on their own line. Bundled into a retainer, their annual increases disappear into your fee invisibly.

To sanity-check the relationship between scope and budget before you negotiate the maintenance line, the website cost calculator gives a rough build figure you can then apply a maintenance percentage to. For the project-side budget in full, our guide to software project budgeting breaks down the development cost structure.

Finally, never leave the price-increase clause as the vendor's unilateral decision. It needs a cap, a published reference index, and a notice period.

The 12 Clauses Every Agreement Needs

Use this as a pre-signature checklist for any software maintenance agreement. The number of missing clauses predicts the number of future arguments.

1. Scope definition. All four maintenance types written separately, with exclusions listed.
2. Severity levels and SLA. Levels defined with examples; response and resolution committed separately.
3. Coverage window and holiday rules. Which hours, which days, and how public holidays and vacation cover are handled.
4. Single intake channel and escalation. Where tickets land, who escalates in what order, named contacts and their deputies.
5. Hours quota and overage rate. Monthly quota, rollover rule, overage hourly rate.
6. Change-request process. Quoting turnaround, approval authority, form of the resulting work order.
7. Reporting and review cadence. Monthly report contents — tickets opened and closed, SLA compliance, patches applied — and meeting frequency.
8. Environment and access management. Separation of development, staging and production; who holds which privileges; access logging.
9. Backup and restore commitments. Frequency, retention, recovery objectives, and at least one tested restore per year.
10. Data processing addendum. Processor obligations, sub-processor rules, breach notification deadline.
11. Intellectual property and source code. Who owns code written during maintenance, and how code and credentials are held.
12. Term, termination and handover. Contract length, renewal mechanism, notice period, and exit obligations.

Clause 11 is the one buyers most often assume is already settled. Paying a maintenance invoice does not by itself transfer ownership of code written during the engagement; the assignment has to be written. Our guide to source code ownership covers how that works in practice and which arrangements leave you exposed.

Data Protection When Your Vendor Touches Production Data

A maintenance team reaches production by definition, which means it reaches real customer records. This is the section templates handle worst and regulators handle most seriously.

Under Article 28(3) of the GDPR, processing by a processor must be "governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller," setting out the subject matter and duration of processing, its nature and purpose, the types of personal data and categories of data subjects, and the controller's obligations and rights (Article 28 GDPR). The processor must act only on documented instructions, impose confidentiality on its staff, apply Article 32 security measures, respect sub-processor conditions, assist with data subject requests, and delete or return the data when the service ends.

Translated into maintenance clauses, that means six specifics:

• Instruction limits. Which data the vendor may access, for what purpose, under whose instruction.
• An access inventory. How many people hold which privileges, and how quickly access is revoked when staff leave.
• A ban on copying production data into test environments. With a masking or anonymisation requirement where a copy is genuinely needed.
• Sub-processor control. No onward transfer to a third party without written authorisation.
• A breach notification deadline. How many hours the vendor has to tell you about a security incident.
• End-of-contract deletion. Including backups, logs and local copies, documented.

If your users include California residents, the CCPA service-provider terms add their own contractual requirements, so check whether one addendum can satisfy both regimes before you draft two. Either way, write confidentiality as surviving termination — the obligation should outlast the engagement.

The Compounding Cost of Skipping Maintenance

"It works, do not touch it" does not remove cost. It defers it and adds interest. Three figures from 2026 show how quickly that interest accrues.

First, the patch queue has exploded. By publication date, the NIST National Vulnerability Database recorded roughly 50,000 vulnerability entries during 2025, and passed 75,000 in the first nine months of 2026 alone. The longer your dependency list, the higher the odds that stream reaches your stack.

Second, attackers changed their preferred front door. Verizon's 2026 Data Breach Investigations Report finds that 31% of breaches now start with software vulnerabilities, overtaking stolen credentials as the most common initial access route. That makes "we hold nothing sensitive" a weak defence: the target is increasingly your unpatched component rather than your data.

Third, incidents cost more. IBM's Cost of a Data Breach research puts the global average cost of a breach at $4.99 million, a 12% year-over-year increase and a record high. That is a global mean across org sizes and sectors, so do not read it as your exposure — but the direction is not in dispute.

There is also an unbilled cost that never appears in a risk register: every deferred upgrade makes the next one harder. Lifting a dependency that is two major versions behind costs several times what three timely upgrades would have, because you are no longer performing an upgrade — you are repairing a backlog of accumulated breakage all at once. For the security baseline every maintained system should meet, see our website security guide.

Web and Enterprise Software vs Mobile App Maintenance

The two carry different maintenance profiles, and copying a contract template from one to the other produces nonsense clauses.

The practical consequence: on the web side your agreement should centre on downtime and security, while on mobile it centres on store compliance and version management. For the line-by-line post-launch budget on mobile, see app maintenance costs; if you are still deciding between delivery models, what web-based software is sets out the structural trade-offs.

If one vendor maintains both, keep a single contract but build two scope sections and two SLA tables. A merged table unfairly scores store-review delays as vendor SLA breaches.

Renewal and Switching Vendors: The Exit Clause

A software maintenance agreement is really tested at renewal and at exit. Before you renegotiate, put four numbers on the table: tickets opened and closed over the year, SLA compliance rate, hours-quota utilisation, and the list of security updates actually applied. Without those, you are negotiating on feeling rather than evidence — which reliably favours the incumbent.

If you are switching, the handover clause becomes the whole ballgame. It should specify:

• An access and asset inventory. Domain, DNS, hosting, repository, database, third-party accounts — registered to whom, and transferred how.
• Documentation delivery. Setup steps, environment variables, architecture notes, known-issues list.
• A transition period. How many days of question-and-answer support the outgoing vendor owes your new team, and whether it is billable.
• Data and log export. In what format, within what deadline.

Source code escrow addresses the same risk from another angle. As the Out-Law guidance notes, failure to maintain the software, or termination of the maintenance agreement, can be drafted as a trigger that releases escrowed source code to the customer. The same guidance raises a caution worth taking to your lawyer: linking termination of the maintenance agreement to termination of the software licence may raise competition law issues. On smaller custom projects the cheap equivalent of escrow is simpler — hold the repository under your own organisation account and grant the vendor access rather than the reverse.

Finally, test maintenance capacity while you are still choosing. Ask how many engineers staff support, how on-call rotation works, and where a ticket lands when the one developer who knows your system is on leave. The answers tell you more than the numbers in the SLA table. Our guide on how to choose a software development company covers the wider evaluation.

Frequently Asked Questions

Is a software maintenance agreement mandatory?

No — it is a commercial choice, not a legal requirement. But statutory defect liability under most contract regimes is time-limited and narrow, covering faults present at delivery rather than ongoing upkeep. If you want continuous patching, compatibility work and a response commitment, you need a separate maintenance agreement to create those obligations.

How much does annual software maintenance cost?

For packaged software, the documented benchmark is 20% or more of net licence fees for the first year, escalating annually; the GSA negotiation white paper treats that as standard publisher practice. For custom-built software, fees are usually set as a percentage of build cost or as a monthly retainer with an hours quota, and the drivers are SLA level, coverage window and the number of integrations.

What is the difference between maintenance and support?

Support handles user-facing questions and incidents; maintenance changes the software itself through fixes, compatibility work and improvements. Many contracts merge them under one heading, but splitting them produces better pricing and clearer service levels, because support is measured in hours and maintenance is planned in work items.

Should I negotiate response time or resolution time?

Resolution time is what determines your actual downtime, so it matters more. Response time only proves a ticket was acknowledged, which is easy to achieve and tells you little. A sound agreement commits to both separately, with target resolution times tied to the severity level.

Does a maintenance agreement give me the source code?

Not automatically. Code ownership and delivery need their own written clause, and in many jurisdictions an assignment of rights must be explicit about what is being transferred. Paying maintenance invoices does not create that transfer, so specify repository access, delivery format and ownership before signing.

What should I ask for when changing maintenance vendors?

Request an access and asset inventory, current documentation, a known-issues list, data and log exports, and a defined question-and-answer period for your incoming team. Negotiate all of it into the termination clause when you sign the original agreement — these are the hardest items to obtain once the relationship has ended.

What is normally excluded from maintenance scope?

New modules and screens, framework or database migrations, third-party licence and usage fees, content entry, infrastructure scaling driven by traffic growth, and end-user training are typically out of scope. Work driven by replacing a core technology is modernisation rather than maintenance, and it should be quoted as a project.

How long should the contract term be?

A one-year term with automatic renewal is the common choice, because it gives both sides a measurable performance period. Longer commitments can earn a discount, but only trade length for price if you also secure a short notice period and the right to terminate without penalty after repeated SLA breaches.

A software maintenance agreement is the quietest document in a software project and the one with the most leverage. Written well, nobody needs to open it after launch. Written badly, both parties read it during the first outage and reach opposite conclusions. The difference is rarely legal sophistication — it is whether scope and timings were written with concrete examples instead of adjectives.

If you already have software in production, the first step is not a new contract but an inventory: which runtime and library versions you depend on, whether your backups actually restore, who holds production access, and where the logs live. A scope clause written without that inventory is guesswork. To review the maintenance load on an existing system, or to start a new build with a maintenance plan attached from day one, get in touch or take a look at our web software development services.