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.
- Assessment vor der Strategie-Empfehlung
- Etappen mit umkehrbarer Umschaltung
- Datenmigration explizit geplant
01Ausgangslage
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.
02Auslö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).
-
Datenbank oder Integration bremst
Eine zentrale Datenbank oder Integration hemmt alles andere.
03Phase 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
04Entscheidung
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.
| 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) | 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 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.
05Architektur
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; die Schnittstellen zwischen alten und neuen Teilen gestalten wir als APIs.
06Umsetzung
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.
- 01
Etappe festlegen
Kleinster Schnitt mit eigenem Nutzen und prüfbarem Ergebnis.
- 02
Sicherungsnetz bauen
Tests für das vorhandene Verhalten (soweit fehlend), Beobachtbarkeit am Altsystem, Referenzmessung.
- 03
Neues Stück entwickeln
Zunächst ohne Verkehr, im Schattenbetrieb oder mit Vergleich der Antworten.
- 04
Umschalten
Per Routing in kleinen Anteilen, mit Kennzahlen zur Entscheidung.
- 05
Rückfallweg bereithalten
Der Altpfad bleibt aktiv, bis die Etappe in Produktion bestanden hat; die Umschaltung ist umkehrbar.
- 06
Altpfad abbauen
ZuletztErst nach vereinbarter Beobachtungszeit.
07
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.
08Daten
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
09Betrieb
Reproduzierbar ausliefern, verlässlich betreiben
Ziel ist ein reproduzierbarer Auslieferungsweg. Anschließender Betrieb auf Wunsch über Managed Services.
-
Container-Images
Die Anwendung wird als Image gebaut und überall gleich gestartet.
-
Konfiguration als Code
Umgebungen mit OpenTofu/Terraform beschrieben statt von Hand gebaut.
-
Automatisierte Pipelines
Build, Prüfung und Auslieferung laufen über CI/CD, auf Kubernetes oder Ihrer bestehenden Plattform.
-
Datenbankziele
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.
10
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.
11
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.