Application Maintenance Agreement: What to Include

Reviewed by the DESSS engineering team

An application maintenance agreement sets out what a support provider will do for your software, how quickly problems get attention and what you keep if the relationship ends. A good one prevents arguments on the bad days, when a report has failed at month-end and everyone remembers the conversation differently. Before signing, it helps to understand the different application maintenance services on offer, since the contract should match the model you choose. This guide covers what to include and what to compare. Have your attorney review the final wording.

Define Exactly What Is Covered

Vague scope causes more disputes than poor service does. List the applications, environments, integrations, reports and scheduled jobs included, then be equally clear about what is excluded.

Hosting often sits in a gray area. If an application goes down because a server failed, who responds? If a third-party API changes, is the fix included or charged separately? Write these boundaries down. A simple table showing who handles the application, database, operating system, network, backups and vendor relationships will settle many arguments before they begin.

Types of work

Name the kinds of work the agreement covers, because they are often priced differently.

• Corrective: fixing defects and restoring service
• Adaptive: responding to outside changes, such as a new tax rule or vendor API
• Preventive: cleanup, tuning and monitoring to avoid future incidents
• Perfective: new features and usability improvements

Many arguments come from one party treating a request as a defect and the other as an enhancement. Agree on a definition, plus a way to settle the disagreements that will still arise.

Agree on Severity Before You Need It

Severity levels should describe business impact in terms both sides can recognize. Avoid wording like "major" with no explanation.

For each level, give an example from your own business, then state what the provider commits to. Common measures include hours of coverage, time to first response and how often you will receive updates. Be careful with promises about time to resolve, since root causes can be unknown at the start. A commitment to a workaround is often more realistic for older systems.

Ask who decides the severity level, and how a disagreement gets escalated. The answer should name actual roles on both sides.

Choosing the Right Support Model

The contract follows from the model. Each suits a different kind of application.

Support needs can change. A dedicated team may make sense while a backlog is being cleared, with a lighter model afterward. Include a way to change models without renegotiating everything.

Change Control and Testing

Support work changes production software, so the agreement should describe how that happens safely. Cover who can request a change, who approves it and how it gets tested before release. Specify the environments involved, how releases are scheduled and how a failed change gets rolled back.

Emergency changes need their own rule. Fixes applied under pressure should still be recorded and reviewed afterward. If no test environment exists yet, make creating one an early deliverable.

Reporting You Can Actually Use

A monthly report should help you make decisions, not simply prove the provider was busy. Ask for incidents by severity, root causes, repeat problems, changes released, hours used against the plan and open risks. Add a summary of unsupported components when they apply.

A regular review meeting matters as well. Trends often show whether you need more prevention, whether one module deserves refactoring, or whether the time has come to plan a replacement.

Security and Data Handling

Support staff often have privileged access to production systems and sometimes to sensitive data. State how access gets granted, logged and removed, and whether anyone can work from outside the country. Cover how production data may be used in testing, as well as how quickly you will be told about a suspected incident.

If you handle health, payment or other regulated data, the agreement may need specific terms. Your compliance advisers should identify those requirements, and the provider should confirm in writing that it can meet them.

Ownership and Leaving

Plan the exit while everyone is still on good terms. The agreement should state that you own your code, data, documentation and accounts, and that the provider's own tools stay with the provider unless agreed otherwise.

Spell out what a handover includes: source code, build steps, runbooks, passwords, open tickets and a set period of cooperation with any new provider. Specify the charges for this work. A provider who resists a reasonable exit clause is telling you something important.

Agreement Checklist

Review your draft against this list before signing.

• ☐ Applications, environments and integrations are listed
• ☐ Exclusions and third-party responsibilities are stated
• ☐ Types of work are defined, including defects versus enhancements
• ☐ Severity levels include examples from your business
• ☐ Coverage hours and response commitments are clear
• ☐ Escalation contacts are named by role
• ☐ Change, testing and rollback steps are described
• ☐ Emergency change rules are included
• ☐ Reporting contents and review meetings are specified
• ☐ Access, data use and incident notice terms are written down
• ☐ Ownership of code, data and documents is stated
• ☐ Handover duties and charges are agreed
• ☐ There is a way to change the support model

Comparing Proposals

Put competing proposals into the same structure, since headline rates reveal very little without context. Check what each one excludes and how it treats out-of-hours work. Ask for examples of their reports and for references from customers running similar technology. Our software testing services page can also help you judge how a provider's release process stacks up.

Frequently Asked Questions

What is the difference between an SLA and a maintenance agreement?

A maintenance agreement sets out the whole relationship, including scope, responsibilities, charges, ownership and exit terms. A service level agreement, or SLA, is the part that defines measurable commitments, such as coverage hours, response targets and how they are reported. An SLA might be a section or an attachment, and it is only as useful as its definitions.

Should response times be guaranteed for legacy applications?

Response commitments are reasonable if the provider has reviewed the application and can staff the coverage. Resolution guarantees are harder, especially with old code, missing documentation or unsupported components. Agreeing on a target for a workaround is often more honest. Treat any provider offering firm resolution promises on software they have never examined with some caution.

Who owns fixes made during a support contract?

Generally you want the contract to say that changes to your application belong to you, with any exceptions listed clearly. Providers may keep general tools and know-how of their own, which is normal. Make sure you receive source code for every release, not just compiled files. Have your attorney confirm the wording, since ownership depends on what the agreement says.

How should unused support hours be handled?

Agree this upfront. Some bundles expire at the end of a period, while others roll over a limited amount. If hours would otherwise be lost, you might direct them toward documentation, tests or small improvements. Reports should show how hours were spent. That helps you judge whether the plan size still fits how the application behaves.

Reviewing a Support Proposal?

Contact DESSS to discuss your application and the kind of coverage it needs. We can explain how we would structure support, and what to ask if you are comparing several providers. This article is general information, not legal advice.