A software maintenance agreement is the contract that commits a supplier to fixing defects in live software, applying security and compatibility updates, making small improvements and supporting users, within agreed timescales and rules. A good one goes well beyond "we will provide support": it spells out what is included, how quickly a fault will be handled, who has to prove what, and what gets handed over if you part ways.
Key takeaways
- A maintenance agreement picks up where the development contract ends, because software starts to age on the day it goes live.
- Define scope through four types of maintenance: corrective, adaptive, perfective and preventive.
- Write response time and resolution time separately, and define each priority level with concrete examples.
- Verizon's 2026 DBIR found that exploiting vulnerabilities is now the most common way into a breach, so security patching cannot sit outside the agreement.
- Agree up front how source code, access and documentation are handed over when the agreement ends.
What do you lose without a maintenance agreement?
Bespoke software does not stand still after delivery. Operating systems, databases, browsers, integrated services and regulations keep changing, and users find bugs that testing missed. Without an agreement, every fault starts with a fresh negotiation, and at the most urgent moment the supplier sets both the price and the priority.
That dependency bites hardest in smaller firms. Turkey's statistics office, TÜİK, reported in its 2026 ICT usage survey of enterprises that only 15.2% of enterprises employ ICT specialists, falling to 10.8% among firms with 10 to 49 staff. In most businesses nobody in-house can fix the software, so a written maintenance agreement becomes the main safety net.
According to Verizon's 2026 Data Breach Investigations Report, exploitation of vulnerabilities became the most common initial access vector for breaches, at 31%. If nobody has agreed in writing who applies patches for your libraries and frameworks, and how fast, you have left a door open. We cover the in-house side of this in our guide to the patch management process.
What should a software maintenance agreement cover?
Most scope disputes come down to one question: is this a bug or a new request? The cleanest answer is to split maintenance into the four types described in ISO/IEC 14764 and state how the agreement treats each one.
| Maintenance type | What it means | Example | Typical treatment in the agreement |
|---|---|---|---|
| Corrective | Fixing delivered functions that do not work as specified | Invoice totals are calculated wrongly | Included in the fee, subject to priorities and timescales |
| Adaptive | Keeping up with a changing environment | An integrated service changes its API version; a statutory format is updated | Usually included, with a cap for large changes |
| Perfective | Improving performance and usability, small new requests | Two extra columns in a report, a faster screen | Drawn from a monthly pool of hours |
| Preventive | Reducing risk before problems appear | Library and security updates, log and disk checks | Scheduled, and evidenced in a report |
New modules, new integrations or requests that change a business process are development, not maintenance. Quote them separately and define them the way you would in a technical specification. A table drawing that line settles most annual arguments.
Scope also has a "where" dimension. If the software runs on your own servers, state separately who is responsible for the server, the operating system and the backups. Your choice between SaaS and on-premise software largely decides how those responsibilities are split.
How do you write the SLA? Response time is not resolution time
The service level agreement (SLA) is the measurable heart of a maintenance contract. The classic mistake is a single line promising "response within four hours": someone will pick up the phone, but nothing says the problem will be fixed. A sound SLA separates at least three timescales: first response, workaround and permanent fix.
Priority levels need concrete examples too, or each side will read "critical" the way that suits them. Use the framework below as a starting point and agree timescales according to how critical the software is to you.
| Priority | Definition and example | What is measured |
|---|---|---|
| P1 Critical | The system is completely unusable or data is at risk; orders cannot be taken | First response, workaround and permanent fix, including out of hours |
| P2 High | A core function is down but a workaround exists | First response and resolution time, within working hours |
| P3 Normal | A fault on one screen that does not stop the workflow | Which planned release will carry the fix |
| P4 Request | Questions, training, minor tweaks | Planned, drawn from the pool of hours |
Alongside the timescales, write down how they are measured: which channel tickets are raised through, when the clock starts and stops, and which figures appear in the monthly report. Tracking indicators such as average repair time using the MTTR and MTBF definitions moves the conversation from impressions to data. Be clear, too, about what happens when the SLA is missed: a fee reduction, extra hours, or a right to terminate after repeated breaches.
Ten clauses to check before you sign
Read the draft against this list. If a clause is missing or vague, clarify it in writing before signing.
- Scope table: which of the four maintenance types are included, and where development begins.
- Priority definitions and timescales: an example, first response and resolution time for each level.
- Support channels and hours: ticketing, phone, out-of-hours contact and who is allowed to call.
- Pool of hours: how many improvement hours you get each month, whether unused hours roll over and how overruns are charged.
- Security updates: how quickly critical patches are applied and how they are reported.
- Backups and recovery: who holds the backups, how often they run and whether restores are tested.
- Release and testing process: changes tried in a test environment first, with acceptance and rollback plans.
- Reporting: a monthly list of tickets, resolution times and preventive work carried out.
- Source code and access: where the current code is kept and in whose name the servers and accounts are registered.
- Term, termination and handover: renewal terms, how prices are reviewed and the supplier's handover duties on exit.
Clause six often exists only on paper, so check that backups genuinely restore by following the steps in our guide to backup and restore testing. Clause nine matters enough to deserve its own article, which you will find in software contracts and source code.
How is the maintenance fee set?
Three models are common: a fixed monthly fee, pay-as-you-go hours, or a mix. A fixed fee is predictable, but with vague scope you soon hear "that is not included". Hourly billing is flexible, yet in an outage neither time nor cost is predictable.
For most businesses the best balance is a fixed base fee that secures corrective and preventive maintenance, with improvements managed through a monthly pool of hours. We look at what drives the price, including total cost of ownership, in our article on software project cost. Judge the annual fee not on its own but against what a day of the software being down would cost your business.
Common mistakes in maintenance agreements
The first mistake is leaving maintenance until development is finished, by which point the negotiating power has passed to the supplier. Asking for maintenance proposals when you compare suppliers should be part of choosing a software company.
The second is never asking for a monthly report, so nobody knows whether the SLA is met. Carry your milestone discipline into maintenance with our framework for supervising software contractors.
The third is trying to keep ageing foundations alive through maintenance alone. Software running on a language version or framework that is out of support gets more expensive to patch every month. At some point it makes more sense to redirect the maintenance budget into a legacy software modernisation plan. NIST SP 800-40 Rev. 4 frames patching as a critical part of preventive maintenance and a normal cost of doing business, so an update budget is not optional.
How does Digital Bridge handle maintenance and support?
Digital Bridge has delivered software and hardware projects from a single team in Adana since 2013. Our custom web software projects start with an on-site visit and needs analysis and proceed on a written proposal that sets out scope and cost; after go-live you still deal with the team that built the system.
- Technical support 24/7: support carries on without interruption once your users start working with the system.
- New needs as separate modules: later requests are added without breaking what already works.
- You hold the source code: the source code, database schema and technical documentation are handed over at delivery, so you are not obliged to buy support from us and the relationship rests on service quality rather than lock-in.
You can see our full range of ERP, CRM, warehouse and integration work on the software solutions page, and learn about our team and how we work on the about us page. For more guides like this one, browse the software topic hub.
What is the next step?
Answer three questions about the software you rely on today. Who will you call, and through which channel, when something critical breaks? When was the last security update applied? If you parted ways with your supplier tomorrow, would you hold the code and the access? If even one answer is unclear, get in touch through our contact page or on +90 850 346 41 09, and we will talk through the maintenance and support your software needs, or plan your new project properly from the start with life after go-live in mind.