Software Maintenance Contracts: What's Included And What To Check Before You Sign
What A Software Maintenance Contract Should Answer
What Is Covered?
How Fast?
Who Pays And Who Owns?
A software maintenance contract sets out what a provider will do to keep your software working after launch, how quickly they will respond when something breaks, what it costs, and what is not included. A good one covers bug fixes, security and compatibility updates, support hours, response and resolution times, and who owns the code, data and accounts.
Two kinds of agreement go by this name, and they need different checks. The first is the annual maintenance and support you pay a software vendor for a product you license, such as an accounting or ERP system. The second is a maintenance agreement for custom software built for your business, where a developer or partner looks after something you own.
This guide explains what each kind usually includes, where maintenance ends and new work begins, how service levels work in plain terms, how these contracts are priced, the terms that catch businesses out, and the questions to ask before signing. For what to budget, our guide to software maintenance cost after launch covers the numbers side.
Maintenance, Support And New Development Are Different Things
Many disputes over a maintenance contract come down to one question: is this request covered, or is it new work? The contract should draw that line clearly, and it helps to know the three categories before reading one.
Where Maintenance Ends
Maintenance
Keeping the software working as agreed
Support
Helping people use it and answering questions
New Development
Making the software do something it never did
Maintenance keeps the software doing what it was agreed to do. That includes fixing bugs, applying security patches, and updating the software when something it depends on changes, such as a browser, operating system, or another service it connects to.
Support helps people use the software: answering questions, walking a user through a task, or checking whether an odd result is a bug or a misunderstanding.
New development makes the software do something it never did before. Almost every maintenance agreement treats this as separate work, quoted and approved on its own.
The grey area is usually the middle ground: small changes, such as adding a field to a form or adjusting a report. Some contracts include a set number of hours for these, others price every change separately. Neither is wrong, but you should know which you are signing up to. Our guide to software maintenance cost describes the four kinds of maintenance work in more detail.
What A Software Maintenance Contract Usually Includes
Contracts vary, but a complete software maintenance agreement normally covers the following areas. If one is missing, it isn't necessarily a problem, but you should know what happens in its absence.
| Area | What it should state |
|---|---|
| Scope of maintenance | Which systems, modules or features are covered, and which kinds of work (bug fixes, security updates, compatibility changes) are included |
| Exclusions | What is not covered, in writing, so there is no argument later |
| Support hours and channels | When you can get help (business hours or around the clock), in which time zone, and how (email, phone, ticketing system) |
| Severity levels | How issues are classified, from critical to minor, with a short definition of each |
| Response and resolution targets | How quickly the provider will respond to and fix issues at each severity level |
| Security and dependency updates | How often third-party libraries, frameworks and platforms are updated, and how urgent security fixes are handled |
| Hosting, monitoring and backups | Whether these are included, and if so who is responsible when something goes wrong |
| Reporting | What the provider tells you each month or quarter about what was done |
| Change requests | How small changes and new features are requested, estimated and approved |
| Pricing and renewal | The fee, what triggers extra charges, the contract term, renewal terms and any price increases |
| Ownership and access | Who owns the code and data, and whose name the accounts and credentials are in |
| Exit and transition | What the provider will hand over and help with if the agreement ends |
Fig. 3: The main areas of a software maintenance agreement.
What's Usually Excluded
Exclusions are not a sign of a bad contract. A contract with no exclusions is usually one that hasn't been thought through, and that tends to cause more arguments, not fewer. What matters is that exclusions are written down and reasonable.
New features and changes to how the software works.
Problems caused by changes someone else made, such as another developer editing the code or staff changing settings they shouldn't.
Outages or changes in third-party services the software depends on, beyond making reasonable efforts to adapt.
Fixing data entered incorrectly by users.
Hosting and third-party license fees, unless the contract says they're included.
Major upgrades, such as moving to a new version of a framework, which may be treated as a project rather than routine maintenance.
The last point deserves a direct question. If a framework your software is built on reaches the end of its support, who pays for the upgrade? Contracts that leave this unclear often end in a surprise quote.
Service Levels In Plain English
A service level agreement, usually shortened to SLA, is the part of the contract that sets out how quickly the provider will act. It is where vague promises become measurable ones, so it's worth reading closely.
Response Time And Resolution Time
These are two different promises, and many contracts only state the first. Response time is how quickly the provider acknowledges your issue and starts working on it. Resolution time is how quickly the software is working again, either properly fixed or with a workaround in place. Both are usually counted from the moment you report the issue, so check that the contract says so.
Response Time Is Not Resolution Time
Severity Levels
Targets usually differ by how serious the issue is. The example below shows the structure; the targets you negotiate should reflect how much your business depends on the software and what you are paying.
| Severity | What it typically means | Example |
|---|---|---|
| Critical | The system is down or a core process can't run, with no workaround | Staff can't take or process orders |
| High | A major feature is broken, but there is a workaround | Invoices must be created manually while an export is fixed |
| Medium | Something is wrong but work can continue normally | A report shows the wrong date format |
| Low | Minor issue, cosmetic problem or question | A button label is misspelled |
Fig. 5: An illustrative severity structure. Agree the definitions, not just the labels, in writing.
Uptime Percentages
If the provider also hosts the software, the contract may promise an uptime percentage, meaning how much of the time the system will be available. The numbers can look almost identical while meaning quite different things. Over a 30-day month, 99% uptime allows about 7.2 hours of downtime, 99.5% about 3.6 hours, and 99.9% about 43 minutes. Check whether planned maintenance windows count toward that figure, and what happens if the target is missed, such as a credit on your next invoice.
How Software Maintenance Contracts Are Priced
There is no single standard price, so the useful comparison is how the fee is structured and what it leaves you exposed to. The main models are below. Many agreements combine two of them.
| Pricing model | How it works | Suits | Watch for |
|---|---|---|---|
| Annual fee on a license | A yearly fee for updates and support on software you license from a vendor | Off-the-shelf products and platforms | Annual increases, and rules that make it costly to stop or restart |
| Fixed monthly fee | A set fee for a defined scope and service level | Custom software with predictable needs | Scope that is vague about what counts as maintenance |
| Retainer with an hours allowance | A monthly fee that includes a set number of hours, with extra hours billed | Software that also needs regular small changes | Unused hours that expire, and the rate for extra hours |
| Time and materials | You pay for hours actually worked, at agreed rates | Stable software that rarely needs attention | No commitment to response times unless they are written in |
| Per incident | A fee each time an issue is raised and handled | Very low-use systems | Costs that spike when problems cluster |
Fig. 6: Common pricing structures, compared on the same terms.
Annual software maintenance fees for licensed software are often expressed as a percentage of the license price, but the percentage and what it is calculated on vary by vendor and by deal, so read the actual terms rather than relying on a rule of thumb. For what goes into the total bill, including hosting and staff time, see our guide to software maintenance cost after launch.
Vendor Maintenance Agreements: Terms That Catch Businesses Out
Published vendor policies are a useful way to see what these agreements contain, because they show the fine print that sits behind a quote. Oracle's software technical support policies, updated in August 2026, are one example (Oracle Software Technical Support Policies (opens in a new tab)). Its standard support includes program updates and fixes, security patches, tax, legal and regulatory updates where available, and help with service requests around the clock.
The same document shows two terms worth looking for in any vendor agreement. If support lapses and you later want it back, Oracle's reinstatement fee is 150% of the last annual support fee you paid for that program. And all licenses in a given license set must be supported at the same level, so you can't keep support on only some of them; you would have to terminate the unsupported licenses instead.
Oracle is an enterprise vendor and its terms are not typical of every product. The point is that similar clauses exist in many vendor agreements, and they are easy to miss:
Reinstatement fees for restarting support after letting it lapse.
All-or-nothing coverage, where you can't drop support on licenses you no longer use without ending them.
Automatic renewal with a short notice window to cancel.
Annual price increases written into the renewal terms.
End-of-support dates for older versions, after which updates stop even if you keep paying for something.
An end-of-support date is often the moment a system starts turning into a legacy problem. Our guide to legacy software modernization for growing businesses covers what to do when that happens.
Custom Software Maintenance Agreements: What To Get In Writing
When the software was built for you, the maintenance agreement is also about control. You own the software, but the provider looking after it often holds the knowledge, the access and sometimes the accounts. The agreement should make sure you could hand the work to someone else without starting over.
Code in a repository you control. The source code should live in an account your business owns, with the provider given access, not the other way round.
Accounts and credentials in your name. Hosting, domains, third-party services and admin logins should be registered to your business.
Documentation kept current. How the system is set up, deployed and backed up, updated as it changes.
Dependency updates as routine work. Keeping libraries and frameworks current should be part of maintenance, not a surprise project years later.
Knowledge handover on exit. A defined period of help if you move to another provider or bring the work in-house.
Ownership itself is settled in the development contract, so check that too. Under US copyright law, for example, software isn't one of the nine kinds of commissioned work that can count as "work made for hire" (U.S. Copyright Office, Circular 30: Works Made for Hire (opens in a new tab)). Copyright starts with the person who created the work, and a transfer generally has to be in writing and signed (U.S. Copyright Office, Circular 1: Copyright Basics (opens in a new tab)). So code written by an independent contractor can stay theirs unless the contract assigns it to you. Rules differ by country, and a lawyer should review significant contracts.
If a provider licenses software to you rather than transferring ownership, some businesses use source code escrow. That means a copy of the code is held by an independent third party and released to you under agreed conditions, such as the provider going out of business. It is less relevant when you already own the code and hold it in your own repository.
Whether an outside provider or your own team should handle maintenance at all is a separate decision. Our guide to in-house vs. outsourced software development covers that trade-off.
Questions To Ask Before You Sign
What exactly counts as maintenance, and what would you treat as new work?
How do you define each severity level, and what are the response and resolution targets for each?
What are your support hours, and in which time zone?
How and how often do you update the libraries and frameworks the software depends on?
Who pays when a framework or platform the software relies on reaches end of support?
What will you report to us each month, and in what form?
What happens to unused hours, and what do extra hours cost?
How much notice is needed to cancel or change the agreement, and how do renewals and price increases work?
If we end the agreement, what will you hand over, and how long will you help with the transition?
Answers to the first and last questions tell you the most. A provider that can define its scope clearly, and is comfortable describing how you would leave, is usually one that expects to keep your business by doing good work.
Red Flags In A Software Maintenance Contract
Scope described only in general terms, such as "ongoing support" or "keeping the system running."
Response times with no resolution times, or no severity definitions at all.
No written exclusions, which usually means disagreements get settled case by case.
The provider holds your code, hosting or accounts in its own name.
No reporting on what work was done.
Automatic renewal with a short cancellation window and uncapped price increases.
No description of what happens when the agreement ends.
One of these on its own may just need a clarifying question. Several together suggest the agreement protects the provider much more than it protects you.
How Fossilite Approaches Maintenance
The last of Fossilite's five stages is to hand over and improve: give the team a system it can own, use and improve as the business changes. Maintenance is part of that, and it starts before launch, with decisions about where code, data and accounts live and how the system is documented.
Because Fossilite begins with the work itself rather than a preselected technology, the aim is software built around the systems and data a business already relies on, which also shapes what ongoing maintenance needs to cover. If you are still choosing who should build or maintain your software, our guide on how to choose the right custom software development partner covers what to look for.
Frequently Asked Questions
These are the questions businesses ask most often when they are reviewing a maintenance agreement for the first time.
What Is A Software Maintenance Contract?
A software maintenance contract is an agreement in which a provider commits to keeping software working after launch. It usually covers bug fixes, security and compatibility updates, support hours, response and resolution times, pricing and exclusions. For custom software, it should also confirm who owns the code, data and accounts, and what happens if the agreement ends.
What Does Software Maintenance Include?
Software maintenance usually includes fixing bugs, applying security patches, updating the software when something it depends on changes, and keeping third-party libraries current. Many agreements also include monitoring, backups and user support. New features are usually excluded and priced separately, so check how the contract defines the boundary between maintenance and new work.
What's The Difference Between A Maintenance Agreement And A Support Agreement?
Maintenance keeps the software itself working: fixing bugs and keeping it secure and compatible. Support helps the people using it, by answering questions and handling user problems. Many contracts combine both as a software support and maintenance agreement, but it's worth checking that each is covered, since a support-only agreement may not include fixes or updates.
Is A Software Maintenance Agreement Worth It?
For software your business depends on, usually yes, because security updates and compatibility changes don't stop after launch. The question is whether the agreement matches what you need. A system used a few times a year may suit an as-needed arrangement, while a system the business runs on daily needs defined response and resolution times.
Can You Cancel A Software Maintenance Contract?
Usually, within the notice period the contract sets. Check the renewal date, the notice window and any early termination fees. For licensed software, also check whether restarting support later carries a reinstatement fee, and whether stopping support on some licenses means ending those licenses entirely.
What Should An SLA In A Maintenance Contract Include?
A useful SLA defines severity levels in writing, sets both response and resolution targets for each level, states support hours and time zone, and explains how performance is reported. If hosting is included, it should also state an uptime percentage, whether planned maintenance counts, and what compensation applies when targets are missed.
Who Owns The Code Under A Maintenance Agreement?
It depends on the original development contract, not the maintenance agreement alone. In some countries, including the US, a contractor can keep copyright in code it writes unless the contract assigns it to you, so check that assignment is in writing. The maintenance agreement should also confirm the code sits in a repository you control.
If you are also weighing whether an older system is worth maintaining at all, our guide to software development cost vs. maintenance cost compares the two over the full life of a system.