Software maintenance and operations after launch: what has to be settled afterwards

The pattern is familiar. Software that was introduced two years ago suddenly shows an error message. The employee in the office calls the contact person from back then, who is now busy on another project. Access to the server lies with a service provider nobody knows anymore, and the password is probably in an email from back then. By the time someone understands the situation, the afternoon is over.

In this scenario the project did nothing wrong. The software fulfills its purpose, the acceptance was clean, the users are satisfied. What is missing is an operating model, because the project had no room for one. Development has an end and a budget; operations has neither. It runs as long as the company runs.

This article describes what should be settled after launch. It is aimed at management and internal owners who use or are planning custom software and want to know which questions to ask before go-live. It is not about a tool, but about responsibilities, rhythms and evidence.

A helpful thought up front: software behaves like a building, not like a piece of furniture. It ages even without use, because its environment changes. Browsers, operating systems, libraries and security situations keep moving, whether or not your company changes anything.

The most common operating strategy is: touch nothing as long as it works. It seems reasonable, because every change carries risk. But it only postpones the risk. An application that has seen no update for two years does not become more stable; its distance from its environment grows. When the leap becomes necessary after all, it is big, hard to test and rarely plannable.

Behind this are several failure patterns that rarely show up one at a time. Dependencies, meaning the third-party libraries that make up a large part of modern software, receive security fixes that are never applied. Backups run every night, but nobody has ever tried a restore. The former developer’s access is still active. The certificate expires, and nobody has the date in a calendar.

There is also an organizational weakness: knowledge lives in people’s heads. Whoever built the application knows quirks that are written down nowhere, such as why a nightly job has to run at three o’clock or which setting has to be carried over when the server moves. When that person leaves the project, the knowledge goes with them, and operations become guesswork.

The consequence is not panic but sobriety. An operating concept does not have to be big, but it has to exist and belong to someone. The questions it answers are manageable, and most of them can be settled in half a day if you ask them before the outage rather than after.

To make operations tangible, it helps to break them down into layers that build on each other. At the bottom is the infrastructure: server, network, operating system. On top of that runs the runtime environment with its libraries, and above it the actual application with its data. Each layer has its own aging speed, its own people responsible and its own failure patterns, and they can be looked at separately.

Running across them are topics that touch every layer: access, data protection, monitoring and documentation. They are easily forgotten because they belong to no single layer. A role concept, for example, is neither a server topic nor pure application logic, and a deletion concept affects the database, backups and logs alike.

The breakdown is useful above all for clarifying responsibilities. In an outage, whether the cause lies below or above is decided in minutes. But if it is not defined who is responsible for which layer, the search begins with the service provider, who points to the host, who refers to the application. A simple table with layer, responsible person and deputy solves this problem surprisingly reliably.

The order of consideration follows the damage, not the technology. We begin with what is most expensive to lose: the data and access to it. Only after that is it worth talking about convenience, performance and further development.

There are three models to choose from for operations, and none is always right. With in-house operation, the company takes on hosting and maintenance itself, or with a local IT service provider. This gives control, but requires expertise and a willingness to be reachable at night as well. For small companies this is rarely realistic, unless the application is non-critical.

In the second model, the developer runs the software under a maintenance contract. The advantage is that code and operations are in one hand and errors are quickly narrowed down. The disadvantage is dependency: if the contract becomes difficult or the provider changes direction, the company faces a switch that becomes expensive without good documentation. This is exactly why exit capability belongs in the concept from the start.

The third model separates responsibility. A hosting provider runs the infrastructure, the developer maintains the application, and a third party, often management or an internal owner, holds the threads together. It is the most robust model, but also the one with the most interfaces. It only works with clearly named contacts and a shared document that states who does what.

As a rule we recommend separating infrastructure and application, provided the company has no IT of its own. It limits dependency and allows one part to be replaced without rebuilding everything. The condition is that the application can be rebuilt on another server without special knowledge, and that can be tested rather than taken on faith.

An operating framework consists of a few building blocks that we go through as a checklist before go-live. The first is a maintenance rhythm: dependencies and the operating system are checked at fixed intervals, and highly urgent security fixes are handled outside the schedule. The rhythm is less a matter of technology than of agreement, because it makes sure someone does it.

The second building block is the role concept. It governs who may see and change what in the application, and it follows the principle of least privilege: each person gets exactly the access they need for their task. This includes a procedure for joiners and leavers, so that accounts of departed employees do not stay active for years. The same applies to technical access such as server accounts, database users and interface keys.

Third, documentation. This does not mean a library of prose, but a lean operations manual: an architecture sketch, a list of environments, storage of credentials in a password manager, a description of scheduled jobs, recovery steps and contacts. It should be written so that a qualified but uninvolved person can understand the application in a day.

Fourth, the ownership questions, which often only become noticeable in a dispute. Who owns the source code, who may change or pass it on, and where is it kept? We consider it sensible for the code to sit in a repository to which the client has its own access, and for the usage rights to be clearly regulated in the contract. Legal details belong in the contract and in review by a lawyer; here the concern is the technical side: access must not depend solely on the goodwill of the service provider.

With security updates, what counts is less the frequency than the ability to apply them without danger. That requires a test environment resembling production, automated tests for the most important processes and a way to roll changes back. Then an update is a routine procedure. Without these prerequisites, every update becomes a test of nerve, and out of caution it is skipped. Tools that check dependencies for known vulnerabilities supply the data basis for this, but they do not replace the assessment of whether a notice really affects your own application.

