Outdated dependencies, vulnerabilities, untested backups, expired certificates: what happens when maintenance is postponed and what a reasonable rhythm looks like.
An application that “works” today is not one that will work in a year. Software sits on shifting ground: libraries that receive fixes, operating systems that go out of support, certificates that expire, passwords that leak, servers that fill up. If you put maintenance off, nothing breaks immediately, which is exactly why it gets put off. The cost arrives later, usually at the worst possible moment. This article is for anyone who has an application in the business, technical or not.
What actually breaks
Dependencies fall behind
Every modern application rests on dozens or hundreds of libraries written by others. They receive updates with bug and security fixes. If you do not track them, you stay on old versions, and an update that would have taken an afternoon becomes, two years later, a migration of several weeks, because interfaces have changed, packages have been withdrawn and nobody remembers why the code was written that way.
The same goes for the programming language and runtime: old versions go out of support and stop receiving even security fixes.
Security: known vulnerabilities
OWASP’s list of the most common risks for web applications includes the category “vulnerable and outdated components”. You are exposed, OWASP says, if you do not know which versions you use, if software is unsupported or out of date, if you do not scan for vulnerabilities regularly and if you do not apply fixes in good time. Known vulnerabilities are public; anyone looking for targets does not need to cleverly “break into” your application, only to check whether you stayed on a version with an already published problem.
The backup that has never been restored
Almost everyone “has a backup”. Far fewer have ever restored one. An untested backup is a hope, not a guarantee. Frequent problems: the copy is made, but in the same place as the original; it started failing silently months ago; it does not include the files uploaded by users; the encryption key exists only on the lost server; nobody knows the restore steps.
What to ask of serious maintenance: copies in a separate location, alerts when a copy fails, a periodic trial restore (on a separate environment) and a short document with the steps.
Certificates and domains expire
An expired HTTPS certificate produces a warning page in the browser, and the application looks broken or unsafe. Certificates issued by Let’s Encrypt, for example, are valid for 90 days by default, and the authority recommends automatic renewal well before expiry. If automatic renewal has stopped (a server change, a new configuration) and nobody has an alert, you find out from your customers. The same happens with the domain, if the renewal payment is tied to an expired card or to an email address nobody reads any more.
Space, resources and logs
The disk fills with logs and uploaded files; the database grows; a query that ran fine on a thousand records slows down on a million. The server runs out of space and the application goes down without warning. Simple monitoring (space, memory, response time) catches the problem before users feel it.
Secrets and access
Passwords of former collaborators that still work, API keys left in code or in a message, shared accounts. Maintenance includes rotating secrets and cleaning up access: who has access to what and why.
Knowledge that leaves with the person
If the only person who knows how to release a version or restore the database leaves, the application becomes a black box. Short documentation (how to install, how to release, where the secrets are, who the contact is) is part of maintenance.
What reasonable maintenance looks like
You do not need a complicated contract. A healthy rhythm looks something like this:
- Continuous: basic monitoring and alerts (the application responds, the certificate is not about to expire, the disk is not full).
- Monthly or quarterly: dependency updates and security fixes, with tests before release.
- Periodically: a trial restore from backup, a review of access, a check for versions going out of support.
- As needed: fast incident response, with people and channels agreed in advance.
- Annually: an overview: what we will replace, what we will migrate, what we will document.
The cheapest maintenance is the kind done in small, frequent steps. One done every two years is really a project.
How to decide how much to invest
Ask two questions. What does a day of downtime cost? How sensitive is the data in it? For an internal tool used by three people, a basic level is enough. For an application with customers, payments or personal data you need more, including an incident response plan. If you process personal data, security and incident notification are also GDPR obligations, not just good practice; check with a lawyer.
A five-minute test
Can you answer these without asking anyone?
- When was the application last updated?
- When do the certificate and domain expire?
- Where are the backups, and when was one last restored?
- Who gets the alert if the application goes down at midnight?
- Who can release a new version?
If you cannot, you do not have a problem now, but you have one waiting.
ME Digital offers maintenance for in-house applications and for software built by others, from monitoring and updates to restore tests; you can start with a conversation on the contact page. For new solutions, see also custom software.