Software maintenance is the work of keeping software correct, secure and useful after it goes live. It has four types: corrective (fixing defects), adaptive (keeping up with platform and regulatory change), perfective (improving or extending features) and preventive (reducing future failures). As a planning rule of thumb, annual maintenance often runs around 15 to 20% of the original build cost.
Most software budgets are written around the build. The system then runs for years, and the work that keeps it running is paid for out of whatever is left. This guide explains what maintenance actually consists of, what a maintenance contract should cover, how to budget for it, who should do it, and how to tell when a system has been neglected. The cost figures here are widely quoted market rules of thumb, not Timeline Digital prices. If you already know you need an outside team, our software maintenance services page sets out what an agreement with us covers.
What are the four types of software maintenance?
The four-way classification of corrective, adaptive, perfective and preventive maintenance comes from the software maintenance standard ISO/IEC/IEEE 14764 and is used across the industry. Some vendors use other labels: perfective work, for example, is often sold as "enhancements" or "evolution".
| Type | What it does | Typical example | What triggers it |
|---|
| Corrective | Fixes defects found in production | A report adds up wrongly; an invoice fails to save | A user or monitor reports a fault |
| Adaptive | Keeps the system working as its environment changes | Upgrading a database version; adapting to a changed payment gateway API or a new tax rule | A platform, library, third-party service or regulation changes |
| Perfective | Improves or extends what the system does | A new report; a faster search; a simpler approval screen | Users and the business ask for it |
| Preventive | Reduces the chance of future failures | Refactoring fragile code, adding tests, tuning slow queries, clearing technical debt | A review, monitoring trend or audit finding |
Two points matter for budgeting. First, only corrective work is reactive; the other three types are planned. Second, a contract that lists only "bug fixes" covers one of the four types, and the system will slowly drift out of date underneath it.
What does a software maintenance contract cover?
A maintenance contract (often paired with a service level agreement, or SLA) should state in writing what is covered, how fast the vendor responds and how problems are escalated. Our software maintenance and support page describes how this is structured, and our service level agreements page explains severity levels and response commitments. At minimum a good agreement covers:
- Scope. Which systems, environments and integrations are included, and which types of maintenance (all four, or a named subset).
- Severity levels. A plain definition of what counts as critical, high, medium and low, with an example of each.
- Response and resolution targets. Time to acknowledge and time to restore service or apply a workaround for each severity, and the hours during which they apply.
- Escalation path. Who is contacted, in what order, when an issue is not progressing.
- Monitoring and patching. Whether the vendor watches uptime, errors and performance, and how often security patches and dependency updates are applied and tested.
- Backups and recovery. What is backed up, how often, and whether restores are tested.
- Enhancement work. How small changes are requested, estimated and approved, so they do not crowd out urgent fixes.
- Reporting. A regular summary of issues, response times and work done.
- Ownership and access. You own the code, data and hosting accounts; the vendor works in repositories and accounts you can reach at any time.
What is the cost of software maintenance?
The cost of software maintenance is commonly planned at roughly 15 to 20% of the original build cost per year: a system that cost 200,000 to build would need about 30,000 to 40,000 a year. Treat this as a widely quoted rule of thumb, not a measured law or a quote; some sources use up to about 25%.
The rule appears repeatedly in vendor and consultancy articles, and we did not find a primary academic study behind it.
The rule is a starting point, not a quote. Costs move up or down with:
- Criticality and support hours. Round-the-clock cover with fast response times costs more than business-hours support.
- Codebase condition. Well-tested, documented code is cheaper to maintain than code nobody understands.
- Number of integrations. Every connected service, payment gateway, API or government interface is something that can change under you.
- Rate of change. A business that asks for new reports and workflows every month spends more on perfective work than one with a stable process.
- Platform and security obligations. Regulated or internet-facing systems need more patching and review.
- Age. Older systems tend to cost more, particularly when frameworks or libraries have passed their end of support.
Two budgeting habits help. Separate run costs (hosting, licences, monitoring, patching) from change costs (new features), because they behave differently. And review the budget once a year against actual hours, not against the original rule.
For build-side figures and market ranges, see our custom software development cost guide. Timeline Digital does not publish prices for custom software, because every project is custom.
Should you maintain software in-house, with the original builder or with another vendor?
| Option | Strengths | Weaknesses | Best when |
|---|
| In-house team | Deep business knowledge, immediate availability, full control | Hiring, retention and cover for holidays and sickness; knowledge sits in few heads | The system is core, changes weekly, and you can keep two or more engineers who know it |
| The original builder | Knows the code and the reasoning behind it; fastest to start | Lock-in risk if ownership and documentation are weak | The relationship works and the contract gives you the code and access |
| A different vendor | Fresh review, price competition, can rescue an abandoned system | Takeover needs an audit first; slower first months | The builder is gone, unresponsive or no longer the right fit |
| Hybrid | In-house owner for decisions, vendor for engineering capacity and out-of-hours cover | Needs clear responsibilities | You want control without carrying a full team |
Whichever you choose, check three things: the source code is in a repository you control, the system can be built and deployed from documentation, and at least two people understand it. Those three conditions decide whether you can switch provider later.
What are the signs of neglected software?
- Fixes are made directly on the live system, with no test or staging environment.
- Operating system, database, framework or library versions have passed their vendor's end of support.
- Nobody can say when the last security patch was applied.
- A small change takes weeks because developers are afraid of breaking something.
- Errors are discovered by users, not by monitoring.
- Backups exist but have never been restored as a test.
- The same few people are the only ones who understand the system.
- Staff keep spreadsheets beside the system to work around what it cannot do.
- Integrations break whenever a partner changes something.
Three or more of these usually means the system has been running on goodwill. An audit is a sensible first step: it records what exists, what is at risk and what a sensible maintenance scope would be.
What should a software maintenance agreement checklist include?
Use this checklist before signing, or when reviewing an existing agreement.
- Systems, environments (production, staging) and integrations covered are listed by name.
- All four maintenance types are addressed, or exclusions are stated.
- Severity levels are defined with examples.
- Response and resolution targets are given for each severity, with support hours.
- The escalation path names roles and contact routes.
- Monitoring, patching frequency and testing before release are described.
- Backup frequency and a tested restore are included.
- The process for enhancement requests, estimates and approval is written down.
- Pricing model (retainer or time and materials) and what the monthly amount includes are clear.
- Reporting frequency and format are agreed.
- Code, data, documentation and hosting accounts remain yours; handover on exit is specified.
- Notice period and contract length are stated plainly.
- Confidentiality terms are in place, and an NDA is signed if sensitive data is involved.
When is maintenance no longer enough?
If most of the budget goes on corrective fixes, the platform is out of support, or the system can no longer be changed safely, maintenance only slows the decline. That is the point to assess legacy software modernization: rehost, replatform, refactor, rebuild or replace, chosen per component rather than all at once.
How Timeline Digital approaches maintenance
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. We maintain systems we built and systems built by other vendors. A takeover begins with an audit of the code and infrastructure, a risk list and a proposed scope, and support hours are Monday to Friday, 9:00 to 18:00 Pakistan time (PKT, UTC+5), overlapping UK and European mornings and the Gulf working day, with US and Canada calls booked at the start of their day; wider cover is written into the SLA. Source code, designs and documentation transfer to you on full payment. Before any full project we build 2 to 3 of your key modules as a free pilot, ready in about 2 days. Our software maintenance and support services page covers takeovers, SLA tiers and engagement models; to discuss your system, contact Timeline Digital.