Foto: Google Gemini · AI-generated
AWS hat kürzlich From Migration to Continuous Modernization veröffentlicht — einen tiefen Einblick in ihren Transform-Service zur Anwendungsmodernisierung. Der Artikel ist erwartungsgemäß schwer auf AWS-Tooling ausgerichtet — Bedrock-Migrationen, Mainframe-COBOL-Analyse, CodeCatalyst-Pipelines. Aber im Produktmarketing verborgen steckt eine Botschaft, die eigenständig Beachtung verdient:
„Behandelt Ihre Organisation Modernisierung immer noch als einmaliges Projekt?“
Diese Frage ist mehr wert als der gesamte Rest des Artikels.
Der Irrtum der einmaligen Migration
Die meisten Unternehmen gehen Anwendungsmodernisierung als begrenztes Projekt an. Es gibt ein Legacy-System, es muss modernisiert werden, ein Budget wird bewilligt, und ein Team verbringt 6–18 Monate mit dem Neubau. Projekt abgeschlossen. Weiter zum Nächsten.
Das Problem: Die modernisierte Anwendung beginnt in dem Moment zu altern, in dem sie ausgeliefert wird. Frameworks entwickeln sich weiter, Sicherheitsanforderungen verschärfen sich, Nutzererwartungen verschieben sich, Geschäftsprozesse ändern sich, und die zugrundeliegende Plattform bringt Breaking Changes. Innerhalb von zwei bis drei Jahren ist die „modernisierte“ Anwendung selbst ein Legacy-System.
Das ist kein Versagen der Modernisierung. Es ist ein Versagen des Modernisierungsmodells. Modernisierung als Projekt zu behandeln — mit Startdatum und Enddatum — garantiert, dass Sie in wenigen Jahren ein weiteres Modernisierungsprojekt brauchen.
Vier Generationen und es geht weiter
Wir bei exbisoft haben das selbst erlebt. Unser Nachunternehmerportal für ein deutsches Bauunternehmen ist inzwischen in seiner vierten Generation. exbisoft verantwortet die Generationen zwei bis vier — wir haben einen initialen Build übernommen und die Anwendung über mehrere große Technologiewechsel kontinuierlich weiterentwickelt.
Die Anwendung begann als .NET-Webportal. Im Laufe ihres Lebenszyklus wurde sie um native iOS-, Android- und Windows-Apps erweitert, von Xamarin auf MAUI migriert, an sich verändernde Offline-Sync-Anforderungen angepasst und an neue Compliance-Vorgaben umstrukturiert. Keine dieser Generationen war ein „Projekt“ — jede war eine Antwort auf reale Veränderungen im Geschäft, in der Technologie und bei den Nutzern.
Hätten wir die erste Modernisierung als einmalige Maßnahme behandelt, wäre die Anwendung innerhalb von drei Jahren veraltet gewesen. Stattdessen ist sie weiterhin im aktiven Einsatz, entwickelt sich weiter und liefert Mehrwert — weil der Kunde in eine kontinuierliche Partnerschaft investiert hat, nicht in einen Einmalauftrag.
Was kontinuierliche Modernisierung tatsächlich erfordert
AWS verpackt das in Cloud-Tooling, aber die zugrundeliegende Disziplin ist plattformunabhängig. Kontinuierliche Modernisierung erfordert:
Eine Architektur, die Veränderung verträgt. Monolithen widersetzen sich Evolution. Anwendungen mit sauberer Schichtentrennung, klar definierten APIs und modularen Komponenten können inkrementell aktualisiert werden — Modul für Modul, Schicht für Schicht — ohne alles neu zu bauen.
Ein Team, das das System kennt. Modernisierung ist keine Greenfield-Entwicklung. Sie erfordert das Verständnis dessen, was existiert, warum es so gebaut wurde und was kaputt geht, wenn man es ändert. Ein Team, das eine Anwendung durch mehrere Generationen begleitet hat, trägt institutionelles Wissen, das keine Dokumentation ersetzt.
Ein Partnerschaftsmodell, kein Projektmodell. Einmalige Modernisierungsprojekte enden mit einer Übergabe. Kontinuierliche Modernisierung erfordert eine laufende Beziehung — ein Team, das die Technologielandschaft beobachtet, empfiehlt, wann Upgrades sinnvoll sind, und die Arbeit ohne den Overhead eines erneuten Onboardings durchführt.
Pragmatische Technologieentscheidungen. Nicht jedes Upgrade muss das neueste Framework übernehmen. Kontinuierliche Modernisierung bedeutet, den richtigen Moment für jede Veränderung zu wählen — von Xamarin auf MAUI migrieren, wenn MAUI stabil genug ist, nicht wenn es erstmals erscheint. KI-Tooling einsetzen, wenn es die Entwicklung tatsächlich beschleunigt, nicht weil es gerade Mode ist.
Die AWS-Tendenz — und was trotzdem stimmt
Der AWS-Artikel positioniert kontinuierliche Modernisierung als Grund, AWS Transform, Bedrock und CodeCatalyst zu nutzen. Das ist ein Verkaufsgespräch. Kontinuierliche Modernisierung erfordert kein AWS — sie funktioniert auf Azure, auf Private Cloud, On-Premises oder in jeder Kombination.
Was unabhängig von der Plattform gilt, ist die Kernerkenntnis: Anwendungen sind lebende Systeme, die kontinuierliche Investition brauchen. Unternehmen, die für eine einmalige Modernisierung budgetieren und dann fünf Jahre Stabilität erwarten, planen für Enttäuschung. Unternehmen, die für laufende Evolution budgetieren — einen Partner, ein Team, ein wiederkehrendes Engagement — planen für die Realität.
Die Frage ist nicht, ob Sie modernisieren. Sondern ob Sie einmal modernisieren und hoffen — oder Modernisierung in Ihre Betriebsweise einbauen.