Articles · Contracts

2027-03-19 12 min EN / FR

Maintenance contracts: what they should and shouldn't include

A system goes live, and a few months later something breaks, a certificate expires, or a library needs a security update. Without a maintenance arrangement, the answer to "who fixes this?" is a scramble. With a badly written one, it is an argument about whether this was "included".

A maintenance contract is simply an agreement on who keeps the system healthy after delivery, how fast they react, and what that costs. It should give you predictability, not a new form of lock-in.

What maintenance actually covers

"Maintenance" is four different things, often mixed together:

  • Corrective: fixing bugs and failures
  • Preventive: updates, security patches, monitoring, backups, renewals
  • Adaptive: adjusting to external changes (a payment provider changing its API, a new PHP version, a new tax rule)
  • Evolutive: new features and improvements

Most contracts include the first two, sometimes the third, and almost never the fourth without extra billing. Make sure the contract says so explicitly.

What a good contract includes

Scope: what is covered

  • The exact systems and components (application, servers, database, integrations, domains)
  • What counts as a bug (the system does not do what was specified) versus a change request (you want it to do something new)
  • Which environments are covered (production, staging)
  • Whether third-party components (plugins, themes, connectors) are covered, and who is responsible when an update from a third party breaks something

Preventive tasks, listed

Vague promises like "we take care of everything" are not useful. List what happens and how often:

  • Security updates of the operating system, runtime and framework
  • Updates of plugins and dependencies
  • Backup monitoring and a restore test at a defined frequency (see backups that actually restore)
  • Certificate and domain renewal checks
  • Uptime and error monitoring
  • Log review and disk, memory and database health checks
  • A short periodic report of what was done

Response and resolution times

Distinguish response time (someone acknowledges the problem) from resolution time (it is fixed). Define severity levels:

Level Example Response Target resolution
Critical Site or ordering down Within hours Same day
Major Key feature broken, workaround exists Within a business day Within days
Minor Cosmetic or rare issue Within a few days Next planned release

The numbers are for you to negotiate. What matters is that they exist, that the hours they apply to are stated (business hours or 24/7), and that you know what happens when they are missed.

Availability and contact

  • How to report an incident (a channel that is actually monitored)
  • An emergency contact, and whether it is a person or a shared channel
  • What happens when the main person is on holiday or ill (see the single-point-of-failure issue in warning signs when hiring a freelance developer)

Included time, and the rate beyond it

Many contracts include a number of hours per month or year. Check:

  • What the hours cover (fixes, support questions, updates, small changes)
  • Whether unused hours carry over or expire
  • The rate for work beyond the included hours
  • How hours are tracked, and whether you receive a statement

Price and indexation

  • Fixed monthly or yearly fee, and what it includes
  • How and when the price can change, and with what notice
  • Third-party costs (hosting, licences, monitoring tools): included or passed through at cost? If passed through, do you pay them directly (preferable) or via re-invoicing?

Security and data

  • Access is limited and revocable, and credentials are managed properly (see offboarding and access removal)
  • Personal data handling is covered by a data processing agreement where relevant (see GDPR and test environments)
  • Incident notification: the provider tells you promptly when something affects your data or availability

Duration, renewal and exit

This is where maintenance contracts quietly become lock-in:

  • Initial duration (a year is common)
  • Automatic renewal: with what notice period to cancel? Long automatic renewals with a short cancellation window are a trap
  • Termination for convenience, with a reasonable notice period
  • Handover obligations at the end: documentation up to date, access transferred, support hours for transition (see the exit plan and contract clauses)

Need a maintenance arrangement that leaves you free?

We can help define scope, response times and exit terms, or take over monitoring and updates on infrastructure you own.

Ask us Infrastructure

What it shouldn't include

  • A penalty for leaving that makes switching unreasonable
  • Exclusive rights: a clause stating only the current provider may touch the system
  • Withholding of access, code or accounts during a dispute (see contract clauses)
  • Unlimited, vague scope at a very low price. If it looks too cheap, nobody is really watching the system
  • Silent price increases or new fees for things previously included
  • Ownership of fixes: improvements made during maintenance should belong to you like the rest of the deliverable

Different models for different needs

  • Pay as you go (time and materials). No monthly fee, you call when needed and pay the rate. Cheap for stable systems, but nobody is watching in between, and response times are not guaranteed. Suits small, low-risk sites with an up-to-date setup.
  • Fixed retainer. A monthly fee for preventive tasks and a block of hours. Predictable, and it keeps someone familiar with your system. Suits business-critical systems.
  • Monitoring only. The provider watches and alerts, and fixes are billed separately. A reasonable middle path.
  • Full managed service. The provider operates the system, with availability commitments. More expensive, appropriate when downtime is costly and you have no internal ability to react.

Choose according to the cost of an outage for your business, not according to the price alone. Ask yourself: what does one day of downtime cost us?

Questions to ask before signing

  • What exactly is covered, and what is excluded?
  • What counts as a bug and what counts as a change request?
  • What are the response and resolution times, and at what hours?
  • Who will work on it, and who replaces them when they are unavailable?
  • How many hours are included, and what happens to unused ones?
  • What does extra work cost?
  • Do you test backup restores, and how often?
  • How are third-party updates that break something handled?
  • How long is the contract, and how do I leave it?
  • What do I receive if I stop: documentation, access, support for transition?

Signs a maintenance contract is working

  • You receive a short regular report (updates applied, incidents, backup status, certificate dates)
  • Problems are found by the provider before you notice
  • Updates are applied in a test environment first, then to production
  • The documentation is updated after changes (see the documentation you should demand at delivery)
  • Costs match what was announced

Signs it isn't

  • You only hear from the provider when it is time to invoice
  • Nobody can tell you the date of the last successful backup restore test
  • Software versions on your server are years old
  • Every request is "outside the contract"
  • The provider is the only person with credentials, and you cannot see what they do

Common mistakes

  • Having no maintenance at all because "the site works"
  • Confusing hosting with maintenance. Hosting keeps the server running, it does not update your application
  • Paying for maintenance without ever checking what was done
  • Accepting long automatic renewals
  • Not defining what an emergency is
  • Letting the contract drift out of date as the system grows
  • Paying for "unlimited support" that is in practice unavailable

Checklist

  • Covered systems and environments listed
  • Bug versus change request defined
  • Preventive tasks listed, with frequency
  • Severity levels with response and resolution times
  • Emergency contact and replacement person identified
  • Included hours, carry-over rule and extra rate stated
  • Third-party costs paid directly by us, or clearly passed through
  • Data protection and access rules defined
  • Duration, renewal notice and termination clear
  • Handover obligations at the end written down
  • Regular reporting agreed

Related

From a vague retainer to clear terms

If you want a second look at scope, response times and exit before you renew, write us. We answer on substance.

Start a conversation All articles