Software Maintenance Plan: What to Include in 7 Steps
A software maintenance plan is a written agreement on how a system will be kept working, secure and useful after launch: who fixes bugs, how often dependencies and servers get updated, how the software adapts to business changes, and how failures are prevented before they happen. If your company runs on custom software, an online store or an internal platform, that plan is what keeps the investment from quietly decaying.
This guide covers what software maintenance actually includes, the four types worth separating, a seven-step way to build your plan, what belongs in a maintenance contract, and the mistakes that end up costing the most.
What is software maintenance, and why doesn't it end at launch?
Software changes even when nobody touches the code. Browsers update, payment providers retire API versions, libraries ship security patches, and the operating system on your server keeps moving. Any of those can break something that worked yesterday.
Then the business itself changes: new tax rules, new products, a reworked process, a bigger team. Software that doesn't keep up gets surrounded by spreadsheets and manual workarounds. In our experience building custom software, launch day is the start of a system's useful life, not the end of the project.
The 4 types of software maintenance
Most teams split maintenance work into four categories. Separating them makes budgeting and vendor conversations much easier, because each one follows different logic.
| Type | What it handles | Real-world example | When it happens |
|---|---|---|---|
| Corrective | Bugs already hurting operations | Shipping is miscalculated for one state | When the failure shows up |
| Adaptive | Changes in the environment: APIs, regulations, hosting | Your payment gateway deprecates a version and you must migrate | When a third party or a rule changes |
| Perfective | Usability, performance, small new features | Adding the sales-report filter everyone keeps asking for | Based on business priority |
| Preventive | Risks that aren't failures yet | Upgrading a library before it stops getting patches | On a schedule |
The classic mistake is paying only for corrective work, the "call us when it breaks" model. It looks cheaper, but it piles up technical debt: every month without preventive work makes the next upgrade riskier and more expensive.
What should a software maintenance plan include?
Beyond the four types, a solid plan covers specific tasks you should be able to see in a report. Here is the minimum checklist we recommend:
- Monitoring and alerts for downtime, slowness and error spikes, ideally before a customer notices.
- Tested backups. Having backups isn't enough; someone has to restore them on a schedule to prove they work.
- Security updates for the operating system, framework and libraries. The OWASP Top 10 is a good reference for the most common web application risks.
- Version and end-of-life tracking. Know which version of each component you run and when it stops receiving patches. endoflife.date collects those dates by technology.
- Bug fixing with agreed priorities and response times.
- Small improvements within a defined number of hours.
- Up-to-date documentation, so knowledge doesn't live in one person's head.
- A regular report: what was done, what risks exist, and what's recommended next.
How to create a software maintenance plan in 7 steps
Your plan doesn't need to be long. It needs to answer who does what, how often, and how you'll measure it. This is the process we use with clients.
- Take inventory. List every system, domain, server and third-party service (payments, email, messaging), plus who has access to each. No inventory, no plan.
- Rank by criticality. What happens if this system is down for an hour? A day? Your store during the holiday rush is not the same as a monthly internal report.
- Set response times. Define levels such as critical (operations stopped), high (many users affected), normal and low, and agree how fast each one gets a response and a fix.
- Schedule preventive work. Put dependency updates, backup restores and certificate renewals on a calendar instead of relying on good intentions.
- Reserve capacity for improvements. A separate bank of hours keeps enhancements from fighting emergencies for attention.
- Pick a few simple metrics. Uptime, incident count, average time to resolve and dependency age are enough to start.
- Review quarterly. As the business changes, a system that became critical needs a different level of care.
In-house, original vendor or a third party?
There's no single right answer; it depends on the size of the system and your team.
- In-house team: knows the business and moves fast, but it's hard to cover every specialty (infrastructure, security, front end, databases), and it gets fragile when someone leaves.
- The vendor who built it: knows the code and starts with no learning curve. The risk is lock-in, so make sure you hold the repository, documentation and credentials.
- A specialized third party: brings fresh eyes and often more mature processes, but needs onboarding time. A proper technical handover shortens that a lot.
Many mid-sized companies do well with a hybrid: an internal owner sets priorities and holds the keys, and a vendor executes the technical work with clear reporting.
What to put in a software maintenance agreement
Most misunderstandings are avoided in the contract. Before signing, confirm these points are in writing:
- Scope: which maintenance types are covered and which are quoted separately.
- Service levels: response and resolution times by priority, plus support hours.
- Included hours, and what happens to unused or extra hours.
- Ownership: code, data and accounts belong to your company.
- Backups: frequency, storage location and how often restores are tested.
- Reporting: how often and what it must contain.
- Exit terms: how everything gets handed over if you switch vendors.
Be wary of any service that can't tell you what it did last month. If you pay for maintenance and get no reports, you're paying for availability, not maintenance.
Common mistakes that make maintenance expensive
- Putting off updates for years. Skipping several major framework versions turns routine work into a migration project.
- Never testing backups. Plenty of businesses learn their backup was incomplete on the day they need it.
- One person holding all the access. Domains, servers and vendor accounts should be in the company's name.
- Mixing emergencies with new projects. Without a separate bucket of hours, improvements never ship or urgent fixes wait.
- Adding features without cleanup. Every untested, undocumented feature raises the cost of every future change.
When should you stop maintaining and rebuild?
At some point, maintaining costs more than rebuilding. Warning signs: the underlying technology is out of support, every small change breaks something else, nobody understands the code, or the system no longer reflects how the company works. A phased rebuild, migrating one module at a time, usually keeps operations running. The same applies to websites: if yours is slow, hard to edit or insecure, it may be time to look at professional website design and development on a modern foundation.
Frequently asked questions
How much does software maintenance cost?
It depends on system size, how critical it is, the technology stack and the response times you need. That's why it's worth getting an assessment before accepting a flat fee; a price without a diagnosis often leaves out important preventive work.
How often should software be maintained?
Monitoring and backups should run continuously or daily. Critical security patches should go in as soon as they're released, and the rest of the preventive work can run monthly or quarterly depending on criticality.
What's the difference between software support and software maintenance?
Support answers user questions and handles problems as they come up. Maintenance includes that, plus scheduled work on the system itself: updates, failure prevention, adaptations and improvements.
Can I switch software maintenance providers?
Yes, as long as you have access to the code, data, credentials and documentation. That's why ownership and exit terms should be clear from the very first contract.
If you'd like a second opinion on the state of your system and a realistic maintenance plan, talk to our team.
