Software maintenance agreements

This guide is based on UK law. It was last updated in October 2008.

This guide gives an overview of the issues to address in an agreement between a software firm and its customer for the maintenance of software.

Maintenance obligations

Maintenance obligations must be clearly defined in the maintenance agreement, both in terms of their scope and the period of time in which they must be performed.

Issues which may impact upon the scope of services to be provided (and how much these will cost) are likely to include:

1. what constitutes a defect or fault in the software? Consider referring to an agreed specification in order to minimise disputes;
2. which types of defect or causes of defect (if any) are to be excluded from the maintenance obligation?;
3. the categorisation of faults for which maintenance is to be provided. Factors which are likely to influence this process are the nature of the user's business and their ability to pay the costs which will be incurred by the categories of fault selected;
4. from a drafting prospective, it is important that both parties understand the precise meaning of descriptions such as "level 1, level 2" or "priority 1, priority 2", so the maintenance agreement should clearly articulate what level of service is required of the maintenance provider in relation to each specified category of fault (both in terms of commitment to resolution and response time). It is also important to identify which party will be responsible for categorisation, and how any disputes in relation to the proper categorisation of faults will be dealt with;
5. the flexibility of the proposed fault categorisation. In order to make sure that any changing needs of the user can be appropriately dealt with, the maintenance agreement should allow the categorisation to be changed and/or the matter escalated if the user considers any responses too slow or insufficient for the fault concerned;
6. response times (and where possible resolution times) should be agreed and incorporated in the maintenance agreement as a measure for both parties of whether the supplier's maintenance obligations are being properly discharged. This is usually done in the form of service levels which should focus on obtaining acceptable response and resolution (or fix) time commitments and the right to service credits if these are not consistently met;
7. the hours during which support will be provided. The hours of cover should be appropriate to the requirements of the parties, and should be clearly set out. In addition, any requirement for out of hours or exceptional cover should be detailed, together with the arrangements required for invoking it. Consideration should be given to the different time zones in which the parties may be operating. Users may need support across different time zones. It is increasingly common to find suppliers are offering "follow the sun" support models i.e. the provision of the supplier's support service moves around the globe in order to provide extended or 24 hour support to customers in a particular time zone. This support model increasingly relie upon the ability to access remotely the users' IT systems. Remote access to IT systems raises important security and data protection issues which need to be addressed in the contract. In particular remote access by a US supplier to the IT system of a user based in Europe will almost inevitably require additional provisions in the contract to address the potential export of personal data to the US;
8. when should payment for maintenance services commence? Ideally the user should look to delay payment of maintenance until any relevant warranty has expired. Will payment be in advance or in arrears?;
9. will the supplier be expected to attend on site to fix faults? Does this include all of the users sites in all locations?
10. how are the charges for maintenance calculated? By reference to the number of hours or days of support provided to the user during an agreed period or on a fixed sum basis? Are expenses in addition to the charges?

Upgrades / technology refresh

There are a number of issues connected with the effect of changing technology upon the maintenance to be provided by the supplier, which include the following:

1. are new releases, versions, or upgrades to be included in the agreed fee? If the user will be entitled to a limited number of releases, versions, and/or upgrades, it is important to set this out clearly in the maintenance agreement. Often the maintenance agreement will not itself grant a licence to use such releases/upgrades so check the licence terms to ensure these items are included in the scope of the initial licence grant;
2. does the supplier intend to reserve the right to withdraw support and maintenance from old versions of the software (it is not uncommon to restrict the obligation to provide support to the current version of the software plus one earlier version);
3. the user may have good reasons for wishing to postpone installation of upgrades (e.g. upgrades/new releases may themselves cause problems to critical systems). A fair balance needs to be struck between the supplier's wish to ensure users are on the latest releases as against the users' ability to control and phase the installation of new upgrades to its systems. A new version may be very different from the existing version and the installation and transition to the new version may lead to additional costs for training, data conversion etc;
4. is continued maintenance dependent on the purchase by the user of any upgrades. If so, this should be stated clearly in the maintenance agreement;
5. how regularly are upgrades to be provided, and who will deal with any interoperability issues with existing software/hardware?;
6. will the supplier provide releases/upgrades to ensure compliance with changes in law?;
7. finally, are certain categories of fault to be fixed by reference to periodic upgrades rather than fixes?

Renewal and termination

As highlighted above, it is important for both parties that there is no ambiguity in relation to the extent of the obligations to maintain, the timescale in which those obligations must be completed, and the fees to be paid in respect of the maintenance provided.

The length of the relationship between the parties should also be considered, in particular, issues relating to termination and renewal of the maintenance agreement should be discussed at the outset.

For example:

1. does the maintenance agreement have a specified lifespan and then renew automatically? If there is automatic renewal, the maintenance agreement should specify how any change in price should be dealt with (a supplier will want to carve out the ability to increase price in order that the maintenance arrangement does not become unprofitable, while a user will seek to have this price increase restricted (for example by reference to RPI ));
2. if the software is modified by the user can the supplier cease maintenance? If not, will there be an impact on the fee to be charged?;
3. consider whether failure to maintain software in accordance with the maintenance agreement could potentially trigger the release from escrow of source code to the software?;
4. if the maintenance agreement is terminated, will it be practical for the user to obtain maintenance elsewhere (care should be taken in this area when drafting maintenance agreements as it is possible, for example, that any linking of the termination of the maintenance agreement to termination of the software licence may breach competition law).

Contacts