What software maintenance actually involves after launch

Launch is the start of the software’s working life

A website, mobile app or internal system is never really “finished”. The day it goes live it begins to age. The libraries it is built on publish security fixes, operating systems and browsers change their rules, app stores raise their requirements, certificates expire, and the people using it ask for small changes. None of this is a sign that something was built badly. It is simply what happens to software that depends on an ecosystem it does not control.

Maintenance is the planned work that keeps the system secure, working and useful through those changes. This article breaks that work into its main parts so you can see what you are paying for, what happens if it is skipped, and how to plan a sensible budget.

Security patches and dependency updates

Modern applications are assembled from a large number of open-source and third-party components: frameworks, libraries, plug-ins, container images, build tools. Each of those has its own release cycle and its own vulnerabilities. When a flaw is published in a component you use, the clock starts for attackers as well as for you.

The OWASP Top 10, a widely referenced list of web application security risks, has tracked this problem since its 2013 edition, where it appeared as “Using Components with Known Vulnerabilities”. In the current edition, the OWASP Top 10:2025, it appears as A03:2025 Software Supply Chain Failures. OWASP describes this category as an expansion of A06:2021 Vulnerable and Outdated Components, widened to cover compromises anywhere in the chain of dependencies, build systems and distribution infrastructure. The OWASP project page confirms 2025 as the current released version.

OWASP’s guidance for this category maps closely to routine maintenance work:

• keep an inventory of components and versions, including indirect (transitive) dependencies, ideally as a software bill of materials (SBOM);
• remove dependencies, features and files that are not used;
• monitor vulnerability sources such as CVE, NVD and OSV, and subscribe to alerts for the components you rely on;
• obtain components only from official sources over secure links, preferring signed packages;
• upgrade deliberately, watch for components that are no longer maintained, and roll changes out in stages rather than all at once.

In practice this means a regular rhythm of dependency review, a faster path for urgent security fixes, and automated tests good enough to tell you that an upgrade has not broken anything. Skipping minor updates for a long time is what turns a routine upgrade into a risky migration.

Operating system, browser and app-store changes

Your software runs on platforms that move on their own schedule. Browsers deprecate old features, operating systems tighten permissions and privacy rules, and server runtimes reach end of life.

Mobile apps feel this most directly because the stores enforce it. Google Play’s target API level requirements are a clear example. From 31 August 2026:

Google allows developers to request an extension to 1 November 2026. Raising the target level is rarely a one-line change: each Android version changes behaviour around permissions, background work, notifications and similar areas, so the app has to be tested and often adjusted. The same requirement comes round every year, which is why it belongs in a maintenance plan rather than being treated as a surprise.

Monitoring and incident response

You cannot fix what you do not know is broken. Maintenance includes watching the system so that problems are found by you rather than by your customers:

• Uptime and response-time checks on the public endpoints that matter.
• Error tracking for the application and, for mobile apps, crash reporting.
• Resource monitoring for servers, databases and queues, with alerts before disks fill or memory runs out.
• Security logging of sign-ins, permission changes and administrative actions, kept long enough to investigate an incident.
• Expiry monitoring for domains, certificates, API keys and third-party subscriptions.

Monitoring is only useful if someone is responsible for acting on the alerts, so a maintenance arrangement should state who receives them, during which hours, and what happens next.

Backups and restore tests

Backups are easy to set up and easy to forget. The question that matters is not “do we have backups?” but “when did we last restore one?”. A sound approach covers:

• what is backed up (databases, uploaded files, configuration, secrets stored safely);
• how often, and how long copies are kept;
• where copies live, including at least one copy separated from the production account so that one compromised credential cannot delete everything;
• a scheduled restore test into a separate environment, with the time taken recorded.

That recorded time tells you how long you would actually be offline after a serious failure, which is information the business needs before it is needed.

TLS certificate renewals are getting more frequent

Every site served over HTTPS depends on a TLS certificate with a fixed expiry date. In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for publicly trusted certificates, adopted Ballot SC-081v3. It shortens the maximum lifetime of certificates in stages, as now written into section 6.3.2 of the Baseline Requirements:

The same ballot also shortens how long a certificate authority may reuse an earlier check that you control a domain, eventually to 10 days. The practical consequence is that manual, calendar-reminder renewals stop being workable. Certificates need to be issued and installed automatically, typically using the ACME protocol defined in RFC 8555, and that automation needs monitoring of its own. Load balancers, CDNs, mail servers and IoT devices that use certificates all need to be included.

Documentation and handover knowledge

Maintenance is far cheaper when the next person can understand the system quickly. Useful documentation is short and kept current:

• an architecture overview and a list of environments;
• how to build, deploy and roll back;
• where secrets, credentials and third-party accounts are held, and who owns them;
• runbooks for common incidents;
• a change log of what was updated and why.

Updating these documents should be part of each piece of maintenance work, not a separate project that never happens.

Small enhancements and fixes

Once real people use the software, they find rough edges: a confusing form, a missing report, a slow page. Many organisations fold a modest amount of enhancement work into the maintenance arrangement so that these small improvements do not wait for a large new project. It helps to agree a simple rule for what counts as “small” and how requests are prioritised, so routine upkeep is not crowded out by feature work.

Why skipping maintenance costs more later

Deferred maintenance accumulates. Unpatched components become known attack routes; outdated platforms block new features; an expired certificate takes a site offline without warning; an untested backup fails on the day it is needed. In India, the Digital Personal Data Protection Act, 2023 adds a direct legal reason: according to the Press Information Bureau, failure by a Data Fiduciary to maintain reasonable security safeguards can attract a penalty of up to ₹250 crore. The DPDP Rules, 2025, notified on 14 November 2025, give organisations an eighteen-month period for phased compliance.

How to budget for maintenance

There is no honest single percentage that fits every system. The effort depends on factors you can assess for your own software:

• Size and number of dependencies. More components mean more updates to review and test.
• Exposure. A public, internet-facing system handling payments or personal data needs faster patching and more monitoring than an internal tool.
• Platforms. Each mobile platform, browser target and hosting environment brings its own yearly changes.
• Test coverage. Good automated tests make updates quicker and safer; weak tests make each update slower and riskier.
• Integrations. Every third-party API can change or retire a version.
• Regulatory obligations. Logging, retention and reporting duties add work.
• Appetite for enhancements. Decide how much small improvement work you want each month.

A practical way to plan is to separate three buckets: a fixed baseline for routine work (updates, monitoring, backups, certificates, platform requirements), a reserve for urgent security issues and incidents, and an enhancement allowance you can adjust. Review the arrangement against what actually happened every few months. Fund maintenance as an ongoing operating cost from the start rather than as an afterthought once something breaks.

Sources

1. OWASP Top 10:2025
2. OWASP Top 10:2025, Introduction
3. OWASP Top 10:2025, A03 Software Supply Chain Failures
4. OWASP Top Ten project page
5. Android Developers: Meet Google Play’s target API level requirement
6. CA/Browser Forum: Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods
7. CA/Browser Forum: Baseline Requirements for TLS Server Certificates (source on GitHub)
8. RFC 8555: Automatic Certificate Management Environment (ACME) (IETF)
9. Press Information Bureau: DPDP Rules, 2025 Notified (backgrounder, 17 November 2025)