They are two different things
Maintenance keeps the software healthy: security patches, dependency updates, fixing defects, keeping it running as the platforms underneath it change. It happens whether or not anyone reports a problem.
Support is what happens when someone does report one: triage, diagnosis, a fix or a workaround, and telling the person who reported it what is going on. It is reactive by definition.
A contract that says "support and maintenance" without separating them is where the arguments start. One side means "you will answer the phone", the other means "we will apply security updates".
What is normally included
- Security and dependency updates
- Libraries and platforms release fixes constantly. Software that is not updated does not stay still — it gets less secure while sitting untouched.
- Monitoring and alerting
- Knowing something is wrong before a customer tells you. If nobody is watching, your monitoring is your users.
- Defect fixes
- Things that were meant to work and do not. Worth writing down explicitly, because this is the line most often disputed.
- Small improvements
- Changes that are too small to be projects. Usually capped as a block of time per month, which is a reasonable way to handle it.
- New features
- Normally not included. If your agreement does not say so, assume both sides think the other is wrong about it.
The part most agreements get wrong
Access and ownership. Software is supportable by someone else only if the source code, the infrastructure and the accounts are yours and documented.
If the code lives in the supplier's repositories, the servers are on the supplier's account, and the only person who knows how deployment works is the person who built it, then you do not have a support arrangement. You have a dependency.
This is worth settling before launch, when you still have leverage, rather than during a handover you did not plan. The test is simple: if this supplier disappeared tomorrow, could a competent engineer pick it up from what you hold? If the answer needs a phone call to find out, it is no.
How it is usually priced
None of these is better than the others. The question is how much an hour of downtime costs your business, and whether that number justifies paying for availability you might not use.
- A monthly block of time
- A fixed number of hours, used for whatever needs doing. Simple, predictable, and the most common arrangement for smaller systems.
- A retainer with response times
- You pay for availability, with agreed response times by severity. Right when downtime genuinely costs money.
- Ad hoc
- You call when something breaks. Cheapest until the week you need someone and they are on another project.
Agree these before launch
What counts as an emergency, and how quickly someone responds to one. What counts as a defect rather than a change. Who holds the accounts and the credentials. Where the documentation lives, and whether keeping it current is part of the work.
All of these are easy conversations before launch and difficult ones at nine on a Friday evening.