What a Software Maintenance and Support Agreement Should Include

Software is not finished when it launches. Operating systems update, browsers change, libraries publish security fixes, tax rules evolve and the business itself changes. A maintenance and support agreement is how you make sure someone is responsible for all of that, on terms you understood before anything went wrong.

This guide explains what a good agreement covers, the clauses worth reading twice and the red flags to watch for. It is practical guidance, not legal advice; have a lawyer review any contract you sign.

Maintenance vs support vs AMC: the terms explained

• Maintenance is work on the software itself: fixing defects, applying updates, keeping it compatible and secure.
• Support is help for the people using it: answering questions, investigating issues, restoring service when something breaks.
• AMC (annual maintenance contract) is the term most UAE buyers use for an agreement that bundles maintenance and support for a fixed period, usually a year, renewed annually.

The labels matter less than what is written underneath them. Two agreements both called an "AMC" can cover very different things.

Types of maintenance

Corrective

Fixing defects: things that do not work as they were specified to. This is what most people picture when they think of maintenance.

Adaptive

Changes needed because the environment changed rather than because the software was wrong: a new operating system version, a payment gateway changing its API, or new regulatory requirements such as UAE e-invoicing. Adaptive work can be significant, and agreements often say little about it.

Perfective

Improvements: better performance, small usability changes, minor enhancements. The line between perfective maintenance and new features is where most disputes happen.

Preventive

Work that stops problems before they occur: dependency upgrades, removing deprecated code, improving monitoring, reviewing logs and capacity. Easy to skip, and expensive when skipped for years.

Clauses every agreement should cover

Scope and exclusions

Good agreements list exactly which systems, environments and components are covered, and what is excluded. Typical exclusions: new features, issues caused by third-party systems, problems caused by changes the client made, and data correction after user error.

Ask: "Is adaptive maintenance for regulatory changes included, or quoted separately?"

Service levels: severity, response and resolution

An SLA should define severity levels, then commit to a response time and a target resolution or workaround time for each. Response means someone has acknowledged and started work; resolution means the issue is fixed or worked around. Do not confuse the two.

Ask: "Who decides the severity of an issue, and what happens if we disagree?"

Hours of cover and channels

State the hours support is available, the time zone, whether UAE weekends and public holidays are covered, and how issues are reported: ticketing system, email, phone or messaging. Critical systems may need out-of-hours cover for severe incidents only.

Ask: "If our system goes down on a Saturday, what happens?"

Updates, security patches and dependencies

Modern software depends on frameworks and libraries that publish security fixes regularly. The agreement should say how quickly critical security patches are applied, how dependencies are kept current and how the vendor monitors for vulnerabilities. See our web application security guide for why this matters.

Ask: "When did you last update the framework this system runs on?"

Hosting, backups and monitoring

If the vendor hosts or manages the infrastructure, the agreement should cover uptime commitments, backup frequency and retention, how restores are tested, monitoring and alerting, and where data is hosted. If you host it yourself, be clear about where their responsibility ends.

Ask: "When did you last test restoring our backup?"

Change requests vs maintenance

Define how new work is requested, estimated, approved and billed, and how it differs from maintenance. Without this, every request becomes an argument about whether it is "a bug or a feature".

Pricing models

• Retainer — a fixed fee per month or year for defined coverage. Predictable, but check what happens to unused capacity.
• Hours bank — a block of pre-purchased hours drawn down as work happens. Flexible; check whether hours expire and how usage is reported.
• Pay as you go — billed per request at agreed rates. Lowest commitment, but usually no guaranteed response times.

Code ownership, documentation and exit

The clause most often missing. The agreement should confirm who owns the source code, that you have access to the repository, that documentation will be kept current, and what the vendor will do to hand over to another provider if the agreement ends: access credentials, deployment instructions and a reasonable transition period.

Data protection

If the vendor can access personal data in your system, the agreement should address how they handle it, consistent with the UAE data protection law. That includes confidentiality, access controls and what happens to data copies when the agreement ends.

Sample severity levels (illustrative)

The definitions below are examples to help you read an SLA. The response and resolution targets attached to them should be agreed with your provider based on how critical the system is; they are not a statement of any particular provider's terms.

• Severity 1, critical — the system is down or a core function is unusable for all users, with no workaround. Example: nobody can log in, or invoices cannot be issued.
• Severity 2, high — a major function is impaired for many users, or a workaround exists but is impractical. Example: reports fail to generate.
• Severity 3, medium — a function is impaired but a reasonable workaround exists. Example: an export produces the wrong date format.
• Severity 4, low — cosmetic issues, questions and minor requests. Example: a label is misspelled.

Red flags in maintenance contracts

• No list of exclusions, which usually means disputes later.
• No exit or handover clause.
• The vendor retains ownership of the code, or you have no repository access.
• Commitments limited to "reasonable efforts" with no defined response times.
• No mention of security patches or dependency updates.
• Backups mentioned but never tested.
• Automatic renewal with large price increases and short notice periods.

Reporting and reviews

A good agreement does not just promise work; it shows you what was done. Ask for a regular report, monthly or quarterly, covering tickets raised and resolved by severity, whether service levels were met, security updates applied, hours used against any allowance, and recommendations for the coming period. A short review meeting at the same interval keeps the relationship honest and surfaces problems before they become disputes.

Taking over from another provider

If you are moving maintenance from one provider to another, plan the handover rather than switching overnight. The new provider will need:

• Full access to the source code repository and its history.
• Credentials for hosting, domains, databases, third-party services and app store accounts.
• Deployment instructions and any build or release scripts.
• Documentation of integrations, scheduled jobs and known issues.
• A period of overlap, so questions can be answered while the outgoing provider is still engaged.

Expect the new provider to start with a review of the code and infrastructure. It is the only responsible way to accept support for a system they did not build.

Checklist before you sign

• Covered systems, environments and components are listed.
• Exclusions are listed.
• Severity levels are defined, with response and resolution targets for each.
• Hours of cover, time zone and holiday coverage are stated.
• Security patching and dependency updates are included.
• Hosting, backup, restore testing and monitoring responsibilities are clear.
• The change request process is defined.
• Pricing model, rates and renewal terms are clear.
• Code ownership, repository access and documentation are confirmed.
• Exit and handover obligations are specified.
• Personal data handling is addressed.
• Regular reporting on tickets and work done is included.

Related reading

If maintenance has become a constant firefight, the system itself may be the problem; see rebuild, refactor or replace. If you are choosing a new provider, how to choose a software development company covers what to look for. Our own software maintenance and support services are set out on the service page, and you can contact us to discuss terms for your system.