Custom software ships, and then someone has to own the bugs, the security patches and the dependency upgrades. If an agency or nearshore vendor built it, the software maintenance contract you sign next decides who does that work, how fast, at what price, and how hard it is to take it elsewhere. Most pages ranking for this search assume licensed or on-premise software. This one is for buyers of bespoke software, and it's a checklist of terms, not a template. Nothing here is legal advice, so have a lawyer review the real document.
What does a software maintenance contract cover?
It covers the work of keeping a live system working and current. Maintenance is commonly classified into four types, corrective, adaptive, perfective and preventive, a classification IEEE attributes to the ISO/IEC/IEEE 14764 standard. The standard itself is paywalled. Ask the vendor to price those categories separately. A single blended monthly number hides what you're actually buying.
New features aren't maintenance. Put enhancements through a change process with its own estimate, or they'll quietly eat the retainer.
Corrective, adaptive, perfective and preventive work
| Category | Typical example | Who usually pays (judgment) |
|---|---|---|
| Corrective | Fixing a defect found in production | Vendor during warranty, you after it |
| Adaptive | Updating for a new OS, browser or third-party API change | You, under maintenance |
| Perfective | Performance tuning, small usability improvements | You, ideally capped hours or a change request |
| Preventive | Dependency upgrades, refactoring, removing deprecated calls | You, and the first to be cut when budgets tighten |
The "who pays" column is our judgment, not a market rule. Preventive work is the one buyers skip and regret, because deferred dependency upgrades leave known vulnerabilities in place.
Warranty period vs paid maintenance
A warranty covers defects against the specification you accepted, for a stated period after acceptance. Maintenance is everything else. The distinction matters because a vendor can blur the two, billing you for fixes to bugs that were theirs to begin with.
No public benchmark gives a standard warranty length, so don't anchor on a number from a blog. Our judgment is to tie the warranty to acceptance instead: it starts on written acceptance, runs long enough to cover at least one full business cycle of real use (a month-end close, a seasonal peak), and restarts for the affected module when a fix is delivered. The clause that makes this work is the acceptance one, covered in the build-phase agreement clauses. If acceptance is vague, the warranty clock is arguable.
Pinsent Masons' guide advises customers to seek to delay maintenance payment until any warranty has expired. It dates from 2005 with an update in 2008, and it's UK-focused, so treat it as a prompt for negotiation, not current practice.
SLA tiers and response times
An SLA inside a maintenance contract should define severity levels, support hours and time zone, and what happens when the vendor misses a target (service credits are one common remedy). A common trap is the difference between response and resolution. Published targets are often first-response times: someone acknowledges the ticket. They say nothing about when it's fixed. If you need a fix target, write it separately, and expect it to be a goal with a workaround deadline rather than a guarantee.
For an illustration of how a vendor publishes this, AWS's support case documentation lists first-response times by severity. It's one vendor's scheme, not a market norm, and a small agency won't match it.
| Severity | AWS first-response time |
|---|---|
| General guidance | 24 hours |
| System impaired | 12 hours |
| Production system impaired | 4 hours |
| Production system down | 1 hour |
| Business-critical system down | Under 30 minutes (Business Support+), under 15 minutes (Enterprise), 5 minutes (Unified Operations) |
Copy the structure, not the numbers. Define "production down" in your own terms (checkout fails, login fails, data is wrong), then ask the vendor what it can staff. A 15-minute target from a team that works one time zone and no weekends is a number on paper.
Retainer, time and materials, or fixed fee for maintenance
Three structures cover most post-launch deals. daily.dev's guide to maintenance contracts lists them as a flat monthly fee, hourly work as needed, and a prepaid block of hours. In practice that means a capacity retainer, time and materials per ticket, or a block you draw down.
A retainer buys availability and predictability. Time and materials buys flexibility but gives the vendor little reason to answer quickly. A prepaid block sits between them, though you should read what happens to unused hours at the end of the term. The model-choice logic is the same as at build time. For notice periods, minimum terms and unused-hours mechanics, read the sibling guide on monthly versus hourly billing before you sign.
On cost, there's no authoritative average for maintaining custom software, and any percentage you've seen is likely a licence-maintenance ratio that doesn't transfer. Size it from your own history instead. Pull the last three to six months of production tickets from the build period, sort them by category above, and estimate hours per month for each. Add a buffer for dependency upgrades you've been deferring. That's your starting retainer, labelled as judgment, and you can test it against two vendor quotes.
EU clauses that bite during support
Support is when the vendor gets closest to your production system, so it's where EU rules start to apply to the contract.
Start with GDPR Article 28. If the vendor can access production personal data during support, even to debug, you'll need Article 28 processor terms in writing if the vendor acts as your processor: documented instructions, confidentiality, sub-processor rules, and deletion or return at the end. A build contract that covered only a staging environment may not cover this. See GDPR access and transfers when you outsource for how access and transfers play out.
NIS2 comes next. If you're in a sector the directive covers, it can put supply-chain security duties on you that reach your maintenance vendor. Whether you're in scope is a question for counsel. Our guide to the legal requirements for outside developers in Europe reads a maintenance retainer as a closer NIS2 call than delivery-only build work.
Then the Cyber Resilience Act. The Commission's page on the Cyber Resilience Act says the regulation entered into force on 10 December 2024, with reporting obligations applying from 11 September 2026 and the main obligations from 11 December 2027. Whether it reaches a bespoke system you run for your own use is a legal question, not one we can answer here. What you can do now is ask the vendor to commit to vulnerability handling and notification duties in the contract, so you aren't renegotiating in 2027.
Exit and handover terms
Write the exit before you need it. The contract should set a notice period you can live with, and a handover package that's defined by list rather than by "reasonable cooperation": the repository with full history, infrastructure as code, environment configuration, secrets rotated to your control, runbooks, a dependency list, and a set number of knowledge-transfer hours. Add that the vendor can't hold your tooling or accounts hostage.
If the code is held only on the vendor's systems, consider escrow, with release triggered by, for example, the vendor failing to maintain the software (Pinsent's guide flags this trigger). Insolvency is also a common trigger to ask for; have your lawyer draft it. For the full inventory of what to take back, see moving outsourced work in-house. Taking those items on day one costs far less than demanding them in a dispute.
Maintenance contract checklist
| Clause | What to write | Red flag |
|---|---|---|
| Scope categories | Corrective, adaptive, perfective, preventive listed and priced separately | One blended fee, no definitions |
| Enhancements | Handled by change request with its own estimate | "Reasonable improvements included" |
| Warranty | Starts on written acceptance, defined defects, restarts on fixes | Fixes billed as maintenance during the warranty |
| Severity levels | Your own definitions of down, impaired and general | Vendor-defined severity only |
| Response vs resolution | First-response targets, plus a workaround target for top severity | Response time presented as a fix time |
| Support hours | Hours, time zone, holiday cover, escalation contact | "Business hours" with no zone |
| Credits and remedies | Service credits and a termination right for repeated misses | No consequence for missing targets |
| Data terms | Article 28 processor terms covering production access | Vendor can reach production data with no DPA |
| Notice and term | Notice period and minimum term stated, unused-hours rule explicit | Auto-renewal with price escalators |
| Handover package | Repo, infra code, secrets, runbooks, dependency list, transfer hours | "Reasonable cooperation" only |
What post-launch support to buy from your build vendor
The decision for a CTO or founder signing this is simple to state: do you buy support from the vendor that built the system, move it to another vendor, or hire in-house? Our judgment is to keep the build vendor for the warranty period and for corrective and adaptive work, since they know the code, and to buy it on a short term, not a long one. Keep the switch open with four terms: warranty tied to written acceptance, an SLA with your own severity definitions, a handover package defined by list, and a notice period short enough that leaving never costs a year of fees.
Finance should check renewal, notice and price escalators before signing, because those clauses decide the real cost, not the monthly fee. For the wider set of contract, IP and data terms around this decision, read EU engineering hiring compliance: contracts, IP and GDPR. If you'd rather add an engineer to your own team than renew a vendor, HighCircl's EU hiring service has no minimum hour commitment.
FAQ
What is the difference between an SLA and a maintenance contract?
A maintenance contract is the whole agreement: what work is covered, how it's priced, and how you exit. An SLA is the part that sets service targets such as severity levels, response times and credits. You can have a maintenance contract with no real SLA, which usually means no enforceable speed.
Is a warranty the same as a maintenance agreement?
No. A warranty covers defects in what was delivered against the accepted specification, for a stated period, and is usually part of the build deal, so check whether your contract prices it separately. Maintenance covers ongoing work after that, and is paid. If a vendor bills you for fixing a defect inside the warranty window, ask which clause allows it.
How long should a software warranty period be?
There's no sourced market norm, so negotiate by logic. Start the clock at written acceptance and make it long enough to see real production use, including your busiest period. Our judgment is that a warranty shorter than your longest business cycle isn't testing the software at all.
Can I move maintenance to another vendor, and what must the contract allow?
Yes, if the contract lets you. It needs a workable notice period, a handover package defined by list, knowledge-transfer hours, and no restrictions on bringing in a third party to work on the code. Without those, switching is possible but slow, and the delay is where vendors hold the stronger hand.
How much does software maintenance cost?
There's no reliable public average for custom software, so we won't give a percentage. Size it from your own ticket history: estimate monthly hours by maintenance category, add a buffer for deferred upgrades, and compare two quotes against that number.