Application maintenance outsourcing: what it covers, what the contract must say, and a worked example

Application maintenance outsourcing means handing the maintenance of a business application to an external provider under a contract. The provider fixes defects, applies updates, keeps the application working as its environment changes and builds enhancements, within a defined scope, against agreed service levels and for a price set in advance. What separates it from "call the developer when something breaks" is the contract: it states what is covered, how fast, for how much, and how you get out.

Large companies buy this as part of application management services (AMS) or application development and maintenance (ADM) deals. This guide is written for the other end of the market: a small or mid-sized business with one to a handful of custom applications and no development team of its own. If you want to know what maintenance involves technically once software is live, read our guide to business application maintenance. This one is about how to outsource it, and what to put in the contract so the promises hold.

When companies outsource application maintenance

It usually happens in one of three situations:

• after a custom build, when the company that built the application keeps maintaining it;
• when changing provider, because the original developer is gone, too slow or too expensive, and a new team takes over an existing application;
• when an internal team refocuses, and hands stable applications to an outside provider to concentrate on new projects.

In every case, the business keeps control of its needs and priorities. The provider takes on the technical execution and commits to measurable results.

Application maintenance, managed services, staff augmentation: what is what

These terms overlap in sales material. Telling them apart prevents you from signing a contract that does not cover what you think.

The point to watch is the boundary between application and infrastructure. When the application goes down, is it the code or the server? If two providers share the system, the contracts must say which one receives the alert, which one diagnoses, and how they work together. Otherwise each points at the other while your staff wait.

The types of maintenance covered

Software maintenance is traditionally split into four categories, the ones found in the international standard on software maintenance, ISO/IEC/IEEE 14764. They make a good basis for structuring a contract.

• Corrective maintenance repairs a defect that has been observed: a wrong calculation, a screen that freezes, an export that fails.
• Preventive maintenance fixes a latent problem before it causes a failure: upgrading a vulnerable library, hardening a weakness spotted by monitoring.
• Adaptive maintenance keeps the application working as its environment changes: a new browser or operating system version, a partner's API that changes, a new legal requirement.
• Perfective maintenance, or enhancement, improves the application or adds features at the business's request.

The split has a financial consequence. The first three belong to the normal running of the application and are usually included in the recurring fee. Enhancements depend on your requests and are priced separately. The line between a fix and an enhancement is the first source of disputes in outsourced maintenance, so the contract should define it, with examples.

The life cycle of a maintenance contract

A maintenance contract does not start with bug fixes on the day it is signed. It normally goes through four phases.

1. Knowledge transfer

The provider collects the code, access, documentation and database, then audits the application. Can it be built and deployed from source? What are its dependencies, weak points and business rules? When the application comes from another provider, this phase is decisive; see our software audit before takeover checklist.

2. Transition

The new provider takes over gradually, sometimes alongside the outgoing one. Service levels do not fully apply yet. It is a learning period, and it must have an end date.

3. Steady state

The provider handles requests within the agreed times, applies updates, delivers enhancements and reports on its activity at regular intervals.

4. Exit

At the end of the contract, the provider hands over everything a successor, or your own team, needs to continue: up-to-date code, documentation, access, deployment procedures and the request history. This is negotiated at signature, never at separation. Our guide to avoiding vendor lock-in lists what you should be able to get back.

What the contract must say

Here are the clauses to check, in the order in which their absence causes trouble.

Scope. Which applications, which versions, which environments (production, staging, test)? Who on your side can raise a request? Are integrations with other systems included?

Severity levels. A complete production outage does not deserve the same response as a typo on a screen. Three or four levels, defined by their effect on your business, each with an example, are enough.

Which times, exactly. A serious contract separates three measures: the response time (someone has read and qualified the request), the workaround time (the business can carry on, even in a degraded way) and the resolution time (the permanent fix). A single "four hours" for everything means very little. State the hours covered as well: business hours, extended hours or 24/7 on-call.

Fix or enhancement. Who decides whether a request is a defect or an enhancement, and what happens if you disagree? A simple rule: a defect is anything that contradicts the documentation or behaviour accepted during user acceptance testing.

Price. What the fee includes, how enhancements are priced and how the price is reviewed over time.

Reporting and governance. Requests opened and closed, times met per severity level, status of security updates. A monthly report and a quarterly review are enough for most SME business applications.

Security and personal data. A maintenance provider almost always has access to personal data, which makes it a processor under the GDPR (and the UK GDPR). The contract must then include the terms required by Article 28: processing only on your instructions, confidentiality, security measures, rules on sub-processors, and deletion or return of data at the end.

Ownership and access. The code repository, hosting and third-party service accounts should be in your name, or accessible to you at any time. Rights to work produced during the contract are defined case by case in the contract, as for the original build. Our article on software development contract clauses covers the wording.

Exit. What is handed over, how quickly, at what price and with how much help for the successor.

Pricing models

There is no published standard price for application maintenance: it depends on the application's size, its condition, the response times you need and the hours covered. The pricing models, on the other hand, are few, and they do not share risk the same way.

A fixed fee combined with a price list per task is a common arrangement: routine maintenance has a fixed price, and each enhancement has a known price before it starts. To see why time and materials leaves the risk with the client, read our comparison of fixed price vs time and materials.

A worked example

The following example is fictional, built to show how a contract works in practice. A distribution company uses a web application to manage orders. It was built a few years ago by an agency that has since closed. About twenty people use it every day.

Scope. The order application, its integration with the accounting package, and the portal where customers track deliveries. Hosting stays with a separate managed service provider.

Severity levels.

These times are illustrative. They are negotiated according to how much the application matters to the business, and every shorter commitment has a price.

Price. A monthly fee covers defect fixes, security updates and adaptation to changes in the environment. Enhancements are priced from a task price list, with a quote approved before each one starts.

A request, start to finish. On a Monday, the export to accounting fails. The office manager opens a ticket, classed as major. The provider picks it up that morning, finds that the accounting package has changed its expected file format, delivers a workaround the same evening, then a permanent fix tested in staging. Because the cause is a change in the environment, it is adaptive maintenance: covered by the fee, no quote needed.

Governance. A report each month (requests, times met, updates applied) and a quarterly meeting to prioritise enhancements.

When outsourced maintenance is the wrong answer

• The application is at the end of its life. If every fix breaks something else and the technology is no longer supported, paying for maintenance funds the decline. Decide on a replacement first; see replacing unsupported business software.
• The product changes every week. Software at the heart of what you sell, evolving continuously, needs a dedicated product team rather than a maintenance contract.
• Nobody on your side can make decisions. Outsourcing moves execution, not ownership. Someone has to prioritise requests and accept deliveries.
• The project was abandoned halfway. An unfinished application is not maintained, it is rescued; that is the subject of our guide to software project rescue.

Common mistakes

• Signing without a knowledge transfer phase. The provider commits to response times on an application it does not know, then blames the code for every delay.
• Confusing response time with resolution time. "Four hours" may mean a ticket was read, not that the problem is solved.
• Leaving accounts in the provider's name. On the day you change provider, you find that the repository and hosting are not yours.
• Squeezing out preventive maintenance. Users never see it, so it is the first thing cut when the fee is too tight, and it is what prevents serious incidents.
• Never testing the exit. A contract may promise documentation; check every year that it exists and is current.

How LPR Studio approaches it

We do not sell staff augmentation, and we do not offer maintenance as billed days. For the applications we build, maintenance is part of the product. On the subscription formula, hosting, maintenance and enhancements are covered by one monthly amount, and we remain the publisher and operator of the application, with rights defined case by case in the contract. On a fixed price build, the maintenance contract is negotiated at the same time as the development, not after delivery.

If your current application has reached the limit of what maintenance can do, the first step is to see what comes next: we build a free visual prototype, presented on a video call within 5 working days, before any commitment.