With backups, the rule of thumb is clear: a backup that has never been restored is a hope. We therefore plan regular restore tests in a separate environment and check two things. First, whether the data is complete and readable. Second, how long it takes until the application is running again. That time is the actual recovery time, and it often differs greatly from what was assumed. In addition, at least one copy belongs in another location, separate from the server and its credentials, so that an attack or an error does not destroy the backup at the same time.

Monitoring answers a simple question: do we notice before the users do? A few checks are often enough. Is the application reachable from outside, is the database running, is there enough free storage, does the nightly job run through, when does the certificate end? Alerts should reach someone who can act, and be rare enough to be taken seriously. An alarm that goes off ten times a day for no reason will soon be ignored.

Logs complete the picture. The application’s error logs show problems no user reports, such as failed interface calls. They must not, however, collect unnecessary personal data, and they should be deleted after a defined period. In that respect they touch the deletion concept, which we take up in the chapter on special cases.

The first special case concerns data protection. Personal data may not be stored for an arbitrary length of time, and that also applies to backups and logs. A deletion concept defines which data is kept for how long and when it is deleted, and it takes statutory retention obligations into account. This is meant as technical orientation, not as legal advice. You should clarify the specific periods with your data protection officer or a legal adviser. Technically, it pays to plan deletion as a function, because adding it later is usually costly.

The second case is a change of staff on both sides. When an employee leaves the business, accounts in the application, in the password manager and at the host have to be adjusted. When the developer changes at the service provider, a second person should know the application. This can be checked: ask who steps in when someone is on vacation, and have the answer shown to you rather than told to you.

Third, legacy burdens. Some applications run on versions for which there are no longer any security fixes. Then maintenance is, at its core, a question of modernization. We assess by risk: Is the application reachable from the internet, does it contain sensitive data, is it business-critical? Depending on the answer, isolation in the network is enough for a transitional period, or a step-by-step rebuild becomes urgent. A complete rebuild is rarely the first step.

The fourth case is the security incident. Anyone who decides beforehand whom to inform, what to shut down first and who speaks to customers acts more calmly in an emergency. A one-page emergency plan is enough: contacts, first steps, location of the backups. Reporting obligations for data breaches exist; their details belong in a review by specialists and are deliberately not elaborated here.

Finally, the exit. Software has exit capability when data can be exported in an open format, the code is with the client and the environment is documented. The goal is not to switch, but to keep your negotiating position.

An operating concept does not make software invulnerable. It changes the likelihood and the consequences of disruptions. Outages become rarer because known vulnerabilities are closed, and they last shorter because recovery has been practiced. Nobody can credibly promise that nothing will happen, and anyone who does is selling security that does not exist.

The benefit can be measured with a few figures. These include availability over a month, measured from outside, the measured time to restore from backup, the age of the applied security fixes and the number of known, open vulnerabilities in dependencies. Soft indicators come on top: How long does a new developer need to start the application locally, and how many disruptions were reported by users first?

The effort is ongoing and should be treated like maintenance on other assets. A ratio to development serves as orientation, depending on the scope and criticality of the application. A general percentage would be unserious, because small, well-built applications need little, while networked ones with many interfaces need considerably more. We give an estimate only after an inventory.

After six months it becomes clear whether the concept holds. Were the rhythms kept, was the restore test repeated, is access up to date? Where not, the cause is rarely technical. Usually a time slot in the calendar or a clear responsibility is missing. These are solvable problems, but they do not solve themselves.

One of the most common sources of dispute is the unclear boundary between maintenance and further development. Maintenance preserves the existing state: security fixes, adaptation to new environments, monitoring. Bug fixing removes deviations from the agreed behavior. Further development extends the scope of functions and is a new undertaking with its own effort. Anyone who settles this beforehand avoids discussions when the wish for a new field is suddenly called a bug.

Borderline cases exist nonetheless. If a format changes in a connected interface, is the adjustment maintenance or further development? We assign it to maintenance if the existing behavior is to be preserved, and to further development if the scope of functions changes. What matters is that client and service provider know the rule before the first case occurs.

In practice, a shared list of open wishes, ordered by urgency and benefit, proves its worth. From it, a small package for implementation emerges at regular intervals, instead of every idea triggering an intervention immediately. This protects budget and stability, because every change is also a risk, and bundled changes can be tested better.

One point many underestimate: technical debt also grows through well-meant quick fixes. A makeshift solution that is never replaced is part of the system after two years. A share of the maintenance time should therefore stay reserved for cleaning up, so that further development does not get more expensive each time than the time before.

Custom software is a tool with a life cycle. Its value depends on whether it still runs securely after years, whether data can be recovered and whether the company could continue it with another partner. The answers are not a question of large budgets, but of small, binding decisions, best made before launch.

The next step is straightforward. Check four things for your software: who has access, when was a restore last tested, how old are the latest security fixes, and is the code with you? If one of the four questions cannot be answered within a few minutes, that is your starting point.

Plan a fixed, small appointment each quarter for this. One hour is enough to go through access, backup test, fix status and open wishes and to note the results in the operations manual. This appointment is inconspicuous, but it is the difference between operations that are looked after and operations that merely keep running, hopefully.

We are happy to look at this together, with an inventory and an honest assessment of which operating framework fits your application. Whether you ultimately run operations yourself, outsource them or share them is up to you. Our job is to make sure the decision rests on known facts.