Software maintenance and support is the work that keeps a live system working, secure and useful after launch. Maintenance is the engineering: fixing defects, applying security patches, updating dependencies, adapting to changes in the platforms and third parties the system relies on, and making small improvements. Support is the service wrapped around that work: who you contact when something breaks, how quickly they respond, and what they are committed to fixing. A system needs both for as long as it is in use, and the cost is a permanent part of owning software, not an optional extra.
What software maintenance and support covers after launch
Software is correct against the world as it was on release day. Then the world moves: browsers update, a payment provider changes its API, a library publishes a security advisory, the data grows tenfold. Maintenance is the response to that movement. In practice it covers:
- Bug fixes for defects that only appear in real use.
- Security patches and dependency updates, applied on a schedule instead of after an incident.
- Platform upgrades: operating system, language runtime, framework and database versions, each of which has a support window that eventually closes.
- Third-party changes: integrations that break because the other side changed something.
- Monitoring, observability and incident response, so a failure reaches an engineer before it reaches a customer.
- Backups and restore tests. A backup that has never been restored is a hope, not a backup.
- Renewals: domains, TLS certificates, app store accounts, API subscriptions.
- Performance work as usage and data volumes grow.
- Small changes: a new field, an adjusted report, a changed rule.
What it does not cover is new feature development of any size. That is a project, with its own scope and budget. Mixing the two is a common reason maintenance spending looks out of control.
A note on terms. "IT maintenance" is the wider phrase and usually takes in hardware, networks, laptops and licences as well. This article is about the software part.
The four types of software maintenance
The classic types of software maintenance are corrective, adaptive, perfective and preventive. The four-way split is long established and appears in the ISO/IEC 14764 standard on software maintenance. Each has a different trigger, and a different argument about who ought to pay for it.
| Type | Triggered by | Example | If you skip it |
|---|---|---|---|
| Corrective | Something is broken | An invoice total rounds incorrectly, or a form fails in one browser | Users lose trust and build workarounds |
| Adaptive | The environment changed | A new operating system version, a retired API, a change in tax rules | The system stops working through no fault of its own |
| Perfective | The business wants it better | A faster search, a clearer screen, an extra export | The software drifts away from how people actually work |
| Preventive | Nothing, yet | Upgrading a dependency before its end of life, adding tests around fragile code, rehearsing a restore | Small deferred jobs become one large emergency |
In my experience corrective work is the smaller part of maintaining a healthy system. Most of the effort goes on adaptive and perfective work, because the surroundings and the business keep changing even when the code is sound.
Preventive maintenance is the type that gets cut, because nothing visible happens when it is done well. It is also the cheapest. An upgrade done one version at a time is routine. The same upgrade attempted after five skipped versions is a project, and that is how systems slide into technical debt without anyone deciding to let them.
What a maintenance support agreement should define
A maintenance support agreement is only as good as its definitions. "We will look after it" is not an agreement. These are the things I would want written down before signing, on either side of the table.
Response and resolution targets
These are two different promises, and vendors often quote only the first. A response target is how quickly a qualified person acknowledges the problem and starts work. A resolution target is how quickly the system is usable again, even if through a temporary workaround. A fast response with no resolution commitment can mean a prompt email and a slow fix.
Targets should vary by severity, and the severities need definitions that both sides would apply the same way:
| Severity | Typical definition | Example |
|---|---|---|
| Critical | The system is down or data is at risk, with no workaround | Nobody can log in, or payments fail |
| High | A core function is broken for many users | Orders save but confirmation emails do not send |
| Medium | A function is impaired but a workaround exists | A report has to be exported because it will not display on screen |
| Low | Cosmetic or minor | A label is misspelt |
I have deliberately left the numbers out. The right targets depend on what an hour of downtime costs you, and tighter targets cost more because somebody has to be available to meet them. Ask for the targets the risk justifies, not the tightest ones on offer.
Hours of cover
State the support hours, the time zone, and what happens outside them. Business-hours cover is enough for many internal systems. A public system that takes payments may need out-of-hours cover for critical issues only, which costs far less than round-the-clock cover for everything. Check how public holidays are handled and how an issue is raised.
What counts as a bug versus a change
In my experience this line causes more disputes than any other. The workable definition is that a bug is the system failing to do what was agreed, and a change is the system doing what was agreed when you now want something different. That only works if what was agreed is written down, which is one more reason to keep the original specification and acceptance criteria.
The agreement should also say how the grey areas are treated:
- A third party changes its API and an integration breaks. Nobody made a mistake, yet work is needed. Is that inside the fee?
- Bad data entered by a user needs correcting in the database.
- The system has become slow because the data has grown.
There is no universally correct answer to any of these. What matters is that the answer exists before the first case arises.
The commercial terms around it
Finally, the agreement should state what the fee includes, whether unused hours carry over, what is reported each month, the notice period, and what the vendor hands over when the arrangement ends.
Working through this on a real project?
Tell us what you are building or fixing. A senior engineer will give you a straight view of it, including when the honest answer is that you do not need us.
Who holds the keys and the runbooks
The question I would ask of any maintained system is simple: if the people looking after it vanished tomorrow, could someone else take over? The answer depends on two things.
The keys. Every account the system depends on should be owned by the business, with the maintainer given delegated access that can be withdrawn:
- The domain registrar and DNS
- The hosting or cloud account
- The source code repository
- App store developer accounts
- Payment, email and SMS provider accounts
- Third-party API keys, and wherever the system's secrets are stored
- The backups, and the keys that encrypt them
If any of these is registered to a supplier's email address or a former employee's personal account, fix that first. It costs very little while relations are good and a great deal once they are not.
The runbooks. A runbook is a written procedure for an operational task: how to deploy a release, roll one back, restore from backup, rotate a credential, or respond to a particular alert. The test is whether a competent engineer who has never seen the system could restore it using only the documents. If the honest answer is no, the knowledge lives in somebody's head.
Software maintenance cost: how to budget for it
Software maintenance cost is best treated as a structural share of what the system cost to build, recurring every year it stays in service. It scales with the size and complexity of what you own, not with how many problems you happened to notice last year. I give the working range I use with clients in the real cost of custom software. Where a particular system falls within any range depends on a handful of drivers:
- Integrations. Each third party is a source of change you do not control.
- Dependencies. More libraries, and older ones, mean more updates and more risk in each update.
- What downtime costs. Tighter targets and longer hours of cover are the largest multiplier.
- How fast the business changes. A stable process generates few change requests. A growing one generates many.
- Automated tests and deployment. A system with good tests and a CI/CD pipeline is cheaper to maintain for its whole life, because every change is quicker to verify and release.
- Regulation. Systems holding payment, health or personal data carry audit and patching obligations.
The pricing model matters as much as the amount. A retainer buys defined cover for a fixed monthly fee and suits systems where availability matters. A block of hours suits a steady flow of small changes. Pay as you go looks cheapest and suits only systems you could live without for a few days, because nobody is reserved for you and nobody is watching.
Budget separately for the occasional large upgrade. A major framework or platform version is lumpy work that does not fit inside a monthly fee, and it is better planned than discovered.
In-house vs vendor maintenance
You can maintain software with your own staff, with an outside vendor, or with a mix of the two. A disclosure before the comparison: Yarqat is a vendor, an offshore engineering company based in Pakistan, so I have a stake in this answer.
| Factor | In-house | Vendor |
|---|---|---|
| Knowledge of the business | Deep, and it grows over time | Has to be learned and documented |
| Cost shape | Salaries, whether or not there is work | A fee sized to the cover you need |
| Cover for absence | Hard with one or two people | Shared across a team |
| Control of priorities | Entirely yours | Shared with the vendor's other clients |
| Main risk | Dependence on one key person | Dependence on the vendor, unless you hold the keys |
In-house maintenance makes sense when the software is central to how you compete and there is enough work to keep engineers engaged.
A vendor makes sense when the system is important but does not justify a standing team. The downsides are real as well. A vendor will never know your business as well as your own people do, you compete with other clients for attention, and a careless arrangement leaves the vendor holding the accounts. The in-house versus outsourced comparison goes further into that trade.
A mix is often the best answer: one person inside the business who owns the system and its priorities, and a vendor who supplies the engineering hours and the cover.
For the systems we build, Yarqat offers an optional monthly care plan covering hosting, monitoring, backups, security updates and small changes, which can be cancelled at any time. The code and the accounts are in the client's name, so taking the system in-house or to another developer stays open.
Warning signs of a neglected system
Neglect is quiet. The system keeps working, which is why nobody acts. These are the signs I would look for: Left long enough, a neglected system becomes what the industry calls a legacy system.
- Nobody has deployed a change in months, and the idea of doing so makes people nervous.
- Dependencies are several major versions behind, or the runtime is past its end of support.
- Backups exist, but nobody can remember a restore being tested.
- You learn about outages from customers.
- A certificate or domain has expired by surprise at least once.
- Only one person knows how to release, and there is no written procedure.
- Small changes are quoted as large ones, because the code has become risky to touch.
- Staff keep a spreadsheet alongside the system for the things it no longer does properly.
Two or three of these mean the system needs a proper review. Most of them together mean it is already expensive to rescue, and the price rises each quarter. If that is where you are, our maintenance and support service includes taking over systems that someone else built.
Software maintenance and support FAQ
What is software maintenance and support?
It is the ongoing work of keeping live software working, secure and current after launch. Maintenance covers bug fixes, security patches, upgrades and small improvements. Support covers how problems are reported, how quickly someone responds, and what they have committed to fix.
What are the four types of software maintenance?
The four types of software maintenance are corrective (fixing defects), adaptive (keeping up with changes in platforms, integrations and regulation), perfective (improving how the system works for its users) and preventive (reducing the chance of future problems before they occur).
How much does software maintenance cost?
Software maintenance cost is usually budgeted as a share of the original build cost, repeated every year. The share depends on the number of integrations, the age of the dependencies, the hours of cover and response targets you need, and how often the business asks for changes.
What should maintenance support include?
Maintenance support should include security patching, dependency and platform updates, monitoring, tested backups, bug fixing against defined response and resolution targets, stated hours of cover, and a clear rule for bugs versus changes.
Is IT maintenance the same as software maintenance?
Not quite. IT maintenance is the broader term and normally includes hardware, networks, devices and licences. Software maintenance is the part concerned with applications: their code, dependencies and integrations.