WhatsAppSoftware maintenance guide: why it matters
Software does not wear out like a machine, but the world around it changes constantly. Operating systems, browsers, frameworks and third-party APIs update; security vulnerabilities are discovered; data grows; users ask for improvements. Without maintenance, software becomes slower, less secure and harder to change — until a rebuild becomes unavoidable.
The four types of maintenance
| Type | Purpose | Examples |
|---|---|---|
| Corrective | Fix defects | Bugs, crashes, data errors |
| Adaptive | Adapt to environment changes | OS updates, API changes, new regulations |
| Preventive | Reduce future problems | Dependency upgrades, refactoring, monitoring |
| Perfective | Improve and extend | Performance, usability, small features |
How much maintenance costs
A common rule of thumb is to budget 15–20% of the original development cost per year for maintenance, plus hosting and third-party services. Over a system’s lifetime, maintenance often exceeds the initial build cost — which is why maintainability (tests, documentation, clean architecture) is worth investing in from the start.
What a maintenance plan should include
- Uptime, error and performance monitoring
- Regular security patches and dependency updates
- Bug fixes with agreed response times by severity
- Backups with periodic restore tests
- A monthly allowance for small improvements
- Regular reports on incidents, updates and recommendations
- Access to documentation and knowledge transfer
Best practices
- Keep dependencies current with small, regular updates instead of big jumps
- Maintain automated tests so changes can be made safely
- Monitor proactively so issues are found before users report them
- Document architecture, setup and runbooks
- Review technical debt quarterly and address the most costly items
- Plan major upgrades (framework versions, OS targets) ahead of end-of-support dates
Signs maintenance has been neglected
- Frameworks or languages several major versions behind
- Security warnings from scanners or hosting providers
- Small changes take weeks because nobody is sure what will break
- No one knows how to deploy or restore the system
- Rising error rates or slow performance
Sample maintenance plan tiers
| Tier | Typically includes | Suits |
|---|---|---|
| Essential | Monitoring, security patches, backups, critical bug fixes | Stable internal tools with few changes |
| Standard | Essential + business-hours support, monthly updates, a small improvement allowance | Most customer-facing apps |
| Extended | Standard + faster response times, out-of-hours cover, larger development allowance | Business-critical and revenue-generating systems |
Response times by severity
| Severity | Example | Typical response target |
|---|---|---|
| Critical | System down or data at risk | Within 1 hour |
| High | Major feature broken, no workaround | Within 4 business hours |
| Medium | Feature impaired, workaround exists | Within 1 business day |
| Low | Cosmetic issue or question | Within 3 business days |
Illustrative targets; agree specific times in your support agreement.
Response time is when work starts, not when the problem is solved. Good agreements also define how updates are communicated during an incident.
Monthly maintenance checklist
- Review monitoring dashboards: errors, uptime, response times
- Apply security patches and minor dependency updates
- Check backups completed and test a restore at least quarterly
- Review SSL certificates, domains and third-party API keys for expiry
- Check disk, database size and cloud costs
- Review open bugs and prioritise fixes
- Report on incidents, changes made and recommendations
Taking over maintenance from another team
-
Collect access
Repositories, hosting, domains, third-party accounts and credentials.
-
Audit1–2 weeks
Review code quality, dependencies, security, infrastructure and documentation.
-
Stabilise
Fix urgent risks: missing backups, outdated critical packages, monitoring gaps.
-
Document
Write setup, deployment and recovery runbooks.
-
Plan
Agree a roadmap of improvements and upgrades based on the audit.
An honest audit at the start sets realistic expectations and prevents surprises, especially for systems built quickly or without tests.
Budgeting example
Take an application that cost $120k to build. Using the 15–20% rule of thumb, annual maintenance would be in the region of $18k–$24k, before hosting and third-party services. That budget typically splits across monitoring and patching, bug fixes, dependency upgrades and a modest allowance for small improvements. Years with a major framework upgrade or a new mobile OS release may need more; quiet years may need less.
Treat this as a starting point, not a quote. Systems with many integrations, strict compliance requirements or heavy traffic need more care; small internal tools with few users need less. The important point is to budget something every year rather than nothing until a crisis.
Maintenance or rebuild?
| Signal | Keep maintaining | Consider modernising or rebuilding |
|---|---|---|
| Technology | Supported versions, active ecosystem | Unsupported framework or language, few developers available |
| Change speed | Small changes ship in days | Small changes take weeks and regularly break other features |
| Cost trend | Stable maintenance cost | Maintenance cost rising year after year |
| Business fit | Still matches how the business works | Processes have changed and workarounds pile up |
Modernisation does not have to mean a risky big-bang rewrite. Most systems can be improved gradually — see legacy software modernization.
Documentation every system should have
- Architecture overview: main components and how they connect
- Local setup instructions a new developer can follow in an hour
- Deployment and rollback procedure
- Backup and restore runbook
- List of third-party services, accounts and renewal dates
- Known issues and technical debt register
Dependency and platform upgrade planning
Every application depends on a language runtime, a framework, libraries and a hosting platform, and each has its own release and end-of-support schedule. Keeping a simple register of these dates turns surprise emergencies into planned work.
| Component | What to track | Suggested approach |
|---|---|---|
| Language runtime | Supported and end-of-life versions | Upgrade at least a few months before end of support |
| Framework | Major versions and long-term-support releases | Move one major version at a time, with tests |
| Libraries | Security advisories and abandoned packages | Automated update alerts and regular small updates |
| Database | Engine versions and managed-service retirement dates | Test upgrades on a copy of production data first |
| Mobile platforms | Minimum OS targets required by app stores | Plan updates around yearly OS releases |
| Third-party APIs | Deprecation notices and version sunsets | Subscribe to provider change logs |
Monitoring that catches problems before users do
Maintenance is far cheaper when problems are spotted early. A sensible baseline for most business applications:
- Uptime checks on key pages and APIs from outside your network.
- Error tracking that groups exceptions and alerts when new ones appear.
- Performance monitoring for slow pages, queries and background jobs.
- Infrastructure metrics: CPU, memory, disk space and database connections, with alerts before limits are reached.
- Certificate and domain expiry alerts, the classic avoidable outage.
- Backup verification: alerts when a backup fails, plus scheduled restore tests.
Technical debt: deciding what to fix
Every system builds up shortcuts and outdated code. Not all of it is worth fixing. A practical way to prioritise is to weigh how much each item slows the team down or adds risk against the effort to fix it.
| Debt item | Impact | Effort | Typical decision |
|---|---|---|---|
| Code area changed often and frequently buggy | High | Medium | Refactor soon, with tests |
| Outdated framework nearing end of support | High | High | Plan and schedule the upgrade |
| Messy code that rarely changes | Low | Medium | Leave it alone |
| Missing tests on critical workflows | High | Low–medium | Add tests next |
| Inconsistent styling in an old admin area | Low | Low | Fix opportunistically |
Illustrative examples. Score your own items with the team that maintains the system.
Reserving a fixed share of each month’s maintenance time for debt reduction, rather than waiting for a “cleanup project”, keeps systems healthy without stopping feature work.
Questions to ask a maintenance provider
- What is included in the monthly fee, and how are extra hours charged?
- What response and resolution times apply to each severity level?
- How do you monitor the system, and who receives alerts outside business hours?
- How often are dependencies and security patches applied?
- How are changes tested and deployed, and can they be rolled back?
- What reports will we receive each month?
- If we end the agreement, what handover do you provide?
Writing a runbook for your application
A runbook is a short document that tells whoever is on call how to keep the system running. It is one of the most valuable maintenance documents and is rarely written until something goes wrong. A useful runbook covers:
- How to check whether the system is healthy and where the dashboards are
- How to deploy, and how to roll back a bad deployment
- How to restart each service and clear common queue or cache problems
- Where logs are and how to search them
- How to restore from backup, step by step
- Who to contact for each third-party service and how to reach them in an emergency
Maintenance for mobile apps
Mobile apps carry extra maintenance work. Apple and Google release major OS versions every year and raise the minimum target versions accepted in their stores, so apps that go unmaintained eventually cannot be updated. Plan an annual compatibility release, keep signing certificates and store accounts in company ownership, and monitor crash reports after every OS update. See mobile app maintenance for details.
Maintenance and compliance
Regulations such as HIPAA, PCI DSS and SOC 2 controls expect systems to be patched, monitored and backed up, with records showing it happened. Keep a simple log of security updates, access reviews, backup tests and incidents. Besides helping audits, the log shows management what maintenance actually delivers each month, which makes it far easier to justify the budget.
A year of maintenance at a glance
Spreading planned work across the year avoids big, risky catch-up efforts. A typical calendar for a business application might look like this:
| When | Planned work |
|---|---|
| Every month | Security patches, dependency updates, backup checks, small improvements |
| Every quarter | Restore test, access review, technical-debt review, performance check |
| Twice a year | Framework or runtime minor upgrades, disaster-recovery rehearsal |
| Once a year | Major version upgrades, architecture review, maintenance budget review |
Illustrative schedule; adjust to your system and risk profile.
Who does what in a healthy maintenance arrangement
Business owner
Sets priorities, approves changes and owns the maintenance budget.
Maintenance team
Monitors, patches, fixes and reports; proposes improvements.
Users and support
Report issues with clear steps, screenshots and impact.
Security or IT
Sets policies, reviews access and coordinates audits.
Planning for end of life
Every system eventually reaches the point where maintaining it costs more than replacing it. Plan for this rather than waiting for a crisis: keep an inventory of components with their support end dates, review the replacement question annually and make sure data can be exported cleanly. When the decision comes, a planned replacement with a parallel run is far less disruptive than an emergency rebuild.
Reporting that keeps owners informed
A short monthly report keeps maintenance visible and justifies its budget. It should list incidents and how they were resolved, updates applied, upcoming end-of-support dates, small improvements delivered and recommendations for the next quarter. One page is usually enough; the goal is a clear picture, not a long document nobody reads.
Getting help
If your software needs a maintenance partner — or you are taking over a system from another team — see software maintenance & support, mobile app maintenance or legacy modernization.
Browse more practical guides in Software Development Guides & Resources.