The launch is done: the new software is running, staff are working with it, the old spreadsheet has been switched off. Many projects are planned as if that settled everything. In fact the longest chapter in the life of the software begins now - the one in which it is in use.

The question “And who looks after it afterwards?” often comes up in a first conversation only when we ask. It belongs at the beginning, because the answer decides whether the software still fits later on or becomes the next legacy system.

Why software ages without maintenance

Software does not change by itself - everything around it does. The server’s operating system receives updates, the browser changes, the ERP it is connected to gets a new version, a tax rate changes, a customer demands a new format for the delivery note. If the software stands still while everything else moves on, cracks appear: first a printout stops working, then an interface, then nobody can be found who still knows the old foundation. That is exactly how the legacy systems come about that are later replaced with a great deal of effort.

What comes up after launch

Updates to the foundation

Every piece of software stands on foundations that others maintain: operating system, database, the building blocks it is made from, the users’ browsers. These foundations receive new versions regularly, and old ones expire. If you do not keep up, you end up stuck on a version nobody maintains any more - and every later jump gets bigger. In software we build, part of this foundation is ElbDesk, the foundation we build on: sign-in, permissions and collaboration are maintained there, not in each application separately.

Security vulnerabilities

In all foundations, gaps are found and closed again and again. But the closed gap only reaches you if someone installs the update. This matters most when the software can be reached from outside: customer portal, field staff, home working.

Backups

A backup that runs is half the job. The other half: it has been restored once, and it worked. Anyone who has never tried does not know whether they have a backup or just a file with that name.

Change requests from the business

After launch, the requests come: this field here, that printout there, a different sort order, a report for management. That is a good sign - the software is being used. But there needs to be a way in which requests are collected, assessed and implemented. Otherwise they fizzle out, or they are implemented in passing, and later nobody knows why the software looks the way it does.

New requirements from outside

A law changes, for example on e-invoicing. A new major customer demands electronic dispatch notifications. A second site is added, a new product needs different fields. Requirements like these come from outside and bring a deadline you do not set.

Who looks after it?

The question has three possible answers, and all three are fine as long as they are given before launch:

  • Your own business. An employee or your IT service provider takes on server, updates and backups; changes to the program go to the developer. That presupposes that source code, accounts and documentation are with you - see Who owns your software?
  • The developer. Whoever built the software keeps looking after it: updates, security, changes. Settle how you reach them, what the support covers and what it does not, and how change requests are commissioned.
  • Shared. The hosting provider looks after hardware and operating system, the developer after the application, your business after permissions and master data. What matters is that every task has exactly one person responsible, and everyone knows who that is.

What does not work: leaving the question open. Then whoever happens to have time looks after it - until nobody has time any more.

A contact person and documentation

Two things make maintenance easier than anything else. First, a fixed contact person on both sides: on your side someone who collects requests and decides, on the developer’s side someone who knows the software and does not start from scratch with every question. Second, documentation: what the software does, how it is built, where it runs, which accounts exist, how a backup is restored. Not a thick manual, but enough that an outside developer could carry on after reading it.

Every change goes to the test environment first

Every change after launch affects people who are working with the software - in the middle of an order, in the middle of an invoice. That is why the test environment from the rollout stays in place: changes are checked there before they reach everyone, just as in the first acceptance. What applied to the launch applies to every extension.

How to tell that maintenance is missing

  • Nobody dared to install the last update.
  • An employee keeps a list of their own because “the field is missing in the software” - and has been for a long time.
  • Nobody knows when the backup was last checked.
  • The developer is known only through an old email address.
  • Exactly one person has the access details for the server, and that person is away right now.
  • The software runs on a machine nobody wants to touch any more.

Questions before launch

  • Who installs updates, and how do they know one is due?
  • Who checks the backups, and when was one last restored?
  • How does a change request get from the business to the developer, and who decides whether it is implemented?
  • Where does the software run, and who looks after that place? See Cloud or your own server.
  • Are source code, accounts and documentation with you?
  • What is agreed if the developer is unavailable or stops trading?

For us a project does not end with the launch. We keep looking after the software and agree with you before launch who takes on which task.