--- title: "Legacy-Anwendungen modernisieren | SKAFFON" description: "Legacy-Anwendungen modernisieren: App-Assessment, Entscheidungsmatrix von Containerisierung bis Neubau, schrittweise Ablösung, Datenmigration, Rückfallweg." url: https://skaffon.de/software/application-modernisierung/ --- ![Altbau mit Baugerüst an der Fassade während der Sanierung](/_astro/altbau-baugeruest-sanierten-fassade.BT56OoFE_1pomiY.jpg) 1. [Startseite](/) 2. [Software](/software/) 3. Legacy-Anwendungen modernisieren und in die Cloud migrieren Anwendungsmodernisierung · je Anwendung entschieden # Legacy-Anwendungen modernisieren und in die Cloud migrieren Eine Altanwendung braucht keine Technik von der Stange, sondern eine Entscheidung: isolieren, containerisieren, schrittweise ablösen, neu bauen oder ersetzen. Wir nehmen die Anwendung auf, empfehlen begründet und setzen Etappen mit Rückfallweg um. [Anwendung besprechen](/projekt-anfragen/) [Zur Entscheidungsmatrix](/software/application-modernisierung/#welche-strategie-fuer-welche-anwendung) - Assessment vor der Strategie-Empfehlung - Etappen mit umkehrbarer Umschaltung - Datenmigration explizit geplant Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## Wenn jede Änderung zum Risiko wird Die Anwendung läuft, aber niemand fasst sie gern an: Das Wissen sitzt bei wenigen Köpfen, Tests fehlen, die Plattform läuft aus der Unterstützung. Dann steht die Frage im Raum, ob Sie die Anwendung umziehen, zerlegen, ersetzen oder neu bauen. Wir nehmen sie auf, empfehlen eine Strategie mit Begründung und setzen sie in Etappen um, jede mit definiertem Rückfallweg. Eine einzige Standardtechnik gibt es dafür nicht; die Entscheidung fällt je Anwendung. Bei Bedarf verbinden wir sie mit einer [Cloud-Migration](/leistungen/cloud-migration/). Nicht jede alte Anwendung muss weg Läuft sie stabil, ist sicher betreibbar und wird kaum geändert, ist „unverändert lassen und isolieren“ eine legitime Entscheidung. Auslöser ## Woran Sie merken, dass die Anwendung im Weg steht - ### Support läuft aus Das Betriebssystem, die Laufzeit oder ein Framework erreicht das Ende der Unterstützung. - ### Änderungen dauern und riskieren viel Wissen und Tests fehlen, jede Anpassung ist ein Wagnis. - ### Skalierung, Auslieferung, Absicherung gehen nicht Die Anwendung lässt sich nicht skalieren, automatisiert ausliefern oder absichern. - ### Plattformwechsel steht an Ein Rechenzentrums- oder Plattformwechsel verlangt Klarheit ([Cloud-Readiness-Assessment](/loesungen/cloud-readiness-assessment/)). - ### Datenbank oder Integration bremst Eine zentrale Datenbank oder Integration hemmt alles andere. Phase 1 ## Bestandsaufnahme, bevor wir eine Strategie nennen Bevor wir eine Strategie empfehlen, nehmen wir die Anwendung auf. Das Ergebnis ist ein Assessment mit Bewertung je Anwendung, Risiken, Abhängigkeiten und einer begründeten Strategie-Empfehlung. Die Bewertung ist eine Fachentscheidung zusammen mit Ihnen, kein automatisierter Befund. - Quellcode, Abhängigkeiten, Build- und Deployment-Weg, vorhandene Tests - Architektur und Schnittstellen: Eingänge, Ausgänge, Batch-Läufe, Dateiaustausch - Datenhaltung: Datenbanken, Schemas, Größe und Abhängigkeiten - Betrieb: Umgebung, Wartungsfenster, Störungen, Zugriffsrechte - Sicherheits- und Compliance-Anforderungen - Fachliche Bedeutung und Änderungsrate ![Nahaufnahme von farbig hervorgehobenem Quellcode auf einem Bildschirm](/_astro/quellcode-auf-bildschirm.Y9CPsO-G_ZCzO3.jpg) Entscheidung ## Welche Strategie für welche Anwendung? Sechs Wege, jeweils mit der Bedingung, unter der sie tragen, und der, unter der sie scheitern. Welcher gilt, entscheidet das Assessment. __Entscheidungsmatrix: Strategie, Vorgehen, Eignung und Ausschlusskriterium je Anwendung__ | Strategie | Was passiert | Geeignet, wenn | Nicht geeignet, wenn | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Beibehalten und isolieren | Anwendung bleibt, Zugriffe und Netz werden abgesichert, Schnittstelle gekapselt | stabil, selten geändert, Ersatz absehbar | Laufzeit oder Plattform ist nicht mehr absicherbar | | Containerisieren / Replatforming | Anwendung im Wesentlichen unverändert in Container oder auf neue Plattform, Deployment automatisiert ([Containerisierung](/leistungen/containerisierung/)) | Code ist funktional in Ordnung, Betrieb ist das Problem | Anwendung hält Zustand lokal, hängt an Hardware oder Lizenzbindung | | Refactoring | Gezielte Änderung am Code für Wartbarkeit, Konfiguration, Zustand, Beobachtbarkeit | Struktur taugt, einzelne Hemmnisse sind klar | Strukturelle Schulden im gesamten Code | | Schrittweise Ablösung (Strangler-Muster) | Funktionen werden nach und nach in neue Dienste verlagert, Altsystem schrumpft | Monolith mit klaren Funktionsgrenzen, Betrieb muss weiterlaufen | Funktionsgrenzen nicht erkennbar, kein Budget für längeren Parallelbetrieb | | Neubau | Neue Anwendung, Daten werden übernommen | Fachlogik ist veraltet, Code nicht tragfähig, Anforderungen ändern sich grundlegend | Fachwissen steckt ausschließlich im Altcode und ist nicht dokumentiert | | Ersatz durch Standardprodukt | Anwendung wird abgelöst | Anforderungen sind durch Standard abgedeckt | Kernprozess ist Wettbewerbsfaktor | Das [Strangler-Fig-Muster](https://martinfowler.com/bliki/StranglerFigApplication.html) beschreibt Martin Fowler als schrittweise Ablösung durch neue Komponenten neben dem Altsystem anstelle eines risikoreichen Komplettaustauschs. Es erzielt früher sichtbaren Nutzen, verlangt aber organisatorische Disziplin, damit die neue Lösung nicht wieder verfällt. Architektur ## Monolith: zerlegen oder lassen? Ein Monolith ist kein Fehler. Ein sauber strukturierter Monolith ist oft besser als ein verteiltes System, das niemand beherrscht. Wir zerlegen entlang von Fachgrenzen, nicht entlang von Technologie, und nur dort, wo die Zerlegung ein konkretes Problem löst: unabhängige Auslieferung, abweichende Skalierung, getrennte Verantwortung. Zielbild und Muster (Resilienz, Verträge, Beobachtbarkeit) beschreibt [Cloud-native Entwicklung](/software/cloud-native-entwicklung/); die Schnittstellen zwischen alten und neuen Teilen gestalten wir als [APIs](/software/api-schnittstellen/). Umsetzung ## Eine Etappe, ein Nutzen, ein Weg zurück Jede Etappe wird so geschnitten, dass sie allein Nutzen bringt und sich bei Bedarf zurücknehmen lässt. 1. 01 ### Etappe festlegen Kleinster Schnitt mit eigenem Nutzen und prüfbarem Ergebnis. 2. 02 ### Sicherungsnetz bauen Tests für das vorhandene Verhalten (soweit fehlend), Beobachtbarkeit am Altsystem, Referenzmessung. 3. 03 ### Neues Stück entwickeln Zunächst ohne Verkehr, im Schattenbetrieb oder mit Vergleich der Antworten. 4. 04 ### Umschalten Per Routing in kleinen Anteilen, mit Kennzahlen zur Entscheidung. 5. 05 ### Rückfallweg bereithalten Der Altpfad bleibt aktiv, bis die Etappe in Produktion bestanden hat; die Umschaltung ist umkehrbar. 6. 06 ### Altpfad abbauen Zuletzt Erst nach vereinbarter Beobachtungszeit. ## Strangler-Muster in drei Zuständen Von der Ausgangslage über die geteilte Last bis zur entfernten Funktion: die Routing-Schicht entscheidet, der Rückweg bleibt offen. Strangler-Schema mit Routing-Schicht, Altsystem, neuem Dienst und führender Datenquelle je Etappe. Strangler-Schema mit Routing-Schicht, Altsystem, neuem Dienst und führender Datenquelle je Etappe. Daten ## Die Datenbank ist meist der schwierigste Teil Wir klären Schema, Abhängigkeiten, Größe, Anforderungen an Unterbrechungsfreiheit und Prüfung auf Vollständigkeit. Bei schrittweiser Ablösung planen wir den Umgang mit geteilten Daten explizit: wer ist je Datenbereich führend, wie wird synchronisiert, wann endet der Parallelbetrieb. - Führende Datenquelle je Datenbereich festlegen - Synchronisation im Parallelbetrieb planen - Ende des Parallelbetriebs vereinbaren [PostgreSQL-Migration](/daten/postgresql-migration/) ![Historischer Kartenkatalog mit beschrifteten Holzschubladen in einem Archiv](/_astro/historischer-kartenkatalog-holzschubladen-archiv.Csfo2071_Z1AbOy6.jpg) Betrieb ## Reproduzierbar ausliefern, verlässlich betreiben Ziel ist ein reproduzierbarer Auslieferungsweg. Anschließender Betrieb auf Wunsch über [Managed Services](/managed-services/). - ### [Container-Images](/leistungen/containerisierung/) Die Anwendung wird als Image gebaut und überall gleich gestartet. - ### [Konfiguration als Code](/leistungen/infrastructure-as-code/) Umgebungen mit OpenTofu/Terraform beschrieben statt von Hand gebaut. - ### [Automatisierte Pipelines](/leistungen/ci-cd-pipelines/) Build, Prüfung und Auslieferung laufen über CI/CD, auf Kubernetes oder Ihrer bestehenden Plattform. - ### [Datenbankziele](/daten/datenbank-migration/) Wechsel der Datenbankplattform, auch mit PostgreSQL als Ziel. Grenzen ## Wir versprechen keine Cloud für jeden Altbestand Anwendungen mit Hardware-Bindung, nicht ablösbaren Lizenzen oder fehlenden Quellen sind Fälle für Isolieren statt Migrieren. Modernisierung nutzen wir zugleich zur Absicherung: Geheimnisse aus dem Code, Abhängigkeits- und Container-Prüfung, Zugriffsrechte. ## Wann wir modernisieren, wann wir davon abraten ### Passt zu Ihrer Lage - Die Anwendung ist schwer zu ändern, zu betreiben oder abzusichern und soll weiterleben. - Sie wollen ein Assessment als Grundlage für ein belastbares Angebot. ### Passt (noch) nicht - Die Anwendung läuft stabil, ist sicher und wird kaum geändert: dann ist Modernisierung kein Ziel. - Sie erwarten Festpreis und Termin für die Modernisierung eines Systems, das noch nicht aufgenommen wurde. - Es gibt weder Quellcode noch fachliches Wissen noch Testmöglichkeiten; dann beginnt ein Assessment, kein Umbau. - Sie suchen ein Standardprodukt als Ersatz. ## Was das Angebot bestimmt Den Aufwand bestimmen Größe und Zustand der Anwendung, Testabdeckung, Datenmenge und Datenabhängigkeiten, Zahl der Integrationen, Anforderungen an Unterbrechungsfreiheit und der Umfang von Parallelbetrieb. Das Assessment liefert die Grundlage für ein belastbares Angebot. ## Beschreiben Sie uns Ihre Anwendung Eine kurze Beschreibung genügt: Technologie, Alter, Hemmnis. Weitere Leistungen finden Sie unter [Software Engineering und Anwendungsmodernisierung](/software/). [Projekt anfragen](/projekt-anfragen/)