Short answer: maintenance is not "fixing bugs when they happen". It is a set of workstreams with their own cadence — security patching, dependency and runtime upgrades, monitoring and backup verification, incident response, and a capacity allowance for platform change. Define each one, decide who owns it, and fund it as a line item. Teams that treat maintenance as goodwill discover the gap at the worst possible moment: when a critical patch cannot be applied because the upgrade path was never maintained.
Maintenance is a plan, not a favour: patch, upgrade, monitor, and budget for change.
Launch changes the question, not the responsibility
Before launch, the question is "can we build it". After launch, the question is "who keeps it healthy, at what cadence, and with what authority to interrupt feature work". Most disputes about maintenance are really disputes about that last part: whether the team can stop and patch when something urgent appears.
The clean way to structure it is to separate workstreams with different rhythms, because mixing them produces the familiar pattern where the roadmap consumes all capacity and maintenance only happens after an incident.
| Workstream | What it covers | Typical cadence | Cost of skipping |
|---|---|---|---|
| Security patching | Runtime, OS, and dependency vulnerabilities that are reachable in production | Continuous triage, patched by severity | Exploitable exposure with a known fix available |
| Dependency and runtime upgrades | Framework, language, and library upgrades, including majors | Quarterly review, planned majors | Compounding upgrade debt and blocked patches |
| Monitoring and alerting | Error tracking, uptime, cost and queue alerts, alert routing | Continuous, reviewed monthly | Failures discovered by customers |
| Backup and restore verification | Backup execution, restore drills, retention and offboarding | Restore test quarterly | Data loss with no proven recovery |
| Incident response | On-call path, severity definition, communication, postmortems | As needed, drilled annually | Longer outages, no learning loop |
| Platform change allowance | Small improvements required to keep the system current | Budgeted per quarter | The system degrades until a rewrite is the only option |
The last row is the one organizations most often omit, and it is the one that prevents a rewrite from becoming the only option three years later.
Separate reactive support from roadmap work
A maintenance agreement should state two different things: a reactive capacity for unplanned work, and a planned capacity for the workstreams above. Conflating them means unplanned work always wins, because it is loudest.
An illustrative split for a mid-sized product: 15 to 25 percent of engineering capacity per month is a common range for maintenance on a system that is actively changing, with the reactive share bounded so it cannot consume the whole allowance. When reactive work exceeds its share for two consecutive periods, that is a signal to invest in the underlying cause, not to add more reactive capacity.
Whatever the numbers, the mechanics matter more:
- Reactive work is triaged, sized, and reported like any other work, so it is visible.
- Planned maintenance is scheduled in advance and protected; a quarter with no maintenance window is a decision, and it should be recorded as one.
- The budget is reviewed at a fixed cadence — monthly for reactive, quarterly for planned.
- If reactive work exceeds its allowance, the team raises it as a delivery risk, in writing, with the trade-off stated.
Define response expectations without pretending everything is urgent
Severity definitions are useful when they describe the business impact rather than the emotion of the reporter. A workable model:
| Severity | Definition | Expected first response | Target resolution |
|---|---|---|---|
| Critical | Production is unavailable, data is at risk, or security is actively compromised | Within the hour, at any time | Mitigate or roll back immediately; fix follows |
| High | A core workflow is broken with no workaround; revenue or compliance impact | Same business day | Fix or workaround within days |
| Medium | A workflow is degraded, or a workaround exists | Next business day | Scheduled within the current cycle |
| Low | Cosmetic, documentation, or a request for change | Within the week | Prioritised against the roadmap |
Two notes prevent the model from being abused. First, the severity is assigned by the team against the definition, not by the reporter's urgency. Second, "critical" includes security and data risk, not just downtime, because those are the incidents with the largest downstream cost.
What the contract should settle
- Scope: which systems, environments, and integrations are covered, and which are explicitly out of scope.
- Hours and on-call: business hours, extended hours, and what "critical at 3 a.m." actually means in practice.
- Response targets, not resolution guarantees: first response is controllable; resolution time depends on the defect.
- Capacity: the planned and reactive allowances, expressed in a unit both sides can measure.
- Change control: how fixes are deployed, who approves, and what the rollback path is.
- Access and evidence: who can reach production, and what records are kept.
- Exclusions: new features, third-party outages, and misuse are not maintenance.
- Exit: what happens at the end of the term — handover documentation, credential rotation, and a knowledge transfer window.
Worked example: a maintenance quarter
Consider an illustrative product three years past launch, with a small engineering team and a backlog that is entirely feature work. This is a composite, not a client story.
The team starts by measuring: over the previous quarter, unplanned work consumed roughly a third of capacity, mostly small fixes and one dependency emergency that blocked a security patch. Nobody had noticed, because the work was never categorised.
They define four workstreams and a budget: security triage weekly, dependency review quarterly with one major upgrade scheduled, restore drill once a quarter, and a platform allowance of two engineer-weeks per quarter. Reactive work is capped at 20 percent of capacity and reported monthly.
The first quarter's planned work is deliberately unglamorous: upgrade the runtime, remove two abandoned libraries, automate the restore drill, and route alerts to an owned channel with an on-call rotation. No customer-visible feature ships from the maintenance budget, and the reactive share drops from a third to under a fifth by the end of the quarter, because two of the recurring incident classes were fixed at the root.
That is the return on maintenance: not fewer tickets forever, but a system that stops generating the same class of work.
Limitations and assumptions
This model assumes a product with a real production environment and enough traffic that failures matter; for an internal tool or a prototype, a lighter version of the same discipline is enough. It assumes the team has the authority to schedule maintenance work and interrupt it for incidents, which requires a decision from whoever owns the roadmap. It assumes a contractual relationship where capacity can be expressed and reviewed; where maintenance is informal, the first step is simply categorising the work for a quarter so the conversation has numbers. Finally, it is not a substitute for architectural investment: if the same incident class recurs monthly, the honest conclusion is that the design needs to change, and maintenance budget alone will not fix it.
Working with CodeAustral
We run maintenance and support for products we build and for systems we inherit: defined workstreams, response targets tied to business impact, restore drills, and a quarterly upgrade plan. If you are formalising post-launch ownership, send a brief with your current incident pattern, or see how we plan modernisation work when maintenance is no longer enough and read our legacy modernisation roadmap.
Frequently asked questions
How much of our engineering capacity should maintenance take?
For an actively changing product, 15 to 25 percent per month is a common range, with reactive work bounded inside it. The number matters less than the measurement: if you do not categorise unplanned work, you cannot tell whether the allowance is adequate or the system is generating avoidable incidents.
Is a maintenance contract the same as an SLA?
No. An SLA states response and availability targets; a maintenance contract defines the workstreams, cadence, and capacity. You can have strong response targets and still accumulate upgrade debt, because nobody scheduled the work. Both belong in the agreement, but they answer different questions.
When should we stop maintaining and rewrite instead?
When a recurring incident class has a design cause that cannot be fixed incrementally, or when the upgrade path to a supported platform no longer exists. That decision should be made with numbers: incident cost, upgrade cost, and the cost of the delay. A rewrite is not a maintenance outcome; it is a separate investment decision.
Who should own maintenance after launch?
The team that built the system, for at least the first two quarters, because they hold the context that makes fast fixes cheap. After that, ownership can transfer to a dedicated team if the handover includes runbooks, access, and a knowledge transfer window. Transferring ownership immediately after launch is the most common way to lose the knowledge that makes maintenance efficient.