Maintenance doesn’t make headlines
On Monday morning, the business software won’t open. Someone restarts their computer; someone else tries their phone. Then a message appears in the team chat: “Is this happening to anyone else?” Within ten minutes, an IT problem has become stalled work, calls to customers and appointments to reschedule.
The previous Friday, the system had seemed fine. No obvious faults, no urgent reason to look at it. The update could wait. So could checking the backups. There was always something more visible to deliver.
IT maintenance gets caught in this misunderstanding: when everything works, it seems unnecessary. Yet part of the technical work is precisely what keeps things running normally. To understand its value, you need to look between launches, once the presentations are over and the software starts to age.
That small task put off again
A digital certificate expires. Disk space fills up. A software library stops receiving updates. These are predictable events, even if discovering their consequences can come as a surprise.
Take a company website: the pages load, the contact form works and nobody reports anything unusual. Meanwhile, a component falls behind on updates and errors start piling up in the server logs. If all anyone checks is the homepage, the problem can stay out of sight.
Delays also have a practical effect. Updating one component at a time keeps the checks manageable. Catching up on years of neglected maintenance may mean changing code, databases and settings all at once. It then becomes harder to work out which change caused an error.
A backup is only useful if you can restore it
The notification says the backup is complete. Good. But does it include the attachments? Can you access the credentials needed to retrieve it if the main system is down? How long will it take to get the application running again?
A restore test answers those questions. A backup can be readable and still fall short: a configuration file or a key needed to start the service might be missing.
Backup frequency needs to reflect how the business works, too. Losing a few hours of changes to a rarely updated archive may have little impact. For a system that processes orders continuously, those same hours mean reconstructing data and contacting customers again. “We have backups” says nothing about that difference.
Updating without going in blind
Fear of breaking something is one reason updates sit untouched. It’s understandable, especially when an application relies on old or poorly documented integrations.
That makes preparation essential: understanding dependencies, testing changes in a separate environment and working out how to return to the previous state. For an online shop, testing needs to cover payment and order recording. Checking the homepage isn’t enough.
Installing every new version immediately isn’t a sensible blanket rule either. A fix for a vulnerability already being exploited deserves different attention from a cosmetic change. Priority depends on how exposed the system is, the impact of the problem and the protections available while the update is being prepared.
When nobody owns the job
“I thought the supplier handled that.” It’s the sort of sentence that surfaces when a service is already down. The supplier manages the server, the developer looks after the code and the company pays the subscriptions. In between sit domains, certificates, access permissions and external services that nobody has a complete view of.
Maintenance starts here, too: assigning clear responsibilities. Whoever receives an alert needs to know whether to act, who to contact and how urgently.
Documentation makes that work transferable. Where the backups are stored, how to restart a service, what to check after a release: brief, current instructions matter when the person who knows the system is on holiday. Relying on their memory can seem convenient until the first time they’re away.
Room in the schedule and the budget
Maintenance competes with work whose results are easier to show. You can demonstrate a new feature to a customer. Cleaning up data or replacing an outdated dependency takes a little more explanation.
Making room for maintenance means making its results visible. Does a recovery test reveal unacceptable delays? Does an update eliminate recurring errors? Do support requests drop after a fix? These observations help guide investment without inventing estimates of disasters averted.
There is still an organisational decision to make: setting aside time for this work even when there’s no emergency. If new deliveries consume every available hour, the backlog grows until someone has to tackle it under pressure.
On the Monday morning when the business software opens as usual, no congratulatory notification appears. People log in, find their data and get to work. It’s easy to take that for granted. Part of the maintenance team’s job is making sure they can.
