Software Modernization
When is it worth modernising a business-critical system, and when does a rebuild pay off?
Our project with the German Red Cross taught us a clear answer
Here at Gloster, the same question has come up for years with every complex, custom-developed enterprise system: When is it worth completely replacing an existing system, and when is it more practical to enhance it step by step?
Many companies feel that a system that has been in use for 10 to 20 years will inevitably become obsolete sooner or later. They believe there is only one way forward from there: a complete rewrite. In my experience, this is rarely the case.
A business-critical application is not just source code. It embodies business knowledge accumulated over years—and often decades—as well as specialized processes and countless integrations. Replacing it poses significant technical, business, and organizational risks, and these risks very rarely fit into the life cycle of a live, day-to-day operational system.
Our project with the German Red Cross (DRK) demonstrated exactly this: gradual modernization can be a much more sustainable and safer path than starting from scratch. The challenge is the same across all industries. Whether it’s healthcare, the automotive industry, manufacturing, finance, or public administration, after a while, almost every organization faces the same pattern:
This is especially true for systems that are critical to day-to-day operations (or even human lives). In such cases, even a few hours of downtime is unacceptable. The German Red Cross’s laboratory IT system found itself in exactly this situation.
When carrying out modernization projects, there are generally three options to choose from.
We chose this approach at the German Red Cross as well. Not because it was the easier option, but because it was the responsible thing to do.
At first glance, it might seem like this is about developing a laboratory information system. In reality, it’s about much more than that.
The platform connects laboratory equipment from various manufacturers, handles sensitive healthcare data, and supports processes where reliability and availability are not just expectations but fundamental requirements. A system outage was simply not an option.
I remember that during one of our early meetings, a colleague from DRK asked a question that we’ve often brought up within the team ever since: “What happens if this system goes down—even for just one hour?” The answer wasn’t technical, but human: that moment made it clear that the main issue here isn’t the choice of technology.
That wasn't the question. The question was: How can a business-critical system be further developed while ensuring that operations remain stable throughout the process?
We are proud to work with organizations such as the German Red Cross, where modernizing laboratory operations meant not only implementing new software but also ensuring the long-term sustainability of critical healthcare infrastructure.
The project's results clearly demonstrate the tangible business value that the right architecture and modernization strategy can generate:
For us, an even more important outcome is that the DRK now has a platform that can be continuously expanded with new laboratories, new equipment, and new technologies without jeopardizing day-to-day operations.
This project clearly demonstrates that healthcare providers do not have to choose between innovation and operational continuity. With the right strategy, both can be achieved at the same time.
Throughout the project, we built our system using Docker, Kubernetes, microservice architecture, and cloud-native solutions. Not because these technologies are currently trendy, but because they provide solutions to specific problems.
A modular architecture makes it possible, for example, to
Technology is never an end in itself. We always examine what business problem it solves. We don't serve technology; technology serves us.
One of our most important lessons is that there is no single architecture that works universally well in every situation.
Not every application needs microservices. Not every system needs to move to the cloud right away. And not every legacy system needs to be replaced.
The real challenge is to find the modernization path that best aligns with a given company’s business objectives, technological environment, and regulatory requirements. In DRK’s case, availability, stability under heavy load, and long-term scalability were the most important factors. For other organizations, these priorities may be ranked quite differently.
Many projects focus exclusively on solving current problems. We take a broader view: even during the planning phase, we take into account the anticipated needs of the coming years, new business processes, new integrations, new regulatory requirements, the use of AI, and new cloud services.
A well-designed architecture can accommodate these changes later on without requiring another complete system overhaul. Good architecture doesn't solve today's problems. It solves tomorrow's.
The DRK project is a good example, but by no means an isolated case. We encounter the same challenges in other industries as well:
For us, successful modernization is not primarily a matter of technology. It is much more a matter of mindset. Four guiding principles have proven to be particularly important.
Digital transformation doesn't necessarily begin with the implementation of a new system. It begins with the realization that our existing systems already hold tremendous value.
The German Red Cross project clearly demonstrates that even the most critical applications can be modernized securely and incrementally while ensuring that day-to-day operations remain uninterrupted. Here at Gloster, we consider this one of our most important areas of expertise: we help our clients transform their existing systems into platforms that are sustainable in the long term, can be flexibly enhanced, and are prepared for future technologies.
If you, too, operate a business-critical system that you consider too risky to replace, it’s worth asking yourself: Do you really need to build a new system, or is it enough to intelligently upgrade the existing one? In our experience, there is a third option in most cases: gradual, business-safe modernization.
Because successful modernization doesn't start with a new system. It starts with the right strategy.
If you'd like to work with us to plan the modernization of your system, let's discuss your project.
At Gloster, the same question comes up every few years with every complex, bespoke enterprise system: when is it worth replacing an existing system entirely, and when is it wiser to develop it step by step? At many companies the gut feeling is that a system running for 10 to 20 years will eventually become hopelessly obsolete. That from here, only one road remains: the complete rewrite. In my experience, that is rarely true.
A business-critical application is more than source code. Over years, often decades, it accumulates business knowledge, specialised processes and countless integrations. Replacing all of that is a serious technical, commercial and organisational risk, and that risk very rarely fits within the life of a live system running day to day.
Our project at the German Red Cross (DRK) showed exactly that: gradual modernisation can be a far more sustainable and safer route than starting from zero.
Whether it is healthcare, automotive, manufacturing, finance or public administration, after a while almost every organisation runs into the same pattern:
This is especially true of systems tied to daily operations, or even to human lives. There, even a few hours of downtime is unacceptable. The German Red Cross's laboratory information system was in exactly this position.
In modernisation projects there are usually three roads to choose from.
At the German Red Cross we chose this road. Not because it was the more comfortable option, but because it was the responsible one.
At first glance it might look like the development of a laboratory information system. In reality it was about far more.
The platform connects laboratory equipment from different manufacturers, handles sensitive health data, and supports processes where reliability and availability are not an expectation but a baseline requirement. An outage of the system was simply not acceptable.
I remember, in one of the early meetings, a colleague at the DRK asked the question we have often recalled as a team since: "What happens if this system goes down for even a single hour?" The answer was not a technical one, it was a human one. That was the moment that made it clear the main question here was not the choice of technology.
The question was not which technology to use. The question was: how do you develop a business-critical system while keeping operations stable throughout?
We are proud to work with organisations like the German Red Cross, where modernising laboratory operations meant more than introducing new software. It meant making critical healthcare infrastructure fit for the long term.
The results of the project show clearly the tangible business value that the right architecture and modernisation strategy can create:
For us, a more important result still is that the DRK now has a platform that can be extended continuously with new laboratories, new devices and new technologies, without putting daily operations at risk.
This project shows that healthcare providers do not have to choose between innovation and operational continuity. With the right strategy, both can be achieved at once.
During the project we built on Docker, Kubernetes, microservice architecture and cloud-native approaches. Not because they happen to be fashionable right now, but because they answer specific problems.
A modular architecture makes it possible, for example, to develop individual components independently of each other, push new features into the live environment without downtime, spin up new laboratories in minutes, connect new laboratory equipment quickly, and have the system adapt automatically to increased load.
Technology in itself is never the goal. We always look at which business problem it solves. We do not serve the technology; the technology serves us.
One of our most important lessons is that there is no architecture that is universally right for every situation.
Not every application needs microservices. Not every system has to move to the cloud straight away. And not every legacy system needs replacing.
The real task is to find the modernisation route that fits best with a given company's business goals, technology environment and regulatory requirements. For the DRK, what mattered most was availability, stability under heavier load, and long-term extensibility. At other organisations these priorities may line up quite differently.
Many projects focus solely on solving the problems of the moment. We think further than that: as early as the design phase we take into account the likely needs of the coming years, new business processes, new integrations, new regulatory expectations, the use of AI, new cloud services.
A well-built architecture can absorb these later without needing another complete overhaul.
Good architecture does not answer today's problem. It answers tomorrow's.
The DRK project is a good example, but far from a unique one. We meet the same challenges in other sectors too:
The technologies differ. The challenges are surprisingly similar.
Digital transformation does not necessarily start with introducing a new system. It starts with recognising that our existing systems already hold enormous value.
The German Red Cross project shows that even the most critical applications can be modernised safely and gradually while daily operations stay undisturbed. At Gloster we consider this one of our most important competencies: we help our clients turn their existing systems into platforms that are sustainable for the long term, flexible to develop further, and ready for the technologies of the future.
If you too run a business-critical system that you consider too risky to replace, it is worth asking the question: do you really need to build a new system, or is it enough to develop the existing one intelligently? In our experience, in most cases there is a third road: gradual, commercially safe modernisation.
Because successful modernisation does not start with a new system. It starts with the right strategy.
If you would like to think through your own system's modernisation route with us, let's talk about your project. Talk to us about your project
Bei Gloster stellt sich uns seit Jahren dieselbe Frage – bei jedem komplexen, individuell entwickelten Unternehmenssystem: Wann lohnt es sich, ein bestehendes System vollständig zu ersetzen, und wann ist es sinnvoller, es Schritt für Schritt weiterzuentwickeln?
In vielen Unternehmen herrscht das Gefühl, ein System, das seit 10 bis 20 Jahren läuft, veralte früher oder später hoffnungslos. Und dass von hier nur noch ein Weg führt: die vollständige Neuentwicklung. Nach eigener Erfahrung trifft das nur selten zu.
Eine geschäftskritische Anwendung ist nicht nur Quellcode. Sie trägt über Jahre, oft über Jahrzehnte gewachsenes Fachwissen, spezielle Prozesse und unzählige Integrationen in sich. Das alles zu ersetzen, ist ein erhebliches technisches, geschäftliches und organisatorisches Risiko – und dieses Risiko ist im Lebenszyklus eines produktiv laufenden Systems nur sehr selten vertretbar.
Unser Projekt beim Deutschen Roten Kreuz (DRK) hat genau das gezeigt: Die schrittweise Modernisierung kann ein deutlich nachhaltigerer und sichererer Weg sein als der Start bei null.
Ob im Gesundheitswesen, in der Automobilindustrie, in der Fertigung, im Finanzwesen oder in der öffentlichen Verwaltung – nach einiger Zeit sieht sich fast jede Organisation mit demselben Muster konfrontiert:
Das gilt besonders für Systeme, die mit dem täglichen Betrieb (oder sogar mit Menschenleben) verbunden sind. Dort ist selbst ein Ausfall von wenigen Stunden nicht zulässig. Genau in dieser Situation befand sich auch das Laborinformationssystem des Deutschen Roten Kreuzes.
Bei Modernisierungsprojekten kann man in der Regel zwischen drei Wegen wählen.
Auch beim Deutschen Roten Kreuz haben wir diesen Weg gewählt. Nicht, weil das die bequemere Lösung war, sondern weil es die verantwortungsvolle war.
Auf den ersten Blick mag es so wirken, als ginge es um die Entwicklung eines Laborinformationssystems. In Wirklichkeit geht es um weit mehr.
Die Plattform verbindet Laborgeräte unterschiedlicher Hersteller, verarbeitet sensible Gesundheitsdaten und unterstützt Prozesse, in denen Zuverlässigkeit und Verfügbarkeit keine Erwartungen, sondern Grundvoraussetzungen sind. Ein Ausfall des Systems war schlicht nicht akzeptabel.
»Was passiert, wenn dieses System auch nur für eine einzige Stunde ausfällt?« – Diese Frage eines DRK-Kollegen in einer frühen Abstimmung machte deutlich, dass hier nicht die Technologiewahl die entscheidende Frage ist.
Die Frage war nicht, welche Technologie wir wählen sollten. Sondern: Wie lässt sich ein geschäftskritisches System so weiterentwickeln, dass der Betrieb dabei durchgehend stabil bleibt?
Die Ergebnisse des Projekts zeigen gut, welchen greifbaren geschäftlichen Nutzen die richtige Architektur und Modernisierungsstrategie schaffen können:
Noch wichtiger als diese Zahlen ist für uns das Ergebnis, dass das DRK heute über eine Plattform verfügt, die sich fortlaufend um neue Labore, neue Geräte und neue Technologien erweitern lässt, ohne den Tagesbetrieb zu gefährden.
Im Projekt haben wir auf Docker, Kubernetes, eine Microservice-Architektur und Cloud-native-Lösungen gesetzt. Nicht, weil sie gerade in Mode sind, sondern weil sie auf konkrete Probleme eine Antwort geben.
Eine modulare Architektur ermöglicht es zum Beispiel, dass sich die einzelnen Komponenten unabhängig voneinander entwickeln lassen, neue Funktionen ohne Ausfall in die Produktivumgebung gelangen, neue Labore sich innerhalb von Minuten in Betrieb nehmen lassen, neue Laborgeräte schnell angebunden werden und sich das System automatisch an die gestiegene Last anpasst.
Nicht wir dienen der Technologie, sondern die Technologie dient uns.
Es gibt keine Architektur, die für jede Situation gleichermaßen gut ist.
Nicht jede Anwendung braucht Microservices. Nicht jedes System muss sofort in die Cloud umziehen. Und nicht jedes Legacy-System muss ersetzt werden.
Die eigentliche Aufgabe besteht darin, den Modernisierungsweg zu finden, der am besten zu den geschäftlichen Zielen, zur technologischen Umgebung und zu den regulatorischen Anforderungen des jeweiligen Unternehmens passt.
Das DRK-Projekt ist ein gutes Beispiel, aber bei Weitem kein Einzelfall. Denselben Herausforderungen begegnen wir auch in anderen Branchen:
Die Technologien unterscheiden sich. Die Herausforderungen sind überraschend ähnlich.
Wenn auch Sie ein geschäftskritisches System betreiben, dessen Austausch Ihnen zu riskant erscheint, lohnt sich die Frage: Muss wirklich ein neues System gebaut werden, oder genügt es, das bestehende klug weiterzuentwickeln? Nach unserer Erfahrung gibt es in den meisten Fällen einen dritten Weg: die schrittweise Modernisierung bei beherrschbarem Geschäftsrisiko.
Eine erfolgreiche Modernisierung beginnt nicht mit einem neuen System. Sondern mit der richtigen Strategie.
Wenn Sie den Modernisierungsweg Ihres eigenen Systems gemeinsam mit uns durchdenken möchten, sprechen wir über Ihr Projekt. Jetzt Gespräch anfragen
.avif)
.webp)
