Legacy-Software modernisieren ohne Ausfall: Roadmap für den schrittweisen Umbau

Wer ein gewachsenes Altsystem in einem Schritt durch eine cloud-native Architektur ersetzt, riskiert den Betrieb, der das Unternehmen trägt. Der sicherere Weg ist ein Umbau in Etappen, bei dem jede Etappe für sich testbar bleibt und sich zurücknehmen lässt.

Warum der Umbau in einem Schritt fast immer schiefgeht

Ein Altsystem enthält Regeln, die niemand mehr aufgeschrieben hat. Sie stecken in Datenbanktriggern, in Nachtläufen, in einem Skript, das ein Kollege vor Jahren auf dem Server abgelegt hat. Wer alles auf einmal ablöst, entdeckt diese Regeln am Tag der Umstellung, wenn die Rechnungen falsch rauslaufen.

Der Umbau in Etappen dreht das um. Jede Etappe nimmt sich einen abgegrenzten Teil vor, läuft eine Zeit lang parallel zum Alten und wird erst abgeschaltet, wenn die Ergebnisse übereinstimmen. Das dauert länger und ist trotzdem der schnellere Weg, weil kein Schritt den Betrieb gefährdet.

Etappe eins: Bestandsaufnahme und Zielbild

Am Anfang steht eine ehrliche Inventur: Welche Anwendungen laufen, wer nutzt sie, welche Daten fließen zwischen ihnen, und welche Abhängigkeiten kennt nur der Kollege, der nächstes Jahr in Rente geht. Daraus entsteht ein Zielbild, das keineswegs alles in die Cloud schiebt. Manche Systeme bleiben im eigenen Rechenzentrum, weil sie stabil laufen oder weil ihre Daten das Haus nicht verlassen dürfen.

Ein häufiger Befund in dieser Phase: Ein großer Teil der Altanwendungen enthält gar keine Geschäftslogik, sondern schiebt Daten von A nach B. Diese Kandidaten lassen sich zuerst herauslösen.

Etappe zwei: Randfunktionen isolieren

Der erste greifbare Umbau nimmt eine Funktion mit geringer Komplexität und wenig Verflechtung, etwa den Dokumentenversand oder ein Berichtsmodul. Diese Funktion wird als eigener Dienst neu gebaut und über eine Schnittstelle vor das Altsystem gesetzt. Das Muster heißt Strangler Fig: Der neue Dienst übernimmt seine Anfragen, das Altsystem bleibt unverändert und bearbeitet weiterhin alles, was noch nicht umgezogen ist. Läuft der neue Dienst einige Wochen fehlerfrei, folgt die nächste Funktion.

Etappe drei: Container und Orchestrierung

Sobald mehrere Dienste existieren, lohnt der Schritt zu Containern (Docker) und einer Orchestrierung (Kubernetes oder eine schlankere Alternative). Container machen Dienste portabel und reproduzierbar. Beginnen Sie mit einem unkritischen Dienst, betreiben Sie ihn parallel zur alten Installation und schalten Sie die alte erst nach einem Lasttest ab. Kubernetes ist dabei kein Selbstzweck: Für eine Handvoll Dienste reicht oft eine einfachere Plattform, und die spart Betriebsaufwand.

Etappe vier: Daten aus dem Monolithen lösen

Daten sind der schwierigste Teil. Ein Monolith hängt an einer großen Datenbank, an der viele Module gleichzeitig ziehen. Der Weg heraus: Jeder neue Dienst bekommt einen eigenen Datenbestand, und Änderungen werden als Ereignisse verteilt, damit alle Beteiligten denselben Stand kennen. Während der Übergangszeit laufen alte und neue Datenhaltung parallel, mit einem Abgleich, der Abweichungen meldet. Wer Daten zu früh migriert, migriert sie zweimal.

Etappe fünf: Automatisierung und Überwachung

Eine cloud-native Umgebung ohne automatisierte Auslieferung ist nur ein teureres Altsystem. Die Infrastruktur wird als Code beschrieben (etwa mit Terraform), jede Änderung läuft durch eine Pipeline mit Tests, und ein fehlgeschlagenes Update rollt von selbst zurück. Dazu gehört eine Überwachung, die nicht bloß meldet, dass ein Server lebt, sondern ob die Anwendung antwortet. Erst mit diesem Schritt wird ein Update ohne Ausfallzeit zum Normalfall statt zur Heldentat.

Etappe sechs: Sicherheit und Datenschutz in jeder Etappe

Sicherheit gehört in jede Etappe, nicht ans Ende. Sicherheitstests laufen in der Pipeline, Daten sind ruhend und unterwegs verschlüsselt, Dienste authentifizieren sich gegenseitig, und Berechtigungen folgen dem Prinzip der geringsten Rechte. Für Unternehmen unter der DSGVO oder einer Branchenaufsicht kommt die Standortfrage dazu: Wo laufen die Dienste, wo liegen die Daten, wer kann darauf zugreifen? Eine souveräne Infrastruktur in Deutschland beantwortet diese Frage ohne Umwege.

Häufige Fragen zum schrittweisen Umbau

Wie lange dauert der Umbau? Einfache Anwendungen sind in Wochen umgezogen, stark verflochtene Systeme brauchen Monate bis Jahre. Nach jeder Etappe bewerten Sie neu.

Was sind die größten Risiken? Datenverlust und Schnittstellen, die sich anders verhalten als dokumentiert. Beides wird durch Parallelbetrieb und automatisierte Tests kleiner, verschwindet aber nie ganz. Wer Ihnen einen Umbau ohne jedes Restrisiko verspricht, hat noch keinen gemacht.

Wie bleiben Sie unabhängig vom Cloud-Anbieter? Container nach offenem Standard, keine herstellereigenen Dienste im Kern, Datenbanken wie PostgreSQL statt proprietärer Varianten. Dann bleibt ein Anbieterwechsel ein Projekt und wird keine Neuentwicklung.

Der nächste Schritt: Ihre Inventur beginnen

Nehmen Sie das eine Altsystem, das Ihnen am meisten Sorgen macht, und schreiben Sie auf, welche Anwendungen davon abhängen und wer die Antworten dazu kennt. Wird die Liste länger als erwartet, gehen wir sie in einer halben Stunde gemeinsam durch und klären, welche Etappe zuerst dran ist und ob dataso dafür der richtige Partner ist: Potenzial-Check buchen.