Software Maintenance and Support: Keeping Applications Secure and Reliable
What software maintenance covers, why unmaintained applications degrade even when nobody changes them, and how to structure a support arrangement that works.
Software does not need maintenance because it wears out. It needs maintenance because everything it depends on keeps moving underneath it.
A common assumption about software is that once it works, it keeps working. Physical assets degrade and software does not, so leaving it alone should be free.
It is not, and the reason is worth understanding properly: software does not decay, but everything it depends on moves. Browsers update, operating systems change, libraries publish security patches, APIs deprecate endpoints, certificates expire, payment providers alter their requirements. An application that is never touched is not stable — it is drifting out of alignment with its environment, quietly, until something breaks in a way that is urgent and expensive.
The four kinds of maintenance
A useful breakdown, because most support arrangements cover only the first and are then surprised by the other three.
Corrective — fixing what is broken
Defects found after release. This is what people picture when they hear support, and it is the smallest share of the work in a healthy system.
Adaptive — keeping up with the environment
Changes required because something external moved: a new OS version, a browser change, a deprecated API, an updated payment requirement. Nobody requested this work and it delivers no new features, which is exactly why it gets deferred until it becomes an outage.
Perfective — improving what exists
Refining functionality based on how the software is actually used — the awkward step everyone complains about, the report that takes too long, the screen people avoid.
Preventive — reducing future cost
Dependency updates, refactoring, improving test coverage, adding monitoring, writing down what only one person knows. The work with the clearest long-term return and the weakest short-term case, which is why it needs to be scheduled rather than left to spare capacity.
Why deferring maintenance gets expensive
| Deferred | Typical consequence |
|---|---|
| Security and dependency updates | A known vulnerability in a component you did not know you used |
| Framework and runtime upgrades | A one-version upgrade becomes a four-version migration |
| Monitoring and logging | Customers report your outages before your systems do |
| Documentation | One person becomes a single point of failure |
| Backup and recovery testing | Backups that turn out not to restore |
| Performance attention | Gradual slowdown nobody can attribute to a single change |
The pattern in every row is the same: the work does not disappear when deferred, it accumulates interest and is eventually done under time pressure at a worse moment.
What a support arrangement should specify
Vague support agreements cause disputes at exactly the moment nobody has time for one. Agree these in advance:
- Scope — which applications, environments and integrations are covered, and which are not.
- Severity definitions — what counts as critical versus routine, written in terms of business impact rather than technical symptoms.
- Response and update commitments per severity, and the hours during which they apply.
- Escalation path — who is contacted, by what route, and what happens outside working hours.
- What is included versus chargeable. Fixing a defect is maintenance; adding a feature is not. The boundary should be explicit.
- Update cadence for dependencies and security patches, so preventive work has a schedule rather than an intention.
- Access and continuity — credentials, documentation and repository access held by you, so a change of supplier is an inconvenience rather than a crisis.
A realistic maintenance baseline
Even for an application nobody is actively changing, a sensible floor is: monitor availability and errors continuously, review and apply security updates on a regular schedule, test that backups actually restore rather than assuming they do, watch certificate and credential expiry, and review the dependency and platform roadmap periodically so upgrades are planned rather than forced.
That baseline is what keeps a working system working. Everything above it is improvement.
Maintenance and support from B.Wyz
B.Wyz provides ongoing maintenance and support for websites, custom business applications, mobile apps and integrations — including applications originally built elsewhere, which usually starts with an assessment of what is actually running and what has drifted.
Next step: tell us what you are running and who supports it today. We will come back with a maintenance scope and an honest view on what needs attention first.
Services in This Article
The pages that go into detail on what is discussed above.
- Custom Software DevelopmentB.Wyz builds custom software around how your business actually works — internal systems, customer platforms and the integrations between them.
- Web Application DevelopmentB.Wyz builds fast, secure web applications — customer portals, internal platforms and data-heavy tools that hold up in daily production use.
- Mobile App DevelopmentB.Wyz builds iOS and Android apps — native and cross-platform — from first release through store launch and the versions that follow.
More Reading
- 7 min readBusiness Website Development: What Drives GrowthMost business websites are judged in under a second and abandoned in under three. Here is what actually determines which side of that line yours falls on.
- 8 min readAPI Integration: Connecting Your Business SoftwareIntegration is the cheapest major improvement most businesses can make, and the one most often skipped in favour of replacing a system that was never the problem.
- 7 min readDedicated Software Development Teams ExplainedA dedicated team is not cheaper developers. It is a different contract shape — one that only works if you have someone inside the business to direct it.
Frequently
Asked
Because everything it depends on changes. Browsers and operating systems update, libraries publish security patches, APIs deprecate endpoints, certificates expire and payment providers alter requirements. An untouched application is not stable, it is drifting out of alignment with its environment until something breaks urgently.
Four kinds of work: corrective, fixing defects; adaptive, keeping up with external changes such as OS and API updates; perfective, improving existing functionality based on real usage; and preventive, meaning dependency updates, refactoring, monitoring and documentation that reduce future cost. Most support agreements cover only the first.
Which applications and environments are covered, severity definitions written in terms of business impact, response commitments per severity and the hours they apply, the escalation path including out of hours, the boundary between included maintenance and chargeable new work, the update cadence for security patches, and confirmation that you hold credentials, documentation and repository access.
Yes, and it is common. It usually begins with an assessment of what is actually deployed, what its dependencies are, how far behind they have drifted, and what is undocumented. That assessment is what makes it possible to quote a realistic ongoing scope rather than an optimistic one.