Key takeaways
- A good contract says what is covered, how fast problems are handled and how issues are reported.
- Fixing bugs, updating dependencies and security patches are different from building new features, so check which is included.
- You should have access to your code, hosting and documentation at all times, not only while the contract runs.
- Check how to end the contract and what handover you receive.
What should a maintenance contract cover?
At minimum it should state which systems are covered, what kinds of work are included and how you ask for help. If you are unsure what support involves, start with what application support and maintenance actually cover.
What is usually included, and what is not?
- Bug fixes
- Correcting behaviour that does not match what was built. Check whether there is a limit on hours.
- Security updates
- Patching software and libraries as problems are found.
- Dependency and platform updates
- Keeping the software working as the tools beneath it change.
- Monitoring
- Watching for outages and errors. Ask whether alerts reach a person.
- New features
- Usually separate. Ask how changes are requested and priced.
Vague wording such as "reasonable support" causes disputes. Ask for plain descriptions and examples.
How fast should problems be handled?
Look for response and resolution targets by severity. A site outage and a spelling error should not have the same priority. Check the supplier's hours, and whether urgent help is available outside them.
What should you be able to see?
- a record of work done and time spent
- reports on incidents and their causes
- a list of known issues and planned updates
If you cannot see what is being done, you cannot judge whether the contract is worth renewing.
Who owns what?
You should have access to the code repository, hosting accounts, domains and documentation at all times. A contract that keeps these under the supplier's control makes leaving difficult. Ownership questions are covered on our ongoing support and ownership page.
What if the software is too old to maintain well?
Some systems cost more to keep running than they are worth. If fixes keep growing, read legacy system modernisation: repair, replace or leave alone before renewing.
What should you check before signing?
- Which systems and environments are covered?
- What are the response and resolution targets?
- How are changes requested and priced?
- How long is the term, and how do you end it?
- What handover do you get if you leave?
- Who is accountable when something fails?
If a supplier is reluctant to explain any of these in writing, treat that as information.
To talk about support for your software, contact us